Quantum Audit Logo
Launch App

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

Is aeon Safe?

AEONBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades7/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The DERC20 contract implements an ERC20 token with custom vesting and inflation mechanisms.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
30.4%Contracts11.6%Wallets57.9%Everyone else
30.4%Contracts11.6%57.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
42.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking30.4%
  • Walletsanonymous holders, free to sell11.6%
  • Everyone elsethe rest of the supply57.9%
Effective concentrationwhat the score reads23.8%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$431.5K across 14 pairs
Show 4 more pairs

The 4 remaining pairs hold $3 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$425.4KShare of depth98.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x575e…fe98

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

Security Findings

1 High1 Medium1 Low2 Info
High

Potential Denial of Service in mintInflation due to Unbounded Loop

The 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.H-01

Issue

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

Fix

Refactor 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;.

Status

Unresolved

Medium

Potential Denial of Service in releaseVestedTokens due to Unbounded Array Processing

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Unused tokenURI State Variable

The 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.L-01

Issue

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

Fix

Either 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).

Status

Unresolved

Info

Centralized Control by Owner

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Info

Non-Upgradeability of Contract

The 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.I-02

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance4/10Medium risk

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.

Upgrades7/10Low risk

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.

Final RecommendationWhat to do about this score

Address the identified denial of service vulnerabilities by refactoring the mintInflation function to calculate the total mintable amount in a single step, avoiding the unbounded while loop.

Implement explicit gas-limiting checks or pagination for array processing in the releaseVestedTokens function to prevent block gas limit exhaustion. Consider implementing an upgradeability pattern, such as UUPS, to allow for future bug fixes and feature enhancements without requiring a full redeployment, which is a complex and risky operation.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age4mo
Contract0xbf8e…aba3
Deployer0xb2f5…431e
Badge for your website
aeon security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202646Medium
  2. Jul 28, 202643Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the AEON contract address?

The aeon contract on Base is 0xbf8e8f0e8866a7052f948c16508644347c57aba3. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is aeon a scam?

Quantum Audit's risk score for aeon is 46/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is AEON liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $431.5K.

Who holds AEON?

As of Sep 4, 2026, the 10 largest holders own 42.1% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Robo TokenROBO · Base46MediumPlumbingBase46MediumELONBase46MediumBroker CatBROKER · Base46MediumDopplerXDP · Base46MediumNockchainNOCK · Base45Medium

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 Is this your token? Publish your own audit on this page