BscAgentID (BscAgentID) security report
Radar AI scanned BscAgentID on BNB Smart Chain. Material findings include powerful minter permissions, arbitrary pair burning, pool-transfer restrictions, and an external tax-ledger dependency.
BscAgentID is not free of material contract risks. The configured minter has powerful supply and trading controls, including minting and pair-balance burning authority. Pool blocking and external tax-ledger calls can also restrict trading or cause transactions to revert.
Trust score: 42/100. Source verified: Yes. Chain: bsc. Contract: 0x86ef99de176331ede1608058d6d50c5276651caa.
This report was last modified on 2026-11-04 and contains 4 material findings.
high finding: Configured minter can arbitrarily mint tokens up to the supply cap
The configured minter can call mint with any recipient and amount, subject only to MAX_SUPPLY. This creates strong dilution and control risk because the source does not impose a per-call, time-based, or allocation-specific mint limit.
Evidence: DagentToken.sol defines mint(address to, uint256 amount) with onlyMinter. It checks only whether _totalSupply + amount exceeds MAX_SUPPLY, then credits the recipient through _update(address(0), to, amount). GoPlus independently reports is_mintable as 1.
Recommendation: Use an immutable, narrowly scoped mint authority or governance-controlled minter with explicit issuance limits, timelocks, and transparent allocation rules. If no further issuance is required, permanently revoke or disable mint authority after the intended supply is created.
high finding: Minter can burn arbitrary balances from the configured pair
The minter can directly remove any specified amount from the configured pair balance and send it to the DEAD address. This can alter the pair's token balance without a normal swap and may materially disrupt pricing or cause losses for liquidity providers and traders relying on the pair.
Evidence: burnFromPair(uint256 amount) is protected only by onlyMinter and calls _update(pair, DEAD, amount). _update then subtracts amount from _balances[pair] if sufficient, without requiring a pair-originated transfer or a proportional liquidity operation. The DEAD address is not address(0), so this action does not reduce _totalSupply.
Recommendation: Remove arbitrary pair-burning authority or restrict it to a verifiable, bounded mechanism with governance approval, rate limits, and event-level monitoring. Ensure any intended burn mechanism preserves accurate supply accounting and cannot unexpectedly alter pool balances.
medium finding: Minter can censor pools and impose transfer destinations
The minter can block arbitrary pool addresses, while the token also rejects transfers to poolManager and infinityVault and rejects addresses detected as other AMM pairs. These rules can prevent transfers into integrations or trading venues and give the minter operational control over where tokens may be sent.
Evidence: setPoolBlocked(address pool, bool blocked) and disableBlocks() are both protected by onlyMinter. rejects(address to) returns true for poolManager and infinityVault, for blocked pools while blocksDisabled is false, and for addresses identified by _isOtherPair. _update calls rejects(to) for every non-mint transfer after trading is enabled.
Recommendation: Document all transfer restrictions and minimize privileged pool controls. Consider immutable allowlists or governance timelocks, publish the configured addresses, and test compatibility with intended AMM and custody integrations before deployment.
medium finding: Buy and sell transfers depend on an external tax-ledger call
Pair purchases and sales call the configured minter as an ITaxLedger contract after moving tax tokens. If that external call reverts or is incompatible with the interface, the entire buy or sell transaction reverts, creating a conditional trading-availability risk.
Evidence: For buys, _update calls ITaxLedger(m).creditBuyTax(tax); for sells, it calls ITaxLedger(m).creditSellTax(toCreator). The address m is the initialized minter and is not checked for contract code or interface compatibility. These calls occur on the pair-transfer paths and are not wrapped in failure handling.
Recommendation: Validate that the minter implements the required interface during initialization, or decouple tax accounting from the transfer path. Add bounded failure handling and tests covering unavailable, reverting, and non-contract minter addresses.