Is DUAL Safe? Smart Contract Security Analysis

Security Findings

2 Low1 Info

Low

Centralized Initial Token Distribution

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.

IssueThe 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.

FixWhile 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.

StatusUnresolved

Low

Potential for Permit Function Front-Running

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.

IssueThe `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.

FixUsers 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.

StatusUnresolved

Info

Adherence to OpenZeppelin Standards

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.

IssueThe `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.

FixContinue to leverage well-audited and maintained libraries like OpenZeppelin for core functionalities. Regularly monitor OpenZeppelin's security advisories and updates.

StatusResolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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.

UpgradesMedium5/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Liquidity Depth

$710.8K across 5 pairs

Uniswap v4ETHanalysed$600.8K Uniswap v4USDT$107.6K Uniswap v4USDT$1.3K Uniswap v4USDT$909 Uniswap v4USDC$200

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

Key Addresses

1 addresses

Deployer

0x3a80…324e

What Raised This Score

4 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 50% (127.1% total → 67.1% effective; 27.1% in EOAs, 100.0% in contracts — heavy)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
2 Low finding(s) from audit

Each 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

Is DUAL Safe?