币安人 (币安人) security report
Radar by SecureChain AI scanned the verified 币安人 contract source on BNB Smart Chain. Material findings include an unprotected deployment-time initializer, uncapped buy and sell tax parameters that can revert pool trades, and external dividend and tax-processing dependencies. Slither was not run; the assessment combines independent source review with supplied GoPlus evidence.
The reviewed source contains a high-severity initialization risk, a high-severity unrestricted tax-configuration risk, and a medium-severity transfer availability risk involving the external dividend contract. These issues depend on deployment configuration or lifecycle state; the supplied GoPlus signals do not independently validate the source-level controls.
Trust score: 48/100. Source verified: Yes. Chain: bsc. Contract: 0xa754740dbaf8c116a2c351dd64462dfaf58d7777.
This report was last modified on 2026-10-14 and contains 4 material findings.
high finding: Uninitialized clone can be claimed by an arbitrary caller
The external initialize function is protected only by the one-time initializer guard and has no factory, deployer, or caller authorization. If a proxy or clone is deployed without initialization in the same transaction, an arbitrary caller can initialize it, become owner through __Ownable_init(), set the tax and integration addresses, and receive the entire maxSupply mint.
Evidence: FlapTaxTokenV3.initialize(InitParams memory params) is external and uses only the initializer modifier. It calls __Ownable_init(), which assigns ownership to _msgSender(), and then executes _mint(msg.sender, maxSupply). No authorized initializer or factory check is present.
Recommendation: Initialize every proxy or clone atomically at deployment, or restrict initialization to an authorized factory and verify the initialized owner and integration addresses before enabling trading.
high finding: Initializer can set buy or sell tax above 100%, reverting pool trades
The initialization parameters accept uint16 tax rates without a maximum check. A rate above 10000 basis points makes tax exceed the transfer amount for sufficiently ordinary trades, causing amount - tax in _taxedTransfer to revert. Once the relevant tax state is active, this can block buys or sells involving configured pools and create a honeypot-like transfer restriction.
Evidence: initialize stores params.buyTax and params.sellTax directly in poolState without requiring either value to be at most 10000. _getTaxWithPoolState calculates amount * rate / 10000, while _taxedTransfer executes uint256 remainingAmount = amount - tax; Solidity 0.8 arithmetic reverts when tax exceeds amount.
Recommendation: Enforce buyTax and sellTax <= 10000 during initialization, preferably with a lower protocol-specific cap, and test all pool states and boundary values before deployment.
medium finding: External dividend hook can block token transfers
When dividendContract is nonzero, ordinary transfers invoke an external setShare call for the sender and recipient. Any revert from that contract is converted into DividendShareUpdateFailed and reverts the entire token transfer. Because initialize accepts an arbitrary dividendContract without checking code or behavior, a misconfigured, unavailable, or incompatible dividend contract can make transfers fail broadly.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) for non-exempt addresses. Each call is wrapped in try/catch that reverts with DividendShareUpdateFailed on failure. initialize assigns dividendContract = params.dividendContract without validation.
Recommendation: Validate the dividend contract during initialization, use a non-blocking integration or explicit fallback mode for share updates, and add operational controls and tests for dividend-contract failure.
medium finding: Tax processing depends on a privileged external processor
Tax liquidation approves the configured taxProcessor for an effectively unlimited allowance and calls its processTaxTokens function. If processing fails, the token contract transfers its entire accumulated token balance to taxProcessor. The processor address is supplied during initialization and there is no setter or on-chain validation in this contract, so incorrect configuration or unsafe processor behavior can redirect or strand tax proceeds.
Evidence: _processTax sets allowance(address(this), taxProcessor) to type(uint256).max when needed and calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). In the catch branch it transfers balanceOf(address(this)) to taxProcessor with _plainTransfer(address(this), taxProcessor, remainingBalance).
Recommendation: Use an immutable, audited processor selected by an authorized factory, cap approvals where practical, limit fallback transfers to the intended tax amount, and add explicit recovery and failure-handling procedures.