Feeding Daubao (喂豆包) security report
Radar by SecureChain AI scanned the verified Feeding Daubao contract on BNB Smart Chain and found high- and medium-severity control and transfer-availability risks.
The contract is not free of material security and control risks. Its tax-processing and dividend integrations create meaningful trust and availability dependencies, while the owner can control migration progression and associated pool-transfer restrictions.
Trust score: 54/100. Source verified: Yes. Chain: bsc. Contract: 0x7851b24e42114f9e155c52567ec2fec8d8967777.
This report was last modified on 2026-10-13 and contains 3 material findings.
high finding: Tax processor can receive all accumulated tax tokens on processing failure
When tax processing reverts, the contract catches the failure and transfers its remaining token balance directly to the configured taxProcessor. The tax processor also receives an unlimited allowance for the token contract balance during normal processing. A malicious, compromised, or incorrectly configured processor could therefore capture accumulated tax tokens instead of distributing them as intended.
Evidence: In _processTax(uint256), the contract calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount) inside try/catch. In the catch branch it reads balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance). Before processing, it may set allowance(address(this), taxProcessor) to type(uint256).max. taxProcessor is assigned during initialize and has no post-initialization setter.
Recommendation: Use a tightly controlled processor address, avoid transferring the entire balance on failure, isolate failed amounts, and add governance-controlled recovery with explicit limits and events. Consider revoking or bounding allowances after each operation and add tests for malicious or reverting processors.
medium finding: Dividend integration can block token transfers
If dividendContract is nonzero, every transfer involving a non-exempt sender or recipient calls the external dividend contract’s setShare function. Any revert from that call is propagated as DividendShareUpdateFailed, reverting the complete token transfer. A misconfigured, unavailable, or adversarial dividend contract can therefore create a transfer-denial condition for affected accounts.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) for addresses not excluded by the contract’s skip conditions. Each call is wrapped in try/catch, but the catch explicitly reverts with DividendShareUpdateFailed. dividendContract is set by initialize and has no setter.
Recommendation: Prevent a nonessential dividend update from reverting core ERC20 transfers. Use a failure-tolerant queue or best-effort update path, add circuit breakers, and validate the dividend contract during initialization.
medium finding: Owner controls migration states that restrict pool transfers
The owner alone controls startMigration and finalizeMigration. While the token remains in BondingCurve, transfers to or from any configured pool revert. The owner can therefore delay migration indefinitely and keep pool interactions restricted until the owner advances the state.
Evidence: startMigration and finalizeMigration are both external onlyOwner functions. In _transfer, the BondingCurve branch requires !pools[from] && !pools[to], reverting with "Transfers to/from pools are restricted in BondingCurve state". No permissionless or time-based transition can advance the state.
Recommendation: Use a transparent, time-bounded migration process with publicly verifiable conditions, a fallback transition mechanism, and governance or multisignature control rather than a single owner account.