Radar by SecureChain AI

AFTER TEN (AFTER TEN) security report

SecureChain AI scanned the verified AFTER TEN contract on BSC and reviewed GoPlus and Slither evidence. No Critical or High findings were identified. The scan does not guarantee safety.

The contract was AI scanned and no Critical or High findings were identified. The main material risks are centralized launch-state control, approximately 70.65% ownership by the reported owner, and transfer availability depending on the configured dividend contract and tax settings. GoPlus reports no proxy, minting, blacklist, pause, or honeypot signal, while Slither reported no material findings.

Trust score: 62/100. Source verified: Yes. Chain: bsc. Contract: 0x3ad3d5536d4393d5649855292e78c3504e1b7777.

This report was last modified on 2026-09-29 and contains 5 material findings.

medium finding: Owner controls migration and pool-trading availability

The owner exclusively controls startMigration() and finalizeMigration(). While the token remains in BondingCurve state, transfers to or from every configured pool revert, so pool trading depends on owner-controlled state transitions.

Evidence: _transfer() requires !pools[from] && !pools[to] in BondingCurve state. startMigration() and finalizeMigration() are both external onlyOwner functions. GoPlus reports owner_address as 0xe2ce6ab80874fa9fa2aae65d277dd6b8e65c9de0 and is_in_dex as 0.

Recommendation: Verify that migration and finalization are governed by a transparent launch process or timelock, and monitor PoolStateChanged events before relying on pool trading.

medium finding: Configured dividend contract can make ordinary transfers revert

If dividendContract is nonzero, every transfer involving a normal holder calls setShare() for the sender and/or recipient. Any revert from that external contract is propagated as DividendShareUpdateFailed, preventing the token transfer from completing.

Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(...) and reverts in both catch blocks. dividendContract is assigned during initialize() and there is no public setter in the supplied contract.

Recommendation: Verify the deployed dividend contract, its authorization for this token, and its failure behavior. Add a controlled fallback or disable mechanism in future versions so dividend accounting failure cannot globally block transfers.

medium finding: Initialization permits tax rates capable of reverting all pool trades

The initializer accepts uint16 buyTax and sellTax values without enforcing a maximum of 10000 basis points. If a configured tax exceeds 100%, _taxedTransfer() calculates remainingAmount = amount - tax and reverts, making the affected buy or sell path unavailable while the tax state applies.

Evidence: initialize() stores params.buyTax and params.sellTax directly. _getTaxWithPoolState() calculates amount * taxRate / 10000, and _taxedTransfer() subtracts that tax from amount without a rate bound. The supplied GoPlus tax fields are empty, so the deployed rates were not independently confirmed here.

Recommendation: Verify the deployed buyTaxRate() and sellTaxRate() values. Enforce buy and sell rates <= 10000 in the initializer and test every configured pool path before launch.

medium finding: Tax processor is a trusted external custody and failure path

Collected tax tokens are approved to taxProcessor with an effectively unlimited allowance. If processTaxTokens() reverts, the catch branch transfers the entire token balance held by this contract to taxProcessor, rather than preserving the balance for later processing.

Evidence: _processTax() sets allowance(address(this), taxProcessor) to type(uint256).max and calls the external processor. On failure, it executes _plainTransfer(address(this), taxProcessor, remainingBalance). taxProcessor is set during initialize() and has no setter in the supplied contract.

Recommendation: Verify the deployed taxProcessor implementation and administrative controls, restrict fallback transfers to a clearly documented recovery policy, and monitor TaxLiquidationError and token movements to the processor.

medium finding: Dividend and tax integrations create external-call availability dependencies

Token transfers can invoke both the dividend contract and, on qualifying sells, the tax processor. These dependencies increase the conditions under which transfers can fail and make availability dependent on independently deployed contracts.

Evidence: _afterTokenTransfer() performs external setShare() calls and reverts on failure. _liquidateTax() can call _processTax(), which invokes ITaxProcessor(taxProcessor).processTaxTokens(). Slither reported no material findings, but its empty result does not validate the external integrations' deployed behavior.

Recommendation: Test transfers against the exact deployed integration addresses, include failure-mode monitoring, and provide operational recovery procedures for processor or dividend-contract outages.