Quantum Audit Logo

Is aeon Safe?

On-chain security analysis — is it a scam or legit?

aeon AEON
0xbf8e…aba3
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DERC20 contract implements an ERC20 token with custom vesting and inflation mechanisms. It leverages OpenZeppelin libraries for standard functionalities and access control. Key features include owner-controlled pool locking, inflation minting, and a linear vesting schedule. The contract's ownership is managed by a multisig, which enhances governance security. However, the contract is not upgradeable, posing a long-term risk for bug fixes or feature enhancements. Several denial-of-service vectors were identified.

1 High1 Medium1 Low2 Informational
Volume 24h
$312.1K
Liquidity
$425.4K
Price
$0.00001965
Token Age
4mo
Top 10 Holders
42.1%

Security Findings

1 High1 Med1 Low2 Info
High

Potential Denial of Service in `mintInflation` due to Unbounded Loop

H-01The `mintInflation` function contains a `while` loop that iterates once for every full year that has passed since `currentYearStart_`. If the function is not called for an extended period (e.g., many years), this loop could iterate hundreds or thousands of times. Each iteration consumes gas, and an excessive number of iterations could cause the transaction to exceed the block gas limit, leading to a denial of service for this critical function. This prevents the owner from minting inflation tokens and updating the `currentYearStart` and `lastMintTimestamp`.
IssueThe `mintInflation` function contains a `while` loop that iterates once for every full year that has passed since `currentYearStart_`. If the function is not called for an extended period (e.g., many years), this loop could iterate hundreds or thousands of times. Each iteration consumes gas, and an excessive number of iterations could cause the transaction to exceed the block gas limit, leading to a denial of service for this critical function. This prevents the owner from minting inflation tokens and updating the `currentYearStart` and `lastMintTimestamp`.
FixRefactor the `mintInflation` function to calculate the total mintable amount and the new `currentYearStart` in a single step, rather than iterating year by year. This can be achieved by calculating the number of full years passed and multiplying the yearly mint by that count, then handling the partial year. For example, `numYears = (block.timestamp - currentYearStart_) / 365 days;`.
StatusUnresolved
Medium

Potential Denial of Service in `releaseVestedTokens` due to Unbounded Array Processing

M-01The `releaseVestedTokens` function takes `recipients_` and `amounts_` arrays as arguments and iterates over them. If a user provides excessively large arrays, the gas cost of processing all elements could exceed the block gas limit. This would lead to a denial of service, preventing legitimate users from releasing their vested tokens if a malicious actor or an honest user accidentally triggers the gas limit with large inputs.
IssueThe `releaseVestedTokens` function takes `recipients_` and `amounts_` arrays as arguments and iterates over them. If a user provides excessively large arrays, the gas cost of processing all elements could exceed the block gas limit. This would lead to a denial of service, preventing legitimate users from releasing their vested tokens if a malicious actor or an honest user accidentally triggers the gas limit with large inputs.
FixImplement a mechanism to limit the number of recipients that can be processed in a single transaction, or introduce pagination. Alternatively, consider a pull-based model where each user claims their own vested tokens individually, or a batching mechanism with a fixed maximum array size.
StatusUnresolved
Low

Unused `tokenURI` State Variable

L-01The `tokenURI` state variable is declared and initialized in the constructor but is not used anywhere else in the contract. There is no public getter function for it, nor does it influence any contract logic. For an ERC20 token, `tokenURI` is not a standard metadata field, typically associated with NFTs (ERC-721/1155). Its presence suggests an unclear or unimplemented purpose.
IssueThe `tokenURI` state variable is declared and initialized in the constructor but is not used anywhere else in the contract. There is no public getter function for it, nor does it influence any contract logic. For an ERC20 token, `tokenURI` is not a standard metadata field, typically associated with NFTs (ERC-721/1155). Its presence suggests an unclear or unimplemented purpose.
FixEither remove the `tokenURI` variable if it serves no purpose, or implement a public getter function and define its intended use case (e.g., linking to off-chain metadata for the token itself, if applicable).
StatusUnresolved
Info

Centralized Control by Owner

