TEARDOWN (TEARDOWN) security report
Radar by SecureChain AI scanned the verified TEARDOWN contract on BNB Smart Chain. The report identifies owner-controlled migration restrictions, a dividend callback denial-of-service risk, and missing tax-rate bounds. Slither was not run.
The source does not show an unrestricted mint function, blacklist, proxy upgrade mechanism, or selfdestruct path. However, the owner controls migration progression, and the contract contains external callback dependencies that can create meaningful transfer or trading restrictions.
Trust score: 48/100. Source verified: Yes. Chain: bsc. Contract: 0x946ce92d960c878e08c165f82cd7871ca8ef7777.
This report was last modified on 2026-10-12 and contains 3 material findings.
high finding: Owner can indefinitely prevent pool transfers by withholding migration
The owner controls the only functions that move the token out of BondingCurve state. While that state remains active, every transfer involving a configured pool reverts, preventing buys, sells, and other pool interactions until the owner calls startMigration and finalizeMigration.
Evidence: In _transfer, PoolState.BondingCurve requires !pools[from] && !pools[to], otherwise it reverts with "Transfers to/from pools are restricted in BondingCurve state". Both startMigration() and finalizeMigration() use onlyOwner. There is no permissionless timeout or automatic transition out of BondingCurve.
Recommendation: Use an immutable or permissionless migration schedule, enforce a bounded bonding-curve period, and publish the configured pool and migration parameters. Add safeguards so owner-controlled state cannot indefinitely block pool transfers.
medium finding: Dividend callback failure can block ordinary token transfers
When dividendContract is configured, ordinary transfers invoke setShare for the sender and recipient. Any revert from that external contract is caught and converted into DividendShareUpdateFailed, causing the entire token transfer to revert.
Evidence: _afterTokenTransfer calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) for non-exempt addresses. Each failed call executes revert DividendShareUpdateFailed(...). The dividendContract address is supplied during initialize and there is no fallback path that permits the transfer to continue.
Recommendation: Do not make transfer settlement depend on a reverting external callback. Consider non-blocking share accounting, bounded gas or failure isolation, administrative recovery with strict controls, and thorough validation of the dividend implementation before initialization.
medium finding: Initialization permits tax rates that can make pool transfers revert
The initializer accepts uint16 buy and sell tax rates without enforcing a maximum of 10000 basis points. If a configured rate exceeds 10000, the calculated tax can exceed the transfer amount and arithmetic in _taxedTransfer reverts whenever that tax path is used.
Evidence: initialize stores params.buyTax and params.sellTax directly in poolState. _getTaxWithPoolState calculates amount * rate / 10000, while _taxedTransfer computes uint256 remainingAmount = amount - tax. A uint16 value may exceed 10000, so the subtraction can underflow and revert for pool-involved transfers.
Recommendation: Require buyTax and sellTax to be at most 10000 basis points during initialization, validate all pool addresses, and test buy and sell execution across boundary values before deployment.