Bnb大涨，币安链能飞 (币安链能飞) security report
Radar by SecureChain.ai AI-scanned the verified BSC source and reviewed GoPlus evidence. No critical or high finding was confirmed. Medium risks include external tax-processor custody, transfer failures caused by dividend callbacks, and unchecked initialization tax limits. Slither was not run.
The contract was AI-scanned using the verified source, ABI, and supplied GoPlus evidence. No critical or high finding was confirmed. Medium-risk findings concern the trusted tax processor, dividend callback availability, and unchecked initialization tax limits. GoPlus reports is_honeypot=0, is_mintable=0, is_blacklisted=0, is_proxy=0, and owner_address=0x0000000000000000000000000000000000000000.
Trust score: 64/100. Source verified: Yes. Chain: bsc. Contract: 0x7731bf9ee2f367a5a563a34e5b610c14f75b7777.
This report was last modified on 2026-09-30 and contains 4 material findings.
medium finding: External tax processor has broad custody over accumulated tax tokens
The token approves the configured taxProcessor for an effectively unlimited allowance and invokes it to process accumulated tax tokens. If processing reverts, the fallback sends the entire token balance held by the token contract—not only the current tax amount—to taxProcessor. A compromised or misconfigured processor could therefore control or receive accumulated tax inventory.
Evidence: In _processTax(), the contract sets _approve(address(this), taxProcessor, type(uint256).max) when needed, then calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). In the catch branch it executes _plainTransfer(address(this), taxProcessor, remainingBalance), where remainingBalance is balanceOf(address(this)). taxProcessor is supplied during initialize() and cannot be changed through an exposed setter.
Recommendation: Use a narrowly scoped allowance, transfer only the current taxAmount in the failure path, and add an emergency recovery or timelocked processor replacement mechanism. Validate the processor implementation and monitor its allowance and withdrawals.
medium finding: Dividend callback failures can block ordinary token transfers
When dividendContract is configured, every transfer involving a non-excluded address calls dividendContract.setShare(). Any revert from that external callback causes the entire token transfer to revert. A broken, paused, malicious, or incompatible dividend contract can therefore create a transfer-lock condition for users whose addresses are not excluded.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks. The catch branches explicitly revert with DividendShareUpdateFailed. The callback is reached from _transfer(), including regular wallet-to-wallet transfers and taxed transfers.
Recommendation: Do not make balance transfers dependent on dividend bookkeeping. Consider non-blocking callbacks, a pull-based share update model, bounded failure handling, or an owner/timelocked method to disable or replace a malfunctioning dividend contract.
medium finding: Initialization accepts tax rates above 100%, which can make pool transfers revert
The initialization parameters use uint16 buyTax and sellTax values but do not enforce a maximum of 10,000 basis points. For a rate above 100%, _taxedTransfer() computes tax greater than amount and amount - tax reverts under Solidity 0.8 arithmetic. If such values were supplied at initialization, buys or sells involving configured pools could be unusable during the tax-enforced states.
Evidence: initialize() stores params.buyTax and params.sellTax directly in poolState without a <=10000 check. _getTaxWithPoolState() computes (amount * rate) / 10000, while _taxedTransfer() executes uint256 remainingAmount = amount - tax. GoPlus supplied blank buy_tax, sell_tax, and transfer_tax fields, so the deployed rates were not established by the supplied evidence.
Recommendation: Enforce buyTax <= 10000 and sellTax <= 10000 during initialization, and add deployment-time assertions and monitoring for the stored rates. Verify the live poolState rates before treating this as an active deployed condition.
medium finding: Owner-controlled migration state can restrict pool transfers before ownership renunciation
While poolState is BondingCurve, all transfers to or from any configured pool revert. The owner alone can call startMigration() and finalizeMigration() to move the token through migration and tax-enforced states. This is a centralized launch and transfer control before ownership is renounced or otherwise governed.
Evidence: _transfer() requires !pools[from] && !pools[to] in BondingCurve. startMigration() and finalizeMigration() are both onlyOwner. GoPlus reports owner_address as the zero address and can_take_back_ownership=0, so the supplied evidence does not establish that this control is currently exercisable; the risk applies to the pre-renunciation lifecycle or any deployment where ownership remains active.
Recommendation: Do not rely solely on ownership renunciation without independently confirming the deployed state.