Burn Agent (Burn) security report
Radar by SecureChain AI scanned Burn Agent’s verified contract source on BNB Smart Chain. No proxy, blacklist, or arbitrary owner mint was identified, but medium-severity launch-control, oracle-guard, and pair-tax risks were found.
The supplied source does not show a conventional honeypot, arbitrary owner mint, blacklist, proxy, or configurable sell restriction. However, the deployer-designated earlyOpener can manually open trading before the normal threshold, and minting depends on an on-chain reserve-price guard that can create execution failures or become sensitive to sustained reserve-price manipulation.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0x7de1606230aa70802caecf1a3e90039a6265b1c4.
This report was last modified on 2026-11-04 and contains 3 material findings.
medium finding: Privileged early opening can change launch timing and pricing
The constructor assigns earlyOpener to the deployer, and openEarly can be called only by that address while the contract has minted fewer than OPEN_AT shares and has pending liquidity. Calling it sets opened=true, clears earlyOpener, and opens the pool before the automatic threshold is reached. This gives the deployer unilateral control over when the early phase ends and when live reserve-based pricing begins.
Evidence: In the constructor, earlyOpener = msg.sender. openEarly checks msg.sender != earlyOpener and eligible, where eligible is !opened && shares < OPEN_AT && wbnbAmount > 0, then calls _open(true). _open(true) does not require totalMinted == OPEN_AT and sets opened = true.
Recommendation: Remove unilateral manual opening or replace it with a transparent, immutable launch condition. If early opening is required, use a timelocked or multisignature authorization and publish explicit minimum-share and liquidity conditions before enabling the live phase.
medium finding: Reserve-price guard can cause mint denial and is exposed to sustained pool-price manipulation
After opening, paid minting requires the current pool spot price to remain within five percent of a cumulative average. A sustained reserve-price distortion can influence the cumulative observation used by the guard, while ordinary reserve-price changes beyond the fixed tolerance can cause mint transactions to revert until observations catch up. This creates a material availability and pricing dependency on the canonical pair.
Evidence: _guardPrice computes spot from pair.getReserves(), derives an average from cumulative prices when delta >= ORACLE_WINDOW, and reverts with ReservePriceOutsideWindow when diff > avg / 20. ORACLE_WINDOW is 30 minutes. _mintUnits invokes _guardPrice before issuing post-opening paid tokens, and checkpoint updates the stored average from pair cumulative data.
Recommendation: Use a well-defined external oracle or a more robust multi-observation TWAP design with explicit freshness and deviation handling. Consider separating mint availability from a strict five-percent revert condition and add tests for reserve manipulation, stale observations, and legitimate price movement.
medium finding: All pair-facing transfers apply a hardcoded two-percent tax, including pool interactions
Transfers involving the canonical pair are automatically taxed. Half of the tax is sent to the dead address and half to the fixed treasury, which creates a material transfer-cost and pool-accounting behavior that integrators and liquidity operations must account for.
Evidence: _update applies tax = Math.mulDiv(amount, 2, 100) whenever from == address(pair) or to == address(pair), sends tax/2 to DEAD and the remainder to treasury, then transfers only the reduced amount. GoPlus independently reports buy_tax 0.02, sell_tax 0.02, and transfer_tax 0.
Recommendation: Document the pair-specific tax and test swap, liquidity-add, and liquidity-removal paths against the intended economics. Ensure integrations do not assume that transfers to or from the pair are fee-free.