Binance Inu (BI) security report
Binance Inu was AI scanned from verified source with GoPlus evidence reviewed. No critical exploit was proven; two medium external-dependency risks were identified, while Slither was not run.
No Critical or High-confidence exploit was proven from the supplied source and evidence. Two Medium risks were identified: a configured dividend callback can block transfers if it reverts, and tax-processing failure can route the token contract's entire accumulated tax balance to the configured tax processor.
Trust score: 72/100. Source verified: Yes. Chain: bsc. Contract: 0xcaf66eb2c00d206d741a654face34768cf2a7777.
This report was last modified on 2026-10-07 and contains 2 material findings.
medium finding: Dividend callback can block ordinary transfers and trading
Every transfer involving a non-exempt address calls the configured dividend contract's setShare function. Any revert from that external call reverts the entire token transfer, creating a transfer-denial dependency on an external contract.
Evidence: In _afterTokenTransfer, setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) are called without allowing failure; failures are caught and immediately reverted with DividendShareUpdateFailed. Only the token contract, pools, zero address, burn address, and dividend contract are skipped. The behavior affects wallet transfers and can also affect buys or sells because the user-side address is normally not exempt.
Recommendation: Use a non-blocking dividend update pattern, such as recording failed updates for later synchronization instead of reverting the token transfer. Add operational monitoring and emergency recovery procedures for dividend-contract failures.
medium finding: Tax-processing failure transfers the full accumulated tax balance to the tax processor
If the external TaxProcessor call fails, the fallback path sends the entire token balance held by the token contract to taxProcessor, rather than limiting the transfer to the tax amount being processed. A processor failure or malicious processor can therefore take custody of all accumulated tax tokens held by the contract.
Evidence: In _processTax, a failed ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) call enters the catch block, reads balanceOf(address(this)) into remainingBalance, and calls _plainTransfer(address(this), taxProcessor, remainingBalance). The source does not cap this amount at taxAmount or verify how the processor uses the tokens. The processor address is supplied during initialize and there is no owner function to replace it.
Recommendation: Limit fallback transfers to the intended tax amount, use an explicitly governed recovery mechanism for residual balances, and verify or constrain the TaxProcessor implementation before initialization. Document the processor's custody and failure semantics.