BTC18 (BTC18) security report
Radar AI scanned BTC18 on BNB Smart Chain. The review found a conditional initialization takeover risk, dividend callback transfer failures, and launch-state pool restrictions.
BTC18 has no confirmed active honeypot or owner-controlled mint path in the supplied GoPlus evidence, but the source contains a conditional high-severity initialization takeover risk and medium-severity transfer availability risks. The initializer must be atomically called by the intended deployer or factory, and the configured dividend contract should be reviewed and tested for failure behavior.
Trust score: 58/100. Source verified: Yes. Chain: bsc. Contract: 0x8ce6f0fd88088f872944668ecbcdff6ed4537777.
This report was last modified on 2026-11-04 and contains 3 material findings.
high finding: Unrestricted initializer can allow takeover of an uninitialized deployment
The external initialize function is protected only by OpenZeppelin's one-time initializer guard; it has no factory, deployer, or signature authorization. The first caller controls token configuration and receives the entire initial supply. If a proxy or clone is deployed without initialization in the same transaction, an arbitrary caller can initialize it, become owner, configure external addresses, and receive the maxSupply mint.
Evidence: src/Tax/FlapTaxTokenV3.sol: initialize(InitParams memory params) is external and uses only initializer. It calls __Ownable_init(), which sets the owner to _msgSender(), and then executes _mint(msg.sender, maxSupply). The function also accepts taxProcessor, dividendContract, pools, router, and other operational parameters from that first caller.
Recommendation: Atomically initialize every proxy or clone during deployment, or restrict initialization to an authorized factory and validate all configuration addresses. Monitor deployment tooling to ensure no externally callable initialization window exists.
medium finding: External dividend callback can make ordinary transfers revert
When dividendContract is configured, transfers involving non-excluded addresses synchronously call dividendContract.setShare. Any revert from that external call reverts the entire token transfer. A broken, incompatible, paused, or malicious dividend contract can therefore block ordinary transfers involving affected addresses.
Evidence: src/Tax/FlapTaxTokenV3.sol: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks. The catch blocks explicitly revert with DividendShareUpdateFailed. The callback is skipped only for zero/dead addresses, the token contract, dividendContract, and configured pools.
Recommendation: Use a non-blocking share-update design, queue failed updates, or provide a controlled recovery path that can disable callbacks. Validate the dividend implementation and test failure, gas, and upgrade scenarios before enabling it.
medium finding: BondingCurve state intentionally blocks transfers involving configured pools
While the token remains in BondingCurve state, every transfer from or to an address marked in pools reverts. This can prevent buys, sells, liquidity operations, or integrations from functioning until the owner completes the migration sequence. The restriction is a material operational and transfer-availability dependency.
Evidence: src/Tax/FlapTaxTokenV3.sol: _transfer checks if currentState == PoolState.BondingCurve and requires !pools[from] && !pools[to], reverting with "Transfers to/from pools are restricted in BondingCurve state". Only the owner can move the state through startMigration and finalizeMigration.
Recommendation: Document the launch-state requirements, verify the configured pool addresses, and use an independently controlled migration process with monitoring and rollback procedures. Consider safeguards against leaving the token indefinitely in BondingCurve state.