On-chain security analysis — is it a scam or legit?
The ERC20FixedSupply contract implements a standard fixed-supply ERC-20 token with additional features like batch transfers, permit functionality, token recovery, and meta-transaction support.
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.
0xcc2b…49070x73fc…1ee50x75d7…5f1d0x5c3b…25af0x9211…61b70x9b05…520aNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
ContractOwnership pattern grants significant control to a single owner address, including the ability to transfer ownership and potentially recover tokens via TokenRecovery. This introduces a single point of failure, where compromise of the owner's private key could lead to unauthorized control over critical contract functions.M-01The ContractOwnership pattern grants significant control to a single owner address, including the ability to transfer ownership and potentially recover tokens via TokenRecovery. This introduces a single point of failure, where compromise of the owner's private key could lead to unauthorized control over critical contract functions.
Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract owner to distribute control and reduce the risk of a single point of failure. For highly sensitive operations, explore time-locked transactions or a more decentralized governance mechanism.
Unresolved
permit function, while adhering to the EIP-2612 standard, can be susceptible to front-running attacks. An attacker observing a signed permit message could execute the transferFrom before the legitimate user, potentially leading to unexpected transaction ordering or a 'sandwich attack' if the deadline is set too far in the future or not used effectively.L-01The permit function, while adhering to the EIP-2612 standard, can be susceptible to front-running attacks. An attacker observing a signed permit message could execute the transferFrom before the legitimate user, potentially leading to unexpected transaction ordering or a 'sandwich attack' if the deadline is set too far in the future or not used effectively.
Users should be advised to set a reasonable and short deadline for permit signatures to minimize the window for front-running. Developers should ensure the ERC20Permit implementation correctly validates deadline and nonce to prevent replay attacks.
Unresolved
Layout structs, LAYOUT_STORAGE_SLOT, PROXY_INIT_PHASE_SLOT) typically found in upgradeable proxy implementation contracts. While this contract is not explicitly a proxy, this design choice might be confusing or lead to issues if it were later used as an implementation without proper proxy setup, potentially causing storage collisions or unexpected behavior.I-01The contract utilizes a storage layout pattern (e.g., Layout structs, LAYOUT_STORAGE_SLOT, PROXY_INIT_PHASE_SLOT) typically found in upgradeable proxy implementation contracts. While this contract is not explicitly a proxy, this design choice might be confusing or lead to issues if it were later used as an implementation without proper proxy setup, potentially causing storage collisions or unexpected behavior.
Clarify in documentation whether this contract is intended to be used as a standalone token or as an implementation for a proxy. If standalone, consider simplifying storage management if the proxy-specific patterns are not strictly necessary. If it is intended for future proxy use, ensure the proxy setup is robust and compatible with this storage pattern.
Unresolved
ForwarderRegistryContext relies on an external IForwarderRegistry for meta-transaction functionality. The security and trustworthiness of this external registry are critical for the proper and secure operation of meta-transactions within this token contract. Any compromise or malfunction of the registry could impact the ability to process meta-transactions.I-02The ForwarderRegistryContext relies on an external IForwarderRegistry for meta-transaction functionality. The security and trustworthiness of this external registry are critical for the proper and secure operation of meta-transactions within this token contract. Any compromise or malfunction of the registry could impact the ability to process meta-transactions.
Ensure the IForwarderRegistry contract is thoroughly audited, well-maintained, and controlled by a secure, preferably decentralized, entity. Document the expected behavior and security considerations of the forwarder registry for users and integrators.
Unresolved
The ERC20FixedSupply contract implements a standard fixed-supply ERC-20 token with additional features like batch transfers, permit functionality, token recovery, and meta-transaction support. The contract utilizes a modular architecture with library-based storage. No critical vulnerabilities were identified, but centralized ownership and potential front-running in permit functions are noted.
The contract demonstrates a robust modular architecture, leveraging multiple OpenZeppelin-style extensions for ERC-20 functionality (7.1 Architecture). It includes features like safe transfers, batch transfers, and meta-transaction support, enhancing usability and security (7.2 Code Security). Access control is managed via ContractOwnership, ensuring only the designated owner can perform privileged actions like transferOwnership (7.3 Access Control). However, the reliance on a single owner introduces a centralization risk.
The economic model is a fixed-supply ERC-20 token, with all tokens minted during construction, preventing inflationary risks post-deployment (7.4 Economic). Governance is centralized, with a single owner controlling critical functions such as transferOwnership and potentially TokenRecovery (7.5 Governance). This centralization means the project's security heavily depends on the owner's integrity and operational security.
The contract is not designed as an upgradeable proxy, as indicated by is_proxy: false. However, it employs storage layout patterns (e.g., Layout structs, LAYOUT_STORAGE_SLOT, PROXY_INIT_PHASE_SLOT) commonly associated with upgradeable contracts (7.7 Upgrades). While this doesn't pose a direct vulnerability for a standalone contract, it could lead to confusion or issues if the contract were mistakenly used as an implementation for a proxy without proper setup.
Implement robust operational security practices for the contract owner's private key to mitigate the risks associated with centralized control.
Consider exploring multi-signature wallets or time-locked ownership transfers for enhanced security and decentralization. Ensure the external IForwarderRegistry is thoroughly audited and maintained, as its security directly impacts the meta-transaction functionality of this token.
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
