On-chain security analysis — is it a scam or legit?
BNB ChainThe FOOToken contract is an ERC-20 compatible token with several owner-controlled features.
Read the full analysisEach factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed
Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.
Holder balances as recorded by the audit of Oct 15, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x0c0c…23820x5bcb…22e40x9229…a52a0x3360…1e050xced3…31cd0xf3a6…dd770x9786…9c030x86c6…2d940xdcd2…1551No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
revenueWallet address using the setRevenueWallet function. This revenueWallet is critical because it can influence how token transfers are processed, potentially redirecting fees or affecting other token logic. This means a single owner can unilaterally alter a fundamental aspect of the token's operation.CP-03The owner of the FOOToken contract has the ability to change the revenueWallet address using the setRevenueWallet function. This revenueWallet is critical because it can influence how token transfers are processed, potentially redirecting fees or affecting other token logic. This means a single owner can unilaterally alter a fundamental aspect of the token's operation.
Token holders should be aware that the owner can change the revenueWallet at any time, which could impact how their tokens are handled or if any fees are collected. For enhanced security and trust, consider implementing a multi-signature wallet or a time-lock for such critical changes, giving token holders more transparency and control.
Unresolved
blacklist using the addToBlacklist function. Conversely, they can remove addresses from this blacklist using removeFromBlacklist. This gives the owner the power to unilaterally freeze or unfreeze any token holder's assets.CP-06The owner of the FOOToken contract can prevent specific addresses from transferring or selling their tokens by adding them to a blacklist using the addToBlacklist function. Conversely, they can remove addresses from this blacklist using removeFromBlacklist. This gives the owner the power to unilaterally freeze or unfreeze any token holder's assets.
Token holders should understand that the owner has the power to block their ability to move tokens. To reduce this centralized risk, consider implementing a decentralized governance mechanism or requiring a multi-signature approval for blacklisting actions, which would provide greater community oversight and protection against arbitrary actions.
Unresolved
37.0% of the pool's LP is burned or time-locked. 37.0% is locked in PinkLock02 until 30 Jun 2028 (624 days). Until then nobody — the project included — can withdraw it unless the locker contract itself is flawed; after that date the lock's owner can. 2.6% is held, unlocked, by 9 address(es) other than the owner/deployer. No single one holds a majority: their exits thin the market rather than hand anyone the pool. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them.
Check the lock's end date and beneficiary on the locker's own page before relying on it.
Acknowledged
_transfer function, which is called by transfer and transferFrom, might be vulnerable to a reentrancy attack. This occurs when an external call is made before the contract's state (like balances) is fully updated. A malicious contract could re-enter the _transfer function multiple times before the initial call completes, potentially leading to incorrect balance deductions or other unintended behavior.CD-01The _transfer function, which is called by transfer and transferFrom, might be vulnerable to a reentrancy attack. This occurs when an external call is made before the contract's state (like balances) is fully updated. A malicious contract could re-enter the _transfer function multiple times before the initial call completes, potentially leading to incorrect balance deductions or other unintended behavior.
While the direct impact on token holders might be limited without further context on _transfer's internal logic, this type of vulnerability can be exploited in complex scenarios. The project team should ensure that all state changes are completed *before* any external calls are made within the _transfer function to prevent reentrancy.
Unresolved
The ten largest holders own 21.9% of supply. Of that, 17.6% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 4.3% in wallets, 0.0% in other contracts. 8,788 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
Listed on CoinGecko as Football Genie (FOO), rank #4218. 8,788 holders.
Match the contract address against the project's official channels before trading.
Acknowledged
Liquidity $100K (DexScreener, all pools). 24h trading volume $46K (CoinGecko, all markets, daily snapshot). 24h trading volume $46K (DexScreener, all pools).
Size any position to the liquidity and daily volume shown — they set how much you can sell and at what price.
Acknowledged
A token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: fixed — the contract has no mint function. Control: a single wallet (EOA). Code: not upgradeable (no proxy). Fees: 2.5% on buy, 2.5% on sell. Market: $100K of DEX liquidity across 1 pools. Launch: 285 days of market history.
Check the project's own documentation for what the token is used for; this report covers what the contract allows.
Acknowledged
The FOOToken contract is an ERC-20 compatible token with several owner-controlled features. While it implements standard token functionalities, the audit identified significant centralization risks, including the owner's ability to control critical transfer parameters and blacklist users. A low-severity reentrancy vulnerability was also noted. The contract is not upgradeable.
The FOOToken contract implements core ERC-20 functionalities such as balanceOf, transfer, transferFrom, approve, and allowance. It includes emergency withdrawal functions (emergencyWithdraw, emergencyWithdrawToken) to protect funds. Access control for critical functions is properly enforced using onlyOwner (7.3 Access Control). However, the contract exhibits high centralization, with the owner having extensive control over transfer logic, including the ability to change the revenueWallet (CP-03) and blacklist users (CP-06). A reentrancy vulnerability was identified in the _transfer function (CD-01), where state updates occur after an external call (7.2 Code Security).
The contract's governance model is straightforward, with a single owner controlling all privileged operations, which can simplify decision-making and execution. The owner can manage whitelists, blacklists, and swap pairs, offering flexibility in tokenomics (7.5 Governance). This centralized control introduces significant governance and economic risks. The owner can unilaterally block token holders from transferring their tokens via addToBlacklist (CP-06) and can redirect token flow by changing the revenueWallet (CP-03), potentially impacting token value and user trust (7.4 Economic). The owner also has the power to withdraw any ETH or ERC-20 tokens held by the contract (7.8 Operations).
The FOOToken contract is not designed as an upgradeable proxy, which eliminates the complexities and potential risks associated with upgrade mechanisms, such as proxy implementation mismatches or upgrade path vulnerabilities (7.7 Upgrades). As a non-upgradeable contract, any discovered critical vulnerabilities or desired feature enhancements would necessitate a new contract deployment and a token migration process, which can be costly and disruptive for token holders (7.7 Upgrades).
Address the reentrancy vulnerability in _transfer by implementing checks-effects-interactions pattern or using a reentrancy guard.
Consider decentralizing critical administrative functions, such as blacklisting and setting the revenue wallet, by implementing a multi-signature wallet or a time-locked governance mechanism to reduce single points of failure and enhance trust. Review the necessity and scope of the owner's extensive control over transfer logic and emergency withdrawal functions, and explore options for community oversight or time-locks where appropriate.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