I-01The contract utilizes OpenZeppelin's `Ownable` pattern, granting significant control over critical functions to a single address. The owner can `lockPool`, `unlockPool`, `burn` tokens, and `updateMintRate`. While the prefill data indicates the owner is a multisig (3/6 threshold), which mitigates the single point of failure, this centralization of power remains a design consideration.
IssueThe contract utilizes OpenZeppelin's `Ownable` pattern, granting significant control over critical functions to a single address. The owner can `lockPool`, `unlockPool`, `burn` tokens, and `updateMintRate`. While the prefill data indicates the owner is a multisig (3/6 threshold), which mitigates the single point of failure, this centralization of power remains a design consideration.
FixEnsure the owner's private keys (or multisig signers) are secured with robust operational security practices. Regularly review the necessity and scope of owner privileges. Consider implementing a time-lock for critical operations to provide a window for community review or emergency intervention.
StatusUnresolved
Info

Non-Upgradeability of Contract

I-02The DERC20 contract is deployed as a standard, non-upgradeable contract. This means that its logic is immutable once deployed to the blockchain. Any future bug fixes, security patches, or desired feature enhancements would require deploying an entirely new contract and migrating all existing token holders and associated data, which is a complex, costly, and potentially disruptive process.
IssueThe DERC20 contract is deployed as a standard, non-upgradeable contract. This means that its logic is immutable once deployed to the blockchain. Any future bug fixes, security patches, or desired feature enhancements would require deploying an entirely new contract and migrating all existing token holders and associated data, which is a complex, costly, and potentially disruptive process.
FixFor long-term projects, consider implementing an upgradeability pattern (e.g., UUPS or Transparent Proxy) during the design phase. This allows for future logic updates without requiring a full redeployment, providing flexibility for maintenance and evolution. If non-upgradeability is an intentional design choice, ensure all code is thoroughly audited and tested to minimize the risk of immutable vulnerabilities.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture is based on well-audited OpenZeppelin ERC20, ERC20Votes, ERC20Permit, and Ownable contracts, providing a solid foundation (7.1 Architecture, 7.2 Code Security). Custom logic for vesting and inflation is implemented. A significant technical risk is identified in the `mintInflation` function, which contains an unbounded `while` loop that could lead to a denial of service if not called regularly (H-01). Additionally, array processing in the `releaseVestedTokens` function could also lead to DoS if input arrays are too large (M-01). Access control (7.3 Access Control) is appropriately managed via `Ownable` for critical functions.

GovernanceMedium4/10

The economic model includes a capped yearly inflation rate (2%), which is a transparent mechanism for token supply growth (7.4 Economic). The owner has significant control over core parameters like mint rate and pool locking, but this control is mitigated by the use of a multisig for ownership, as indicated by the prefill data (7.5 Governance). Vesting schedules are implemented to distribute tokens over time, with limits on pre-minting to prevent excessive initial distribution.

UpgradesLow7/10

The DERC20 contract is not designed with an upgradeability pattern (7.7 Upgrades). This means that once deployed, its logic cannot be modified. Any future bug fixes, security patches, or feature enhancements would necessitate a complete redeployment of the contract and a migration of all associated assets and user balances, presenting a high operational risk (7.8 Operations) and potential disruption to the protocol.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

42.1% in top 10
11.6% in wallets30.4% in contracts
Effective Concentration23.8%

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.

Liquidity Depth

$431.5K across 14 pairs
Uniswap v4WETHanalysed$425.4K98.6%AerodromeUSDC$3.6K0.8%Uniswap v4USDC$1.4K0.3%Uniswap v4ETH$5790.1%Uniswap v3🌙8$4890.1%Uniswap v4USDC$240.0%
Show 4 more pairsShow less
Uniswap v3USDC$200.0%AerodromeWETH$150.0%Uniswap v3WETH$30.0%PancakeswapWETH$30.0%

The 4 remaining pairs hold $3 between them and are not listed.

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.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xb2f5…431e
Unlocked LP Held By
0x575e…fe98

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (42.1% total → 23.8% effective; 11.6% in EOAs, 30.4% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 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

Related Audits

6 more on the record
Robo Token (ROBO)High RiskPlumbingHigh RiskNockchain (NOCK)Medium RiskViciCoin (VCNT)High RiskgitlawbHigh RiskSolana (Universal) (USOL)Medium Risk

Would You Like a More Detailed Audit of aeon?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit