MAINNETBETA

aave.com

5.9MODERATEhigh
6 sectionsrun #1
Findings4 critical14 high12 medium
DEPGOVTKNAUDCTR
Last analyzed 3d ago runs

Summary

Aave V3 is the largest on-chain lending protocol (~$11.8B TVL, 21 chains) with four years of unexploited core Pool bytecode, tier-1 audit coverage (49 public reports), and mature on-chain DAO governance (AAVE/stkAAVE voting, ~1-day/7-day timelocks, 5-of-9 Guardian multisig). Those strengths are real—but 2026 exposed that the biggest losses do not come from Pool bugs. A CAPO oracle misconfiguration liquidated ~$27.8M of user collateral in March, and an unbacked bridged rsETH deposit left ~$123–196M bad debt and triggered an ~$8.45B deposit run in April. Overall risk is moderate at 5.9/10, driven primarily by dependency risk (7.0/10): oracles, bridged collateral, and automated risk-parameter pipelines sit outside the audited core.

Trust Assumptions

Users must trust that (1) Aave DAO governance and the 5-of-9 Guardian multisig will not pass malicious upgrades or abuse emergency powers; (2) Chainlink feeds, CAPO adapters, and Chaos Labs/AgentHub automated parameter updates will remain accurate and synchronized—core AaveOracle has no on-chain staleness checks; (3) every listed bridged or OFT collateral token (rsETH, wrsETH, etc.) is fully backed by its issuer's escrow on the source chain, because Aave does not verify backing at deposit time; (4) cross-chain governance payloads relay correctly via a.DI bridge adapters within acceptable delay; and (5) for deposits on newer chains, BGD-deployed bytecode on Plasma/MegaETH/XLayer matches the audited reference implementation despite 52% of contracts lacking explorer verification.

What Could Go Wrong

First, another oracle or CAPO misconfiguration—similar to the March 2026 wstETH incident—could trigger mass wrongful liquidations across E-Mode LST positions before anyone intervenes; automation via Chainlink AgentHub executes without mandatory pre-execution simulation. Second, a compromised or misconfigured bridge (like KelpDAO's 1-of-1 LayerZero DVN) could mint unbacked LRT that is deposited as collateral, enabling ~$100M+ borrows against phantom assets while oracles report fair market price—April 2026 left ~$123–196M bad debt and an ~$8.45B deposit run. Third, a governance capture event leveraging Aave Labs' ~23% token concentration, combined with unverified Executor bytecode, could push a malicious Pool implementation upgrade through the ~1-day Level 1 timelock before the Guardian acts.

Recommendation

Aave V3 on Ethereum mainnet with blue-chip collateral (USDC, WETH, wstETH on verified instances) remains reasonable for risk-aware capital, given unexploited core bytecode, strong audit history, and functional DAO governance—but size positions assuming the Safety Module will not fully cover large-scale incidents. Actively avoid or strictly limit exposure to bridged LRT markets, newer unverified chain deployments, and Umbrella staking unless you accept automated slashing risk. Monitor: CAPO/oracle parameter changes, new collateral listing proposals (especially OFT/bridged tokens), Guardian multisig composition, reserve utilization on your deposited assets, and whether Immunefi's $5M critical bounty is live. Reduce exposure if another 2026-style operational failure occurs without structural fixes to pre-execution simulation gates and bridged-collateral backing verification.

Key Findings (30)

critical
52% of deployed contracts unverified on block explorersverification
critical
April 2026 rsETH bad debt exposed Safety Module and tokenomic backstop insufficiencyincentive
critical
Bridged/wrapped LST collateral accepted without on-chain backing verification (Apr 2026 rsETH incident)bridge
critical
Apr 2026 KelpDAO/LayerZero bridge exploit — ~$123–196M bad debt, ~$8.45B runincident
high
Eight chain deployments 100% unverified despite active TVLverification
high
Upgradeable proxy architecture for Pool and PoolConfiguratorupgradability
high
AaveOracle Chainlink integration without staleness validationoracle
high
Executor Lvl 1 holds all core upgrade authoritycentralization
high
Aave Labs founding allocation (~23%) creates governance concentration riskconcentration
high
Umbrella Security Module shifts slashing risk to aToken stakersincentive
high
Chainlink-primary oracle with no on-chain staleness validationoracle
high
CAPO risk-oracle pipeline for LST assets (Mar 2026 wstETH incident)oracle
high
Heavy LST/LRT collateral dependency on issuers and restaking infrastructureoracle
high
52% of deployed contracts unverified on block explorersverification-gap
high
New chain deployments fully unverified despite significant TVLaudit-gap
high
Mar 2026 CAPO oracle misconfiguration — ~$27.8M wrongful liquidationsincident
high
Mar–Apr 2026 core contributor exodus before rsETH exploitteam
high
Protocol communications understate user-impact magnitudeincident
medium
Governance-controlled upgrade path with contract-based ownership (no EOA admin keys)access-control
medium
Role-based ACLManager gates pool operationsaccess-control
medium
Per-chain ownership divergence in cross-chain governance executorscross-chain
medium
Emergency and pause mechanisms distributed across governance layersemergency
medium
TransparentUpgradeableProxy used for Governance V3 contractsgovernance
medium
Executor Lvl 1 contract source unverified on Etherscanarchitecture
medium
Governance Guardian 5-of-9 multisig retains emergency powersgovernance
medium
Cross-chain governance relay introduces bridge-dependent execution lag and trust assumptionscross-chain
medium
Timelock enforced via PayloadsController access levels, not standalone TimelockControllertimelock
medium
stkAAVE holds 2.15M AAVE (~13.5% of cap) with emissions trending downincentive
medium
DAO buyback program net-acquires AAVE but was paused post-rsETHutility
medium
GHO at ~584M supply with facilitator model and soft peg maintenancepeg

Analysis Sections

Aave V3 is governed by on-chain Governance V3 (AAVE/stkAAVE voting → PayloadsController timelock → Executors), not EOAs. Verified on Ethereum: PoolAddressesProvider owner and ACL admin are Executor Lvl 1 (0x5300…192A); both Executors are owned by PayloadsController; Governance Guardian is a 5-of-9 Gnosis Safe. Cross-chain markets mirror this pattern (Arbitrum PayloadsController 0x8964…637C owned by local Executor Lvl 1). Residual risks: Executor Lvl 1 bytecode is unverified on Etherscan, cross-chain payload relay depends on bridge adapters, and Guardians retain emergency cancel/freeze powers without token-holder vote.

Findings (7)

highExecutor Lvl 1 holds all core upgrade authority

On-chain verification shows PoolAddressesProvider.owner() = Executor Lvl 1 (0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A) and getAddress('ACL_ADMIN') returns the same address. This Executor can upgrade Pool, PoolConfigurator, Oracle, and ACLManager implementations via PoolAddressesProvider.onlyOwner functions. Compromise of a passed governance payload or Executor misconfiguration could alter protocol behavior across all Ethereum markets.

on-chain RPC via Etherscan APIPoolAddressesProvider.owner() → 0x5300a1a15135ea4dc7ad5a167152c01efc9b192a; getAddress(ACL_ADMIN) → 0x5300a1a15135ea4dc7ad5a167152c01efc9b192a
contract sourcePoolAddressesProvider.setPoolImpl/setPoolConfiguratorImpl/setPriceOracle — all onlyOwner
mediumExecutor Lvl 1 contract source unverified on Etherscan

The Ethereum Executor Lvl 1 (0x5300…192A) — the address holding PoolAddressesProvider ownership and ACL admin — has no verified source on Etherscan in this workspace. While it is the documented Governance V3 short executor and its owner() resolves to PayloadsController, unverified bytecode limits static auditability of the exact execution logic.

contracts directory0x5300a1a15135ea4dc7ad5a167152c01efc9b192a.sol: source NOT VERIFIED
on-chain RPC via Etherscan APIExecutor Lvl 1.owner() → 0xdabad81af85554e9ae636395611c58f7ec1aaec5 (PayloadsController)
mediumGovernance Guardian 5-of-9 multisig retains emergency powers

Governance Guardian (0xCe52ab41C40575B072A18C9700091Ccbe4A06710) is a Gnosis SafeProxy with threshold 5 and 9 owners verified on-chain. Per Governance V3 design and Aave forum documentation, this multisig can cancel queued payloads before execution and holds EMERGENCY_ADMIN on pools for market pause — bypassing the AAVE token vote path for emergency response.

on-chain RPC via Etherscan APIgetThreshold() → 5; getOwners() returns 9 addresses including 0xda5ae43e…, 0x1e380435…, 0x4f967430…
Aave Governance V3 docsGuardian can cancel malicious/wrong payloads if not executed or expired
mediumCross-chain governance relay introduces bridge-dependent execution lag and trust assumptions

Governance V3 relays approved payloads from Ethereum via CrossChainController (0xEd42…B0e1) to per-chain Executors. On Arbitrum, verified on-chain: PoolAddressesProvider.owner = Executor Lvl 1 (0xFF11…6327), PayloadsController (0x8964…637C).owner = same Executor, CrossChainController.owner = same Executor — consistent with mainnet pattern. Execution depends on Aave Delivery Infrastructure bridge adapters; bridge compromise or message replay misconfiguration could delay or distort L2 governance execution. Granular Guardian (0x4457…251d4) contract exposes solveEmergency/retryEnvelope for CrossChainController recovery.

on-chain RPC via Etherscan APIEthereum CCC.owner() → 0x5300a1a15135ea4dc7ad5a167152c01efc9b192a; Arbitrum PAP.owner/CCC.owner → 0xff1137243698caa18ee364cc966cf0e02a4e6327; Arbitrum PayloadsController.owner → 0xff1137243698caa18ee364cc966cf0e02a4e6327
contract sourceGranularGuardianAccessControl: SOLVE_EMERGENCY_ROLE, RETRY_ROLE on CrossChainController
mediumTimelock enforced via PayloadsController access levels, not standalone TimelockController

Governance V3 uses PayloadsController queue delays rather than an OpenZeppelin TimelockController. Documented delays: Level 1 (short executor) ~86400s (1 day), Level 2 (long executor) ~604800s (7 days), plus additional cross-chain delivery time (~2 days for L2). PayloadsController and CrossChainController are upgradeable transparent proxies; upgrade authority recursively flows to the strictest Executor level. Direct on-chain delay reads via proxy eth_call reverted in this environment.

Aave Governance V3 activation planLevel 1 ~1 day, Level 2 ~7 days; L2 adds ~2 day cross-chain delay
contract sourcePayloadsControllerUtils.AccessControl: Level_1 short executor, Level_2 long executor
lowConfirmed DAO execution chain — not direct EOA control

Adversarial EOA check: no core contract owner() resolves to a bare EOA. Verified chain on Ethereum: PayloadsController.owner() → Executor Lvl 1; Executor Lvl 1.owner() → PayloadsController; Executor Lvl 2.owner() → PayloadsController. Both Executors execute only via PayloadsController after proposal passage and timelock. Governance Core (0x9AEE…2BC7) coordinates AAVE/stkAAVE on-chain voting.

on-chain RPC via Etherscan APIPayloadsController.owner() → 0x5300a1a15135ea4dc7ad5a167152c01efc9b192a; Executor Lvl1.owner() → 0xdabad81af85554e9ae636395611c58f7ec1aaec5; Executor Lvl2.owner() → 0xdabad81af85554e9ae636395611c58f7ec1aaec5
infoACLManager defines granular PoolAdmin, EmergencyAdmin, RiskAdmin roles

ACLManager (verified on L2 deployments) defines POOL_ADMIN, EMERGENCY_ADMIN, RISK_ADMIN, ASSET_LISTING_ADMIN, and BRIDGE_ADMIN roles. Per Aave governance forum, EMERGENCY_ADMIN (market pause) is assigned to Governance Guardian multisig; POOL_ADMIN and other operational roles are assigned to Executor Lvl 1 via governance. ACLManager on Ethereum is unverified in this workspace but follows the same bytecode pattern as other chains.

contract sourceACLManager: POOL_ADMIN_ROLE, EMERGENCY_ADMIN_ROLE, RISK_ADMIN_ROLE — grant/revoke controlled by ACL admin
Aave governance forumGuardian holds EMERGENCY ADMIN; governance Level 1 executor holds POOL ADMIN

Governance Checklist

Multisig Guardian (not EOA)Governance Guardian: 5-of-9 Gnosis Safe (verified on-chain)
Timelock on governance executionPayloadsController Level 1 ~1d / Level 2 ~7d (documented; proxy read unavailable)
On-chain token voting (AAVE/stkAAVE)Governance V3 Core + VotingMachine on Ethereum
No EOA core contract ownersPoolAddressesProvider owner = Executor Lvl 1 contract
Cross-chain governance parityArbitrum: PAP/CCC/PayloadsController all owned by local Executor Lvl 1
All executor bytecode verifiedEthereum Executor Lvl 1 unverified on Etherscan
Guardian powers fully eliminatedGuardian retains payload cancel + emergency pause authority

Upgrade Authority Chain (Ethereum, on-chain verified)

ContractOwner / AdminControl Type
PoolAddressesProvider0x5300A1a15135EA4dc7aD5a167152C01EFc9b192AExecutor Lvl 1 (governance timelock)
ACL Admin (getAddress)0x5300A1a15135EA4dc7aD5a167152C01EFc9b192AExecutor Lvl 1
CrossChainController0x5300A1a15135EA4dc7aD5a167152C01EFc9b192AExecutor Lvl 1
PayloadsController0x5300A1a15135EA4dc7aD5a167152C01EFc9b192AExecutor Lvl 1
Executor Lvl 10xdAbad81aF85554E9ae636395611C58F7eC1aAEc5PayloadsController
Executor Lvl 20xdAbad81aF85554E9ae636395611C58F7eC1aAEc5PayloadsController
Governance Guardian5-of-9 Gnosis SafeCommunity multisig (emergency)

Governance Guardian Multisig (verified on-chain)

governanceethereumGovernance Guardian Safe
governanceethereumGranular Guardian
Loading dependency graph…