Quantum Audit Logo

Is Aave Safe?

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

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

Aave AAVE
0x7fc6…dae9
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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the AaveTokenV3 contract, which functions as an ERC20 token, deployed via an OpenZeppelin Transparent Upgradeable Proxy. The contract incorporates standard features such as burnability, pausability, and a transfer hook mechanism. The implementation leverages well-vetted OpenZeppelin libraries, contributing to a robust technical foundation. Key security considerations include the centralized control inherent in the pausable and upgradeability mechanisms, and the potential risks associated with external calls via the ITransferHook interface. The overall risk is assessed as Medium, primarily due to the significant economic value managed by the token and the inherent risks of centralized governance and external dependencies.

3 Medium1 Low2 Informational
Volume 24h
$359.6K
Liquidity
$10.90M
Price
$131.0300
Token Age
1y
Top 10 Holders
43.0%

Security Findings

3 Med1 Low2 Info
Medium

Centralized Control over Pausability and Upgrades

M-01The `AaveTokenV3` contract includes `Pausable` functionality, allowing an authorized address (owner) to halt all token transfers. Additionally, the Transparent Proxy pattern grants the `ProxyAdmin` owner the ability to upgrade the contract logic. While these features are common for emergency response and flexibility, they introduce a significant degree of centralized control over the token's operation and future evolution. (7.3 Access Control, 7.5 Governance)
IssueThe `AaveTokenV3` contract includes `Pausable` functionality, allowing an authorized address (owner) to halt all token transfers. Additionally, the Transparent Proxy pattern grants the `ProxyAdmin` owner the ability to upgrade the contract logic. While these features are common for emergency response and flexibility, they introduce a significant degree of centralized control over the token's operation and future evolution. (7.3 Access Control, 7.5 Governance)
FixEnsure that the owner addresses for both the `AaveTokenV3` implementation and the `ProxyAdmin` are controlled by a robust, multi-signature wallet or a well-established decentralized governance mechanism with appropriate time-locks for critical operations. Clearly document the process and conditions under which these controls can be exercised.
StatusUnresolved
Medium

Potential Reentrancy and External Dependency via ITransferHook

M-02The `ITransferHook` interface allows for external calls during token transfers. While `AaveTokenV3` itself uses `ReentrancyGuard` for its own state-changing functions, the `onTransfer` hook introduces an external call context. A malicious or vulnerable contract hooked into this mechanism could potentially re-enter the token contract or other sensitive contracts, leading to unexpected behavior or asset manipulation. This also creates a dependency on the security and availability of the hooked contract. (7.2 Code Security, 7.6 External)
IssueThe `ITransferHook` interface allows for external calls during token transfers. While `AaveTokenV3` itself uses `ReentrancyGuard` for its own state-changing functions, the `onTransfer` hook introduces an external call context. A malicious or vulnerable contract hooked into this mechanism could potentially re-enter the token contract or other sensitive contracts, leading to unexpected behavior or asset manipulation. This also creates a dependency on the security and availability of the hooked contract. (7.2 Code Security, 7.6 External)
FixImplement strict checks on the address of the `ITransferHook` contract, ensuring it is a trusted and thoroughly audited entity. Consider adding reentrancy guards around the `onTransfer` call if the hook interacts with critical state or external contracts. Evaluate the necessity and potential risks of the hook's functionality, and ensure it adheres to the checks-effects-interactions pattern.
StatusUnresolved
Medium

Upgradeability Storage Collision Risk

M-03The contract utilizes an upgradeable proxy pattern. While this provides flexibility, any future upgrades to the `AaveTokenV3` implementation must carefully manage storage layout. Incompatible storage variable declarations between different implementation versions can lead to storage collisions, where new variables overwrite existing data, potentially corrupting contract state or leading to loss of funds. (7.7 Upgrades)
IssueThe contract utilizes an upgradeable proxy pattern. While this provides flexibility, any future upgrades to the `AaveTokenV3` implementation must carefully manage storage layout. Incompatible storage variable declarations between different implementation versions can lead to storage collisions, where new variables overwrite existing data, potentially corrupting contract state or leading to loss of funds. (7.7 Upgrades)
FixAdhere strictly to OpenZeppelin's upgrade safety guidelines, especially regarding storage layout. Use tools like `hardhat-upgrades` or `truffle-upgrades` to detect potential storage collisions during development and deployment. Conduct thorough testing and formal verification of new implementation versions before any upgrade to ensure storage compatibility.
StatusUnresolved
Low

