AICODE (AICODE) security report
SecureChain AI scanned the verified AICODE source and GoPlus evidence. Slither was not run. No token-level mint, blacklist, pause, proxy, or transfer-tax backdoor was identified.
The verified token contract does not expose an obvious mint, blacklist, pause, confiscation, or transfer-tax backdoor. However, the broader launch system is not risk-free: the owner controls launch-time trading fees and fee routing, the external hook source was not supplied, and staking rewards can be permanently locked by extreme launch parameters.
Trust score: 58/100. Source verified: Yes. Chain: ethereum. Contract: 0x13697195bd7d5e6c6160f94faf3e84a7f709f62d.
This report was last modified on 2026-09-29 and contains 3 material findings.
high finding: External hook controls effective trading fees and sell behavior
AICODE trading is performed through an external Uniswap v4 hook selected by the owner before launch. The launch configuration permits a feeStart of up to 99%, a feeEnd of up to 10%, and sellBurnBps of up to 5%. The supplied source does not include the hook implementation, so the exact enforcement and behavior cannot be independently verified.
Evidence: AirdropLaunch.setHook() allows the owner to set the hook once. launch() accepts Curve values with MAX_FEE_START = 990000, MAX_FEE_END = 100000, and MAX_SELL_BURN = 500. poolKeyOf() embeds the selected hook, while currentFee() and sellBurnBps() expose values intended to be read by that hook. The GoPlus sell_tax is 0, but it does not evaluate Uniswap v4 pool-hook fees.
Recommendation: Publish and independently audit the deployed hook implementation, verify its immutable address and registration state, and disclose the maximum initial fee and sell-burn behavior prominently before trading. Users should verify the live hook and current fee on-chain.
medium finding: Owner can redirect future protocol fee proceeds
The owner can replace feeWallet at any time. This does not directly confiscate user token balances, but it gives centralized control over ETH collected from liquidity fees and creates a trust dependency for future fee distributions.
Evidence: AirdropLaunch.setFeeWallet(address w) is protected only by onlyOwner and has no timelock, multisig requirement, or one-time restriction. claimFees() sends collected ETH to the current feeWallet, with failed transfers credited to ethOwed[feeWallet].
Recommendation: Use a multisig or governance-controlled fee wallet, add a timelock and transparent event monitoring, and document that collected fees are payable to the owner-selected wallet.
medium finding: Staking reserve can be permanently stranded by launch parameters
The staking reserve is streamed using integer division. If the configured duration exceeds the reserve amount in base units, reserveRate becomes zero and no rewards are distributed. Even when nonzero, division remainder is not recoverable by users. There is no rescue or rollover mechanism for undistributed reserve tokens.
Evidence: Staking.startReserve() sets reserveRate = amount / secondsLong and reserveEnd = block.timestamp + secondsLong. AirdropLaunch.launch() only requires stakeDays > 0 when a staking remainder exists and imposes no upper bound on stakeDays. The staking contract has no function to withdraw undistributed reserve tokens after reserveEnd.
Recommendation: Require amount >= secondsLong, cap stakeDays to a practical range, account for division remainders, and provide a governed recovery or rollover path for undistributed reserve tokens.