Binance Man (币安人) security report
Radar by SecureChain AI scanned Binance Man on BNB Smart Chain. Slither was not run. Source review found medium-severity risks involving dividend callbacks, unchecked tax limits, and owner-controlled migration.
No Critical or High-confidence exploit was established from the supplied evidence. Three Medium-severity risks were identified: external dividend callbacks can block transfers, tax settings above 100% can lock taxed pool transfers, and owner-controlled migration can restrict pool interaction before ownership is renounced.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0x2c2d4298548ae585c224714555f18abde7367777.
This report was last modified on 2026-10-13 and contains 3 material findings.
medium finding: External dividend callback can block token transfers
When dividendContract is nonzero, every transfer involving a non-excluded address calls IDividend.setShare(). Any revert from that external contract is propagated through DividendShareUpdateFailed, causing the token transfer itself to revert. A misconfigured, unavailable, or intentionally reverting dividend contract can therefore create a transfer-availability failure.
Evidence: In _afterTokenTransfer(), calls to IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) are wrapped in try/catch that executes revert DividendShareUpdateFailed(...) on failure. dividendContract is assigned during initialize() and has no setter in the contract.
Recommendation: Use a failure-tolerant dividend update path, such as queuing share updates or allowing transfers to succeed when the dividend callback fails. Validate the dividend contract during initialization and provide a controlled recovery or replacement mechanism.
medium finding: Tax parameters above 100% can make taxed pool transfers revert
The initializer accepts uint16 buy and sell tax rates without enforcing a maximum of 10000 basis points. If a rate exceeds 10000, the calculated tax exceeds the transfer amount, and amount - tax in _taxedTransfer() reverts. This can prevent buys or sells involving configured pools while tax enforcement is active.
Evidence: initialize() stores params.buyTax and params.sellTax directly in poolState without a <= 10000 check. _getTaxWithPoolState() calculates amount * taxRate / 10000, while _taxedTransfer() performs uint256 remainingAmount = amount - tax. Solidity 0.8 arithmetic reverts when tax is greater than amount.
Recommendation: Require both tax parameters to be <= 10000 during initialization and add defensive bounds checks before subtracting tax. Test all migration and tax-enforcement states with boundary values.
medium finding: Owner-controlled migration can restrict pool transfers
While the token is in BondingCurve state, transfers to or from any configured pool are rejected. Only the owner can call startMigration(), and only the owner can call finalizeMigration(). Before ownership is renounced, a privileged owner can delay or sequence these transitions, keeping pool interaction restricted or controlling when tax enforcement begins.
Evidence: _transfer() requires !pools[from] && !pools[to] in PoolState.BondingCurve. startMigration() and finalizeMigration() are both external onlyOwner functions. GoPlus reports the current owner address as the zero address, which reduces this live control concern if the supplied state is accurate, but the restriction remains part of the verified contract behavior before renunciation.
Recommendation: Use an immutable or time-bound migration schedule, publish the intended state-transition conditions, and verify that ownership is intentionally renounced only after migration is complete. Monitor poolState and migration events.