ERC20 `approve` Race Condition Warning

L-01The `IERC20` interface, and by extension `AaveTokenV3`, implements the standard `approve` function. The ERC20 standard itself has a known race condition vulnerability where a user changing an allowance from a non-zero value to another non-zero value can be exploited by a malicious spender to spend both the old and new allowances. This is a characteristic of the ERC20 standard, not a bug in the implementation. (7.2 Code Security)
IssueThe `IERC20` interface, and by extension `AaveTokenV3`, implements the standard `approve` function. The ERC20 standard itself has a known race condition vulnerability where a user changing an allowance from a non-zero value to another non-zero value can be exploited by a malicious spender to spend both the old and new allowances. This is a characteristic of the ERC20 standard, not a bug in the implementation. (7.2 Code Security)
FixEducate users and integrated protocols about this known ERC20 vulnerability. Recommend that users first set the allowance to zero with `approve(spender, 0)` and then to the desired non-zero amount, or use `increaseAllowance`/`decreaseAllowance` if available in the token implementation to mitigate this risk.
StatusUnresolved
Info

Proxy Contracts Compiled with Older Solidity Version

I-01The proxy contracts (`BaseAdminUpgradeabilityProxy`, `InitializableAdminUpgradeabilityProxy`, etc.) are compiled with Solidity versions `^0.6.0` or `0.6.10`, while the `AaveTokenV3` implementation uses `0.8.20`. While this is common for older deployments and the proxy's logic is minimal, the proxy itself does not benefit from the native overflow/underflow checks and other compiler optimizations introduced in Solidity 0.8.x. (7.1 Architecture)
IssueThe proxy contracts (`BaseAdminUpgradeabilityProxy`, `InitializableAdminUpgradeabilityProxy`, etc.) are compiled with Solidity versions `^0.6.0` or `0.6.10`, while the `AaveTokenV3` implementation uses `0.8.20`. While this is common for older deployments and the proxy's logic is minimal, the proxy itself does not benefit from the native overflow/underflow checks and other compiler optimizations introduced in Solidity 0.8.x. (7.1 Architecture)
FixThis is generally acceptable for established proxy deployments. For new deployments, consider using proxy patterns that are fully compatible with the latest stable Solidity versions to leverage all compiler safety features. For existing deployments, ensure the proxy's minimal logic is thoroughly tested and verified against its specific compiler version.
StatusUnresolved
Info

Use of `SafeMath` in 0.8.x Context

I-02The `AaveTokenV3` implementation is compiled with Solidity 0.8.20, which includes native overflow and underflow checks for all arithmetic operations. However, the provided source code includes `SafeMath.sol` from OpenZeppelin. While `SafeMath` is crucial for older Solidity versions (pre-0.8.0), its explicit use in 0.8.x is redundant and can slightly increase gas costs without adding further security benefits. (7.2 Code Security)
IssueThe `AaveTokenV3` implementation is compiled with Solidity 0.8.20, which includes native overflow and underflow checks for all arithmetic operations. However, the provided source code includes `SafeMath.sol` from OpenZeppelin. While `SafeMath` is crucial for older Solidity versions (pre-0.8.0), its explicit use in 0.8.x is redundant and can slightly increase gas costs without adding further security benefits. (7.2 Code Security)
FixFor contracts compiled with Solidity 0.8.0 or higher, `SafeMath` is generally not required. Consider removing explicit `SafeMath` usage in the `AaveTokenV3` implementation to optimize gas costs and simplify the code, relying on the compiler's native checks. Ensure that any custom arithmetic operations are still handled safely.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The technical architecture (7.1) utilizes OpenZeppelin's Transparent Proxy pattern and well-established ERC20 standards, enhancing code security (7.2). The implementation includes `ReentrancyGuard` and `SafeMath` (for older Solidity versions), mitigating common vulnerabilities. However, the `ITransferHook` interface introduces external call dependencies, which could lead to reentrancy or unexpected behavior if not carefully managed. The proxy contracts are compiled with an older Solidity version (0.6.x), while the implementation uses 0.8.20, which is generally secure.

GovernanceMedium5/10

The economic model (7.4) is based on a standard ERC20 token, which is a core asset for the Aave ecosystem with high TVL. Governance (7.5) is centralized through an `Ownable` pattern for the `AaveTokenV3` implementation and an `OZ_ProxyAdmin` for upgrades. The `Pausable` functionality provides an emergency stop mechanism, which is a necessary control but also a point of centralization. The admin address is controlled by a separate entity, likely a governance contract or multisig, which is a good practice for mitigating single points of failure.

UpgradesHigh1/10

The contract employs the OpenZeppelin Transparent Upgradeability Proxy pattern (7.7), allowing for future logic upgrades without changing the contract address. The `Initializable` pattern is correctly used to prevent re-initialization after deployment. Upgrade control resides with the `ProxyAdmin` contract, whose owner is a separate address, indicating a multi-layered control structure. While this pattern is robust, careful management of storage layout during upgrades is crucial to prevent storage collisions between different implementation versions.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

43.0% in top 10
11.7% in wallets31.3% in contracts
Effective Concentration24.2%

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

$24.38M across 21 pairs
BalancerwstETHanalysed$10.90M44.7%Uniswap v4ETH$5.75M23.6%Uniswap v3WETH$3.81M15.6%Uniswap v4USDC$2.10M8.6%Uniswap v3WETH$428.8K1.8%Uniswap v3UNI$273.8K1.1%
Show 4 more pairsShow less
Uniswap v4USDC$253.4K1.0%Uniswap v3USDC$210.3K0.9%Uniswap v3USDT$125.9K0.5%Uniswap v4LINK$118.8K0.5%

The 11 remaining pairs hold $417.3K 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 Holder38.0%
Top-3 Unlocked68.4%

Key Addresses

11 addresses
Deployer
0x51f2…b815
Unlocked LP Held By
0x00a3…95f40x00bd…c55c0x5ccf…7acf0xa29d…34db0xb47b…5d6c0x0b80…9e740x52d7…359d0x679e…a1940xb661…4d400x7d42…53c9

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 20% (43.0% total → 24.2% effective; 11.7% in EOAs, 31.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 3 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

Frequently Asked Questions

Is Aave a scam?

Based on the provided data, Aave does not exhibit typical scam characteristics. Its token contract is verified, ownership is renounced, and no mint function exists, indicating a high level of transparency and immutability. These fundamental security features contradict the hallmarks of a scam, supporting Aave's standing as a prominent decentralized finance protocol, despite its Medium Risk score of 28/100.

Is Aave safe to buy?

Aave demonstrates robust foundational security, including a verified contract, renounced ownership, and no mint function, enhancing its structural integrity. However, investors should be aware of factors contributing to its 28/100 Medium Risk score. Notably, 40.9% of the supply is concentrated among the top 10 holders, and liquidity is not locked. These elements require careful consideration regarding market stability and potential influence.

Has Aave been audited?

The Aave token contract is verified on Ethereum, ensuring its code is publicly visible for inspection. This transparency is a key safety signal, enabling community and expert review. While verification is crucial for security and facilitates audits, it confirms code visibility. It doesn't inherently confirm a formal, independent security audit of the token contract has been completed based on this data.

Related Audits

6 more on the record
Injective (INJ)Medium RiskLighter (LIT)Medium RiskPepeMedium RiskShiro Neko (SHIRO)Medium RiskBeefy (BIFI)Medium RiskADIMedium Risk

Would You Like a More Detailed Audit of Aave?

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

Get Detailed Audit