Quantum Audit Logo
Launch App

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

Is Aerodrome Finance Safe?

AEROBase
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
Technical7/10Governance3/10Upgrades3/10Checks passed2 of 5Findings1 High · 2 Low · 1 Info4
SummaryAI Copilot

This audit covers the provided Solidity source code, which includes the OpenZeppelin ERC20 base contract and the custom IAero interface.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (66.8% total → 35.9% effective; 15.3% in EOAs, 51.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
51.5%Contracts15.3%Wallets33.2%Everyone else
51.5%Contracts15.3%Wallets33.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
66.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking51.5%
  • Walletsanonymous holders, free to sell15.3%
  • Everyone elsethe rest of the supply33.2%
Effective concentrationwhat the score reads35.9%
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$42.38M across 30 pairs
Show 4 more pairs

The 20 remaining pairs hold $762.2K 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$29.21MShare of depth68.9%
Top-1 Unlocked Holder26.3%
Top-3 Unlocked57.6%
Unlocked LP held by
0x3e13…ce200xb182…69100xc4ec…c7a50xcbf7…aaab0xf4c7…d9880xef68…04260xdca8…6f6a0xcf40…423c0x11d4…d1600xda65…9dab

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

Security Findings

1 High2 Low1 Info
High

Centralized Minting Authority

The IAero interface defines a mint function that is explicitly stated to be 'Only callable by Minter.sol', implying a single minter address or contract controls the token supply. This centralized control over minting allows a single entity to arbitrarily increase the token supply, which can lead to token devaluation and economic instability if the minter's private key is compromised or if the minter acts maliciously. This is a significant single point of failure for the token's economic model (7.3 Access Control, 7.4 Economic).H-01

Issue

The IAero interface defines a mint function that is explicitly stated to be 'Only callable by Minter.sol', implying a single minter address or contract controls the token supply. This centralized control over minting allows a single entity to arbitrarily increase the token supply, which can lead to token devaluation and economic instability if the minter's private key is compromised or if the minter acts maliciously. This is a significant single point of failure for the token's economic model (7.3 Access Control, 7.4 Economic).

Fix

Implement a robust access control mechanism for the minter role. This could involve a multi-signature wallet (e.g., Gnosis Safe) for the minter address, or integrating a decentralized governance system that requires community approval for minting operations. Consider adding a time-lock for minting operations to provide a window for review and reaction. Clearly document the minter's identity and operational procedures.

Status

Unresolved

Low

Lack of Emergency Pause Mechanism

The ERC20 contract does not include an emergency pause mechanism. While not a direct vulnerability, the absence of a pause function means that in the event of a critical bug, exploit, or market manipulation, there is no immediate way to halt token transfers or other critical operations. This can lead to prolonged exposure to risks and potential loss of funds (7.8 Operations).L-01

Issue

The ERC20 contract does not include an emergency pause mechanism. While not a direct vulnerability, the absence of a pause function means that in the event of a critical bug, exploit, or market manipulation, there is no immediate way to halt token transfers or other critical operations. This can lead to prolonged exposure to risks and potential loss of funds (7.8 Operations).

Fix

Consider implementing a pause mechanism (e.g., using OpenZeppelin's Pausable contract) that can be triggered by a trusted role (e.g., a multi-sig owner or governance). This would allow for emergency intervention to prevent further damage during critical situations. Ensure the pause mechanism itself is secured and its activation criteria are well-defined.

Status

Unresolved

Low

ERC20 approve Race Condition

The approve function in the ERC20 standard has a known race condition where a malicious spender can exploit a change in allowance by front-running the transaction. If a user first approves X amount and then approves Y amount, a malicious actor could execute the first approved transaction before the second approval takes effect, potentially spending more than intended. OpenZeppelin's ERC20 contract includes increaseAllowance and decreaseAllowance functions to mitigate this, but direct approve calls still carry this risk if not used carefully (7.2 Code Security).L-02

Issue

The approve function in the ERC20 standard has a known race condition where a malicious spender can exploit a change in allowance by front-running the transaction. If a user first approves X amount and then approves Y amount, a malicious actor could execute the first approved transaction before the second approval takes effect, potentially spending more than intended. OpenZeppelin's ERC20 contract includes increaseAllowance and decreaseAllowance functions to mitigate this, but direct approve calls still carry this risk if not used carefully (7.2 Code Security).

Fix

Educate users and integrated protocols to prefer increaseAllowance and decreaseAllowance over direct approve calls when modifying existing allowances. If approve must be used to change an existing allowance, it is best practice to first set the allowance to zero and then to the desired new value, although this requires two transactions.

Status

Unresolved

Info

Incomplete Source Code for 'Aero' Token

The provided source code primarily consists of the OpenZeppelin ERC20 base contract and various interfaces, including the custom IAero interface. However, the full implementation of the 'Aero' token contract, which would inherit from ERC20 and implement the IAero interface (specifically the mint function and minter role management), was not provided for a comprehensive review. This limits the ability to audit the specific logic governing the token's supply mechanism and privileged roles (7.1 Architecture).I-01

Issue

The provided source code primarily consists of the OpenZeppelin ERC20 base contract and various interfaces, including the custom IAero interface. However, the full implementation of the 'Aero' token contract, which would inherit from ERC20 and implement the IAero interface (specifically the mint function and minter role management), was not provided for a comprehensive review. This limits the ability to audit the specific logic governing the token's supply mechanism and privileged roles (7.1 Architecture).

Fix

For a complete security assessment, provide the full source code of the deployed 'Aero' token contract, including the implementation of the mint function and any associated access control or role management logic. This would allow for a thorough review of the token's specific economic and security mechanisms.

Status

Unresolved

Analysis

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

This audit covers the provided Solidity source code, which includes the OpenZeppelin ERC20 base contract and the custom IAero interface. While the full implementation of the 'Aero' token contract was not provided, the analysis assumes the deployed contract at the given address implements the IAero interface, particularly its minting functionality. The contract benefits from using battle-tested OpenZeppelin libraries and Solidity 0.8.19 for robust arithmetic safety. The primary risk identified is the centralized control over token minting, which introduces a single point of failure and potential economic instability if compromised. Operational considerations like an emergency pause mechanism are also noted.

Technical7/10Low risk

The technical architecture leverages the robust and audited OpenZeppelin ERC20 standard, ensuring a solid foundation for token operations (7.1 Architecture). The use of Solidity 0.8.19 inherently protects against integer overflow/underflow vulnerabilities (7.2 Code Security). However, the implied centralized minting authority, as defined by the IAero interface, represents a significant access control risk (7.3 Access Control). If the minter's key is compromised, it could lead to unauthorized token inflation.

Governance3/10High risk

The economic model, as inferred from the IAero interface, relies on a centralized minting mechanism controlled by a single 'minter' address (7.4 Economic). This design introduces a high degree of centralization, as the minter has the unilateral ability to increase the token supply, potentially devaluing existing tokens. While this provides flexibility, it also concentrates power and risk. There is no explicit governance mechanism visible in the provided code to oversee or restrict the minter's actions (7.5 Governance).

Upgrades3/10High risk

The provided contract is not designed with an upgrade mechanism, such as a proxy pattern (7.7 Upgrades). This simplifies the contract's architecture and removes upgrade-related risks like storage collisions or logic errors during upgrades. However, it also means that any critical bugs discovered post-deployment cannot be fixed without deploying a new contract and migrating assets, which can be a complex and costly process.

Final RecommendationWhat to do about this score

It is strongly recommended to implement robust security measures for the 'minter' address, such as multi-signature control or a time-locked governance mechanism, to mitigate the risks associated with centralized minting.

Consider adding an emergency pause functionality to provide a safety switch in case of unforeseen vulnerabilities or market exploits. Ensure that all external interactions, especially with the 'minter' contract, are thoroughly audited and secured.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2y
Contract0x9401…8631
Deployer0xe83f…2818
Badge for your website
Aerodrome Finance 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. Jul 23, 202644Medium

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

Frequently Asked Questions

Is Aerodrome Finance a scam?

Aerodrome Finance has verifiable attributes like a verified contract and renounced ownership, which suggest a degree of transparency and reduced immediate scam risks often associated with unverified or owner-controlled projects. However, its overall risk score of 64/100 is high, indicating significant inherent vulnerabilities. Investors should acknowledge these structural risks rather than solely focusing on general scam indicators.

Is Aerodrome Finance safe to buy?

Investing in Aerodrome Finance carries notable risks. Key concerns include the existence of a mint function, which could increase token supply, and the high concentration of 67.6% of tokens held by the top 10 addresses, posing potential market impact. Additionally, the project's liquidity is not locked, adding another layer of risk. These factors contribute to its high-risk score, advising caution for potential buyers.

Has Aerodrome Finance been audited?

The Aerodrome Finance contract is confirmed as verified, ensuring its deployed code matches the public source. This offers transparency but differs from a formal security audit. An audit is an independent review by experts to identify vulnerabilities and flaws. The provided information does not specify if such a comprehensive audit has been performed on Aerodrome Finance.

Related Audits

6 more on the recordAll audits
SapienBase44MediumRaveDAORAVE · Base44MediumMocaBase44MediumNockchainNOCK · Base45MediumSolana (Universal)USOL · Base45MediumElsaBase45Medium

Would You Like a More Detailed Audit of Aerodrome Finance?

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