Quantum Audit Logo

Is AVA Safe?

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

Is this your token? Publish your own audit on this page →

AVA AVA
0xa6c0…ceb9
Ethereum
Not verifiedThis 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 4d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The AVA token contract implements an ERC20 token with a time-based inflationary minting model, leveraging OpenZeppelin's `ERC20PresetMinterPauser`. A critical vulnerability was identified where public minting functions lack proper role-based access control, allowing unauthorized token minting. Additionally, an inconsistency in the inflationary model's year-tracking logic and the admin's ability to indefinitely increase the maximum supply pose further risks to the token's integrity and economic model.

1 Critical1 Medium1 Low2 Informational
Volume 24h
$464.2K
Liquidity
$168.2K
Price
$0.2535
Token Age
2y
Top 10 Holders
74.6%

Security Findings

1 Crit1 Med1 Low2 Info
Critical

Unauthorized Minting via Public Functions

C-01The `mintCurrentYear`, `mintRemainingCurrentYear`, and `mintRemainingPastYear` functions are declared `public` but lack any access control checks (e.g., `onlyRole(MINTER_ROLE)`). This allows any external caller to mint tokens up to the yearly limits defined by the inflationary model, bypassing the intended authorization mechanism provided by `ERC20PresetMinterPauser` and leading to uncontrolled inflation.
IssueThe `mintCurrentYear`, `mintRemainingCurrentYear`, and `mintRemainingPastYear` functions are declared `public` but lack any access control checks (e.g., `onlyRole(MINTER_ROLE)`). This allows any external caller to mint tokens up to the yearly limits defined by the inflationary model, bypassing the intended authorization mechanism provided by `ERC20PresetMinterPauser` and leading to uncontrolled inflation.
FixImplement appropriate role-based access control for all custom minting functions. For instance, add `onlyRole(MINTER_ROLE)` or `onlyRole(DEFAULT_ADMIN_ROLE)` to `mintCurrentYear`, `mintRemainingCurrentYear`, and `mintRemainingPastYear` to restrict their execution to authorized accounts.
StatusUnresolved
Medium

Inconsistent `inflationaryModelTotalYears` Update Logic

M-01The `addNewYearForInflationaryModel` function's logic for updating `inflationaryModelTotalYears` can lead to gaps in the inflationary model. If `getCurrentYear()` is significantly ahead of `inflationaryModelTotalYears`, the function will set `inflationaryModelTotalYears = currentYear`, skipping intermediate years. This means `inflationaryModelPerYear` entries for the skipped years will remain zero, preventing minting during those periods if `getCurrentYear()` falls within them, potentially disrupting the token's planned inflation schedule.
IssueThe `addNewYearForInflationaryModel` function's logic for updating `inflationaryModelTotalYears` can lead to gaps in the inflationary model. If `getCurrentYear()` is significantly ahead of `inflationaryModelTotalYears`, the function will set `inflationaryModelTotalYears = currentYear`, skipping intermediate years. This means `inflationaryModelPerYear` entries for the skipped years will remain zero, preventing minting during those periods if `getCurrentYear()` falls within them, potentially disrupting the token's planned inflation schedule.
FixRefine the logic in `addNewYearForInflationaryModel` to ensure that new years are added sequentially or allow the admin to specify the exact `yearID` to add, ensuring no gaps are created in the inflationary model. For example, ensure `inflationaryModelTotalYears` is always `currentYear` or `inflationaryModelTotalYears + 1` when adding a new year.
StatusUnresolved
Low

Admin Can Increase `MAX_SUPPLY` Indefinitely

L-01The `increaseMaxSupply` function allows the `DEFAULT_ADMIN_ROLE` to increase the `MAX_SUPPLY` by a percentage of the `totalSupply` once per year after the initial 10-year period. While restricted to a percentage less than 100%, this mechanism, if repeatedly invoked over many years, could lead to a significantly higher total supply than initially anticipated, potentially diluting existing token holders over a long timeframe.
IssueThe `increaseMaxSupply` function allows the `DEFAULT_ADMIN_ROLE` to increase the `MAX_SUPPLY` by a percentage of the `totalSupply` once per year after the initial 10-year period. While restricted to a percentage less than 100%, this mechanism, if repeatedly invoked over many years, could lead to a significantly higher total supply than initially anticipated, potentially diluting existing token holders over a long timeframe.
FixConsider implementing a hard cap on the total `MAX_SUPPLY` or a maximum number of times the `increaseMaxSupply` function can be called. Clearly communicate the long-term implications of this mechanism to token holders to manage expectations regarding potential supply dilution.
StatusUnresolved
Info

