蘑菇头和我的16年 (蘑菇头) security report
Radar AI scanned the verified BSC source and reviewed GoPlus evidence. No obvious mint, blacklist, proxy, or honeypot behavior was identified. Material risks involve unlimited tax-processor approval, dividend callback transfer reverts, and safe initialization requirements. Slither was not run.
The contract does not show an obvious mint, blacklist, adjustable-tax, or honeypot mechanism in the supplied source. However, tax processing and dividend accounting depend on external contracts that can materially affect fee custody and transfer availability.
Trust score: 78/100. Source verified: Yes. Chain: bsc. Contract: 0x681234b574ac190eaf58bb12a5d61fb29bb07777.
This report was last modified on 2026-09-26 and contains 3 material findings.
medium finding: Tax processor receives unlimited approval over accumulated tax tokens
During tax liquidation, the token approves the configured taxProcessor for type(uint256).max and calls its external processTaxTokens function. A compromised or incorrectly configured processor can use that allowance to pull token balances held by the token contract, including accumulated tax tokens. On processing failure, the fallback also transfers the remaining token-contract balance directly to taxProcessor.
Evidence: _processTax() executes _approve(address(this), taxProcessor, type(uint256).max) when the allowance is insufficient, then calls ITaxProcessor(taxProcessor).processTaxTokens(taxAmount). Its catch branch calls _plainTransfer(address(this), taxProcessor, remainingBalance). The taxProcessor address is supplied through initialize() and has no setter or on-chain governance control in this token.
Recommendation: Use narrowly scoped approvals or approve only the current tax amount, validate the processor implementation and configuration, and consider a timelocked or governed processor update mechanism in the deployment architecture. Monitor processor allowance usage and unexpected token withdrawals.
medium finding: External dividend callback can block token transfers
Every transfer involving a non-excluded account invokes dividendContract.setShare. If either callback reverts, the token transfer reverts through DividendShareUpdateFailed. A failure, malicious behavior, or incompatibility in the configured dividend contract can therefore prevent ordinary transfers and potentially block buys or sells that update user shares.
Evidence: _afterTokenTransfer() calls IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) inside try/catch blocks; each catch executes revert DividendShareUpdateFailed(...). The dividendContract is assigned during initialize() and cannot be changed by this token.
Recommendation: Decouple balance transfers from dividend accounting, or make share updates non-blocking with deferred reconciliation. Add failure isolation, gas limits, and an emergency disable or replacement mechanism controlled by a timelock or governance.
medium finding: Initialization must be atomic to prevent supply capture on clone deployments
The public initializer mints the entire fixed supply to msg.sender. If a clone or proxy instance is deployed without initialize() being executed atomically, the first caller can initialize the token and receive the complete maxSupply, while also selecting the tax processor, dividend contract, pools, taxes, and migration parameters.
Evidence: initialize(InitParams) is external and protected only by the one-time initializer modifier. It executes _mint(msg.sender, maxSupply) and assigns configuration directly from params. The constructor disables initialization only on the implementation contract, not on a separate proxy or clone storage context.
Recommendation: Deploy clones with initializer calldata in the same transaction, verify initialization state before exposure, and use a factory that prevents uninitialized instances from remaining callable. Confirm the deployed address is initialized before funding or listing it.