On-chain security analysis — is it a scam or legit?
EthereumThe Dual token contract is a straightforward ERC20 implementation leveraging battle-tested OpenZeppelin libraries, including ERC20Permit functionality.
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
How the supply is spread across holders could not be read — the indexer's holder list does not add up to the supply. Check the largest holders on a block explorer, which reads current balances.
The risk score reads depth across every pair.
Whether the LP tokens are locked could not be determined.
TOTAL_SUPPLY of 10,000,000,000 DUAL tokens is minted to a single mintTo address during contract deployment. This design choice centralizes the initial control and distribution of all tokens, which could pose a risk if the mintTo address is compromised or acts maliciously, as it holds the entire supply.L-01The entire TOTAL_SUPPLY of 10,000,000,000 DUAL tokens is minted to a single mintTo address during contract deployment. This design choice centralizes the initial control and distribution of all tokens, which could pose a risk if the mintTo address is compromised or acts maliciously, as it holds the entire supply.
While this is a design decision, for projects aiming for decentralization, consider implementing a more distributed initial token allocation strategy, such as vesting schedules, multi-signature wallets for the initial recipient, or a public sale mechanism.
Unresolved
permit function, while correctly implemented per EIP-2612 using OpenZeppelin's ERC20Permit, is inherently susceptible to front-running. An attacker could observe a pending permit transaction in the mempool and submit a transaction with a higher gas price to either consume the user's nonce or approve a different spender/amount, potentially causing the original transaction to fail or leading to unintended approvals. This is a known characteristic of the EIP-2612 standard and not a flaw in the implementation itself.L-02The permit function, while correctly implemented per EIP-2612 using OpenZeppelin's ERC20Permit, is inherently susceptible to front-running. An attacker could observe a pending permit transaction in the mempool and submit a transaction with a higher gas price to either consume the user's nonce or approve a different spender/amount, potentially causing the original transaction to fail or leading to unintended approvals. This is a known characteristic of the EIP-2612 standard and not a flaw in the implementation itself.
Users should be educated on the risks of front-running when using permit. Relay services or off-chain mechanisms can help mitigate this by ensuring transactions are submitted directly to miners or through private transaction networks. Users should also be cautious about the deadline parameter and ensure it is set appropriately.
Unresolved
Dual contract correctly implements the ERC20 and ERC20Permit standards by inheriting from battle-tested OpenZeppelin contracts. This includes robust implementations for token transfers, approvals, and EIP-2612 permit functionality, significantly reducing the likelihood of common vulnerabilities related to token functionality and signature handling.I-01The Dual contract correctly implements the ERC20 and ERC20Permit standards by inheriting from battle-tested OpenZeppelin contracts. This includes robust implementations for token transfers, approvals, and EIP-2612 permit functionality, significantly reducing the likelihood of common vulnerabilities related to token functionality and signature handling.
Continue to leverage well-audited and maintained libraries like OpenZeppelin for core functionalities. Regularly monitor OpenZeppelin's security advisories and updates.
Resolved
The Dual token contract is a straightforward ERC20 implementation leveraging battle-tested OpenZeppelin libraries, including ERC20Permit functionality. The contract's architecture is simple, with a fixed total supply minted to a single address upon deployment. While the core token logic is robust, the centralized initial distribution and inherent front-running risk of the permit function are noted as low-level concerns.
The contract exhibits strong technical security (7.2 Code Security) by exclusively utilizing OpenZeppelin's battle-tested ERC20 and ERC20Permit implementations, which are widely audited and considered secure. The architecture (7.1 Architecture) is simple and adheres to standard token patterns, minimizing custom logic where vulnerabilities often arise. Access control (7.3 Access Control) is standard for an ERC20 token, with no additional privileged roles beyond the initial minting. Error handling is robust, using custom errors from OpenZeppelin and a specific ZeroAddress error.
The economic model (7.4 Economic) involves a fixed total supply minted entirely to a single address at deployment, which centralizes initial token distribution. There are no explicit governance mechanisms (7.5 Governance) within the contract itself, meaning control over the token's future (e.g., upgrades, parameter changes) is not decentralized. This centralization of initial supply is a design choice that should be understood by users.
The contract is not designed to be upgradeable (7.7 Upgrades), as it does not implement any proxy patterns. This eliminates upgrade-related risks such as proxy misconfigurations or logic errors during upgrades. However, it also means that any future changes to the token's logic would require a new deployment and migration.
The Dual token contract is well-implemented using established OpenZeppelin standards, making it robust against common technical vulnerabilities.
Users should be aware of the centralized initial token distribution and the inherent front-running characteristics of the EIP-2612 permit function. For future projects, consider implementing a more decentralized initial distribution strategy if community ownership is a goal. If the project intends to evolve, plan for upgradeability from the outset to avoid costly migrations.
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