Hardcoded Initial Inflationary Model Limits Flexibility

I-01The inflationary model for the first 10 years is hardcoded in the constructor. While `updateInflationaryModelPerYear` allows modification of future years, it requires `yearID >= currentYear`. This design choice prevents the admin from adjusting the minting schedule for any of the initial 10 years that have not yet passed, limiting flexibility in response to unforeseen economic conditions.
IssueThe inflationary model for the first 10 years is hardcoded in the constructor. While `updateInflationaryModelPerYear` allows modification of future years, it requires `yearID >= currentYear`. This design choice prevents the admin from adjusting the minting schedule for any of the initial 10 years that have not yet passed, limiting flexibility in response to unforeseen economic conditions.
FixThis is a design choice. If greater flexibility is desired, consider allowing the admin to update future years within the initial 10-year period, perhaps with a grace period or a multi-signature approval process.
StatusUnresolved
Info

Reliance on `block.timestamp` for Critical Logic

I-02The `getCurrentYear` function, which is central to the inflationary model and `MAX_SUPPLY` increase logic, relies on `block.timestamp`. While acceptable for long durations like years, `block.timestamp` can be manipulated by miners within a small range (up to 900 seconds on Ethereum), potentially affecting the precise timing of year transitions.
IssueThe `getCurrentYear` function, which is central to the inflationary model and `MAX_SUPPLY` increase logic, relies on `block.timestamp`. While acceptable for long durations like years, `block.timestamp` can be manipulated by miners within a small range (up to 900 seconds on Ethereum), potentially affecting the precise timing of year transitions.
FixFor yearly calculations, `block.timestamp` is generally considered acceptable. However, for extremely time-sensitive operations, consider using a decentralized oracle for time if precise, unmanipulable time is critical, though this adds complexity and external dependencies.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes OpenZeppelin's `ERC20PresetMinterPauser` for core ERC20 functionality and access control (7.1 Architecture). The code generally follows good practices for Solidity 0.8.18, including checked arithmetic. However, a critical flaw exists in the custom minting functions (`mintCurrentYear`, `mintRemainingCurrentYear`, `mintRemainingPastYear`), which are `public` without requiring any specific role, enabling unauthorized token minting (7.3 Access Control, 7.2 Code Security). Furthermore, the logic for adding new years to the inflationary model can create unintended gaps (7.2 Code Security).

GovernanceHigh1/10

The tokenomics are based on a predefined 10-year inflationary schedule, with the `DEFAULT_ADMIN_ROLE` having significant power to modify future yearly mint amounts, add new years, and increase the `MAX_SUPPLY` (7.4 Economic, 7.5 Governance). While the initial supply and yearly mints are clearly defined, the ability to increase `MAX_SUPPLY` annually after 10 years could lead to long-term dilution (7.4 Economic). The critical access control vulnerability in minting functions directly impacts the economic model by allowing unauthorized inflation (7.4 Economic).

UpgradesHigh2/10

The AVA contract is deployed as a standard, non-upgradeable implementation (7.7 Upgrades). This design choice means that any identified vulnerabilities or desired feature changes would necessitate a new contract deployment and a migration process, which can be complex and costly for users. The immutability provides certainty but sacrifices future adaptability.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

74.6% in top 10
38.6% in wallets36.0% in contracts
Effective Concentration53.0%

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

$168.2K

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 Holder96.7%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x182c…a34e
Unlocked LP Held By
0x5e1a…4cec0x575d…d1730x0f9a…812c

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 50% (74.6% total → 53.0% effective; 38.6% in EOAs, 36.0% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 96.7% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical 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
RallyCritical RiskGlobal Dollar (USDG)Critical RiskBigShortBets (BIGSB)Critical RiskFrankencoin (ZCHF)Critical RiskHeyAnon (ANON)Critical RiskKyber Network Crystal v2 (KNC)Critical Risk

Would You Like a More Detailed Audit of AVA?

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

Get Detailed Audit