招财猫 (招财猫) security report
Radar AI scanned the verified 招财猫 contract on BNB Smart Chain. GoPlus found no honeypot, blacklist, proxy, or minting signal, but source review identified tax-processor custody risk, transfer denial-of-service through dividend callbacks, and a possible permanent migration lock after ownership renunciation. Slither was not run.
The verified contract does not expose an owner mint function, blacklist, adjustable tax setter, or proxy upgrade function. However, the configured tax processor receives an unlimited token allowance and can control tax-token handling, dividend-contract failures can revert transfers, and GoPlus reports ownership is currently renounced. If migration has not been finalized, renunciation can permanently prevent pool trading transitions.
Trust score: 58/100. Source verified: Yes. Chain: bsc. Contract: 0xc442d2a44dbeaae902765d527839327489487777.
This report was last modified on 2026-09-30 and contains 3 material findings.
high finding: Tax processor receives unlimited allowance and can control all contract-held tax tokens
The token automatically approves taxProcessor for type(uint256).max whenever its allowance is insufficient. The processor can therefore call transferFrom on the token contract and move the entire token balance held by the token contract, not only newly accrued tax. If processTaxTokens fails, the fallback explicitly transfers the remaining contract balance to taxProcessor.
Evidence: In _processTax(), the contract executes _approve(address(this), taxProcessor, type(uint256).max). In the catch branch, it calculates balanceOf(address(this)) and calls _plainTransfer(address(this), taxProcessor, remainingBalance). The taxProcessor address is supplied during initialize() and is not changeable through the exposed ABI.
Recommendation: Verify the deployed taxProcessor implementation and governance. Replace unlimited approval with exact-amount approvals, restrict fallback transfers to the intended taxAmount, and add explicit accounting so unrelated tokens held by the token contract cannot be swept.
medium finding: Dividend callback failure can block token transfers
Every qualifying transfer invokes the configured dividend contract through setShare(). Any revert from that external call is caught and converted into DividendShareUpdateFailed, reverting the entire token transfer. A broken, paused, incompatible, or malicious dividend contract can therefore create a transfer denial-of-service for affected accounts.
Evidence: In _afterTokenTransfer(), IDividend(dividendContract).setShare(from, balanceOf(from)) and setShare(to, balanceOf(to)) are called. Each catch block executes revert DividendShareUpdateFailed(...). dividendContract is assigned during initialize() and has no setter in the exposed ABI.
Recommendation: Use a non-blocking dividend update pattern, isolate share accounting from ERC20 transfers, or provide a controlled recovery mechanism. Validate the dividend implementation and test behavior when setShare reverts or runs out of gas.
medium finding: Renounced ownership can permanently prevent migration from BondingCurve state
Pool transfers are explicitly prohibited while the pool state is BondingCurve. Only the owner can call startMigration() and finalizeMigration(). GoPlus reports owner_address as the zero address, so if the deployed instance remains in BondingCurve, no account can advance it to a trading state and transfers to or from configured pools remain blocked.
Evidence: _transfer() requires !pools[from] && !pools[to] in PoolState.BondingCurve. startMigration() and finalizeMigration() both use onlyOwner. Supplied GoPlus evidence reports owner_address=0x0000000000000000000000000000000000000000 and owner_balance=0.
Recommendation: Confirm the deployed poolState before renouncing ownership. If renunciation is intended, finalize migration first and document the irreversible state transition. Add an immutable, verifiable launch-state check to deployment procedures.