On-chain security analysis — is it a scam or legit?
The Fun token contract implements a standard ERC20 token with UUPS upgradeability and OpenZeppelin's AccessControl.
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 Sep 4, 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.
0x8815…288b0xe24d…c94aNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
initialize function mints the entire MAX_SUPPLY (1,000,000,000 * 1e18 tokens) to the owner address. This grants the initial owner complete control over the token's distribution and market dynamics, posing a significant centralization risk. A single entity holds all tokens, which could lead to market manipulation or a lack of trust from the community (7.4 Economic).H-01The initialize function mints the entire MAX_SUPPLY (1,000,000,000 * 1e18 tokens) to the owner address. This grants the initial owner complete control over the token's distribution and market dynamics, posing a significant centralization risk. A single entity holds all tokens, which could lead to market manipulation or a lack of trust from the community (7.4 Economic).
Implement a more decentralized token distribution strategy. Consider vesting schedules, community airdrops, or a gradual release mechanism instead of minting the entire supply to a single address. If the current design is intentional, clearly communicate this centralization to users.
Unresolved
owner address is granted both DEFAULT_ADMIN_ROLE and GOVERNOR_ROLE. The DEFAULT_ADMIN_ROLE can manage all other roles, including GOVERNOR_ROLE, which is responsible for authorizing contract upgrades. This setup creates a single point of failure: if the owner's private key is compromised, an attacker would gain full administrative control over the contract, including the ability to upgrade it to malicious code and manage all roles (7.3 Access Control, 7.5 Governance, 7.7 Upgrades).H-02During initialization, the owner address is granted both DEFAULT_ADMIN_ROLE and GOVERNOR_ROLE. The DEFAULT_ADMIN_ROLE can manage all other roles, including GOVERNOR_ROLE, which is responsible for authorizing contract upgrades. This setup creates a single point of failure: if the owner's private key is compromised, an attacker would gain full administrative control over the contract, including the ability to upgrade it to malicious code and manage all roles (7.3 Access Control, 7.5 Governance, 7.7 Upgrades).
Transfer DEFAULT_ADMIN_ROLE and GOVERNOR_ROLE to a multi-signature wallet or a DAO governance system. This decentralizes control and requires multiple approvals for critical operations, significantly reducing the risk associated with a single compromised key.
Unresolved
_mint is used once during initialization, there is no corresponding _burn function or a mechanism to reduce the total supply after initial minting. This might be an intentional design choice, but it limits flexibility for supply management, such as implementing deflationary mechanisms or burning tokens from a treasury (7.4 Economic).M-01The contract does not provide an explicit function for burning tokens. While _mint is used once during initialization, there is no corresponding _burn function or a mechanism to reduce the total supply after initial minting. This might be an intentional design choice, but it limits flexibility for supply management, such as implementing deflationary mechanisms or burning tokens from a treasury (7.4 Economic).
If a burn mechanism is desired for future tokenomics or supply management, consider adding a burn function, potentially restricted by a role (e.g., GOVERNOR_ROLE), that calls _burn from the ERC20Upgradeable base contract. If not desired, document this design choice.
Unresolved
PausableUpgradeable) to halt token transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market disruption. While not always strictly necessary, a pause function can be a valuable tool for mitigating risks in a centralized token system (7.8 Operations).L-01The contract does not include a pause mechanism (e.g., PausableUpgradeable) to halt token transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market disruption. While not always strictly necessary, a pause function can be a valuable tool for mitigating risks in a centralized token system (7.8 Operations).
Consider integrating OpenZeppelin's PausableUpgradeable module. This would allow a designated role (e.g., GOVERNOR_ROLE or a new PAUSER_ROLE) to temporarily pause and unpause contract functionality, providing an emergency stop-gap measure.
Unresolved
The Fun token contract implements a standard ERC20 token with UUPS upgradeability and OpenZeppelin's AccessControl. While leveraging well-audited libraries, the contract exhibits significant centralization risks. The entire token supply is minted to a single owner address, which also holds all administrative and upgrade roles. This creates a critical single point of failure for both economic control and contract integrity.
The contract is built upon well-audited OpenZeppelin Upgradeable libraries for ERC20, AccessControl, and UUPS, contributing to high code security and architectural soundness (7.1 Architecture, 7.2 Code Security). The initialize function correctly sets up the token and roles, and _disableInitializers prevents re-initialization. A key technical concern is the single point of failure for critical administrative functions and upgrades, as the owner address initially controls all roles (7.3 Access Control).
The contract utilizes OpenZeppelin's AccessControlUpgradeable for robust role-based access management, defining DEFAULT_ADMIN_ROLE and GOVERNOR_ROLE. However, a significant economic risk exists as the entire MAX_SUPPLY of tokens is minted to a single owner address during initialization (7.4 Economic). Furthermore, this owner address initially holds both DEFAULT_ADMIN_ROLE and GOVERNOR_ROLE, creating a single point of failure for all administrative and governance actions (7.5 Governance).
The contract correctly implements the UUPS upgradeability pattern using OpenZeppelin's UUPSUpgradeable module, ensuring a secure and standard upgrade path. The _authorizeUpgrade function is appropriately restricted to the GOVERNOR_ROLE. However, the initial assignment of the GOVERNOR_ROLE to a single owner address presents a centralization risk for future upgrades (7.7 Upgrades), as compromise of this address would allow unauthorized contract modifications.
It is strongly recommended to decentralize control over the contract's administrative roles and token supply.
Transfer DEFAULT_ADMIN_ROLE and GOVERNOR_ROLE to a robust multi-signature wallet or a decentralized autonomous organization (DAO) to mitigate the single point of failure risk. Consider implementing a token distribution strategy that avoids concentrating the entire supply in a single address, and evaluate the need for a token burn mechanism or a pause functionality for emergency situations.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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
