DeFiPunk'd

Aave

7 deployments · $13.7B aggregate TVL · Lending

Deployments

Each deployment is rated independently. Pick one to see its rating, risk analysis, and stage.
TVL $13.2B
Type Lending
Chains Ethereum, Plasma, Arbitrum, Base, Avalanche +16
View on DeFiLlama ↗
Control — tentative orange Ability to exit — tentative red Autonomy — tentative orange Open Access — tentative orange Verifiability — tentative green Control Exit Autonomy Open Access Verifiable
Control criteria
Upgradeability Upgradeable Bug bounty audits.sherlock.xyz Governance forum governance.aave.com Docs aave.com
About

Aave V3 is a decentralized non-custodial lending protocol where users supply assets to earn interest and borrow assets by providing overcollateralized deposits. It operates across 20+ chains with isolated markets and risk parameters managed through on-chain AAVE token governance. The protocol uses a cross-chain governance system (Governance V3) with voting via storage proofs on multiple networks while token balances remain on Ethereum mainnet.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 225 addresses on file · 2 runs Submit run ↗
  • Verifiability ✓ 3/3 models agree AI-only weak green — weak consensus margin; only 0/3 sources have a public chat share link; total support weight 0.12 below confidence floor (1.5) Submit run ↗
  • Control ✓ 4/4 models agree AI-only weak orange — only 0/4 sources have a public chat share link; total support weight 0.38 below confidence floor (1.5) Submit run ↗
  • Ability to exit ✓ 3/3 models agree AI-only weak red — weak consensus margin; only 0/3 sources have a public chat share link; total support weight 0.12 below confidence floor (1.5) Submit run ↗
  • Autonomy ✓ 3/3 models agree AI-only weak orange — weak consensus margin; only 0/3 sources have a public chat share link; total support weight 0.12 below confidence floor (1.5) Submit run ↗
  • Open Access ✓ 3/3 models agree AI-only weak orange — only 0/3 sources have a public chat share link; total support weight 0.12 below confidence floor (1.5) Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative 3/3 models agree AI-only 0/3 with chat share link
    Pool/PoolConfigurator/PoolAddressesProvider all 'Source Code Verified - Exact Match' on Etherscan; deployed implementations correspond to aave-dao/aave-v3-origin@v3.6.0; v3.6 audited Nov 2025 by 5 recognized firms (Certora, MixBytes, Pashov, Blackthorn, Savant) ~2 months before on-chain upgrade Jan 2026.
    Verdict

    All three core Aave V3 contracts on Ethereum mainnet (Pool proxy 0x87870Bca..., PoolConfigurator proxy 0x64b761D8..., PoolAddressesProvider 0x2f39d218...) show 'Source Code Verified - Exact Match' on Etherscan. Both proxy AND current implementation contracts are independently verified: Pool implementation 0x8147b99d... ('PoolInstance', Solidity 0.8.27) and PoolConfigurator implementation 0x6fDdde45... ('PoolConfiguratorInstance', Solidity 0.8.27). The deployed implementations correspond to the public aave-dao/aave-v3-origin repo at tag v3.6.0 (commit 5a230ec82fcb10afc7fe7cffa8978752fb17aa2b): contract names match exactly, the v3.6.0 PoolInstance.sol declares POOL_REVISION=10 and PoolConfiguratorInstance.sol declares CONFIGURATOR_REVISION=7. The current v3.6 release was audited by five recognized firms (Certora, MixBytes, Pashov, Blackthorn, Savant) in Nov 2025, ~2 months before the on-chain upgrade (Jan 16, 2026), well within the 6-month freshness window. Earlier versions (V3 genesis, V3.0.1, V3.0.2, V3.1, V3.2, V3.3, V3.4, V3.5) were each independently re-audited by recognized firms (OpenZeppelin, Trail of Bits, ABDK, Sigma Prime, Peckshield, Certora, MixBytes, ChainSecurity, Sherlock), so post-audit drift is continuously addressed. Choosing green because all V1-V6 conditions hold with direct on-chain and repo evidence.

    Steelman argument
    Steelman argument Pool, PoolConfigurator and PoolAddressesProvider are all 'Verified - Exact Match' on Etherscan with both proxies and current implementations verified; deployed implementation source corresponds to aave-dao/aave-v3-origin @ tag v3.6.0 (5a230ec82fcb10afc7fe7cffa8978752fb17aa2b); five recognized firms audited v3.6 Nov 16-29 2025, only ~2 months before the on-chain upgrade Jan 16 2026 - all green-rule conditions hold.
    Evidence (6)
    V1
    Pool 0x87870Bca..., PoolConfigurator 0x64b761D8..., PoolAddressesProvider 0x2f39d218..., and ACLManager 0xc2aaCf65... all show 'Source Code Verified - Exact Match' on Etherscan.
    V6
    Both Pool and PoolConfigurator are EIP-1967 proxies; their current implementations 0x8147b99d... (PoolInstance) and 0x6fDdde45... (PoolConfiguratorInstance) are independently verified with exact-match status.
    V2
    Verified deployed sources correspond to aave-dao/aave-v3-origin tag v3.6.0 (commit 5a230ec82fcb10afc7fe7cffa8978752fb17aa2b): contract names PoolInstance and PoolConfiguratorInstance match the repo's src/contracts/instances/ folder, with POOL_REVISION=10 and CONFIGURATOR_REVISION=7 consistent with the v3.6.0 release.
    V3
    Audit coverage is dense and continuous: V3.6 audited by Blackthorn (2025-11-16), Certora (2025-11-18), MixBytes (2025-11-18), Savant (2025-11-18), Pashov (2025-11-29). Earlier versions V3.5/V3.4/V3.3/V3.2/V3.1/V3.0.x each have multiple firm audits (Certora, MixBytes, ABDK, OpenZeppelin, Trail of Bits, Sigma Prime, PeckShield, Sherlock, Oxorio, Enigma).
    V4
    All current and historical auditors are recognized: Certora (formal verification), Trail of Bits, OpenZeppelin, ABDK, Sigma Prime, PeckShield, MixBytes, ChainSecurity, Sherlock are explicitly listed in the recognized-firm rubric. Pashov, Blackthorn, Savant, StErMi, Enigma are well-known Solidity audit/contest firms in 2025-26 practice.
    V5
    On-chain Pool upgrade to v3.6 implementation occurred ~Jan 16, 2026, ~2 months after the Nov 2025 v3.6 audits, well within the 6-month freshness window. BGD Labs has shipped V3.0.1 -> V3.6 with separate audits per version, so historical post-audit drift has been continuously re-audited.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/3 sources have a public chat share link
    • total support weight 0.12 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 no url gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  2. Control tentative 4/4 models agree AI-only 0/4 with chat share link
    Aave V3 is governed by AAVE token-weighted on-chain governance with a 1-day timelock on the Short Executor path that can perform T1 fund-critical actions (upgrade Pool implementations, change oracles, pause markets). The 5-of-9 guardian multisig has veto-only power.
    Verdict

    Choosing orange because T1 fund-critical actions (Pool implementation upgrades via PoolAddressesProvider.setPoolImpl, oracle source changes) are reachable through the Short Executor path with only a 1-day (86400s) timelock delay, which is >0 but <7 days. While governance is broad and token-weighted with AAVE/stkAAVE/aAAVE, the 1-day timelock on the Short Executor is insufficient for the 7-day exit-window standard required for green on a T1 path. The guardian (5-of-9 multisig) has instant T1-scoped emergency pause power, but this is limited to pause/cancel and does not compound the timelock concern since it cannot execute upgrades. The Long Executor's 7-day timelock only covers T3 governance-internal changes, not the primary T1 upgrade path.

    Steelman argument
    Steelman argument T1 fund-critical actions (implementation upgrades, oracle changes) are reachable via the Short Executor with only a 1-day timelock, which is below the 7-day exit-window standard; the guardian multisig's pause power adds further instant T1 capability scoped to emergencies.
    Evidence (7)
    C1
    Governance V3 core (0x9AEE…BC7) is a TransparentUpgradeableProxy whose owner() is the Short Executor at 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A. The guardian() is the 5-of-9 multisig at 0xCe52ab41C40575B072A18C9700091Ccbe4A06710. The PayloadsController (0xdAbad81a…) also has owner() = 0x5300…5192A and guardian() = 0xCe52ab41…. The Executor (0x5300…) has owner() = PayloadsController (0xdAbad81a…), forming the chain: Governance V3 → PayloadsController → Executor → protocol contracts.
    C2
    Both Governance V3 (0x9AEE…BC7) and PayloadsController (0xdAbad81a…) are TransparentUpgradeableProxy contracts. The Governance proxy implementation is at 0x58BcB647…; PayloadsController implementation at 0x7222182c…. The Executor (0x5300…) is NOT a proxy — it is immutable. Upgradeability of proxies is controlled by the Executor, which is itself controlled by PayloadsController (i.e., governance proposals). The Pool (0x87870bca…) is also a proxy managed via the PoolAddressesProvider, whose owner is the Executor. Overall: upgradeable.
    C3
    EXECUTION PATH (Short Executor / Level 1 — most protocol updates): (1) Proposal created on Governance V3 at 0x9AEE…BC7; (2) coolDownBeforeVotingStart (docs state 1 day for short path); (3) voting period of 3 days (MIN_VOTING_DURATION = 259200s on-chain); (4) vote results relayed via CrossChainController → PayloadsController queues payload; (5) MIN_EXECUTION_DELAY = 86400s (1 day) on PayloadsController at 0xdAbad81a…; (6) Executor 0x5300… executes via executeTransaction. The uncontested fast-path TIMELOCK DELAY is 1 day (86400s). The Long Executor path (Level 2) for governance-internal changes has a 7-day timelock and 10-day voting period per docs.
    C4
    Guardian multisig at 0xCe52ab41C40575B072A18C9700091Ccbe4A06710 is a 5-of-9 Gnosis Safe v1.3.0. Nine owners: 0xDA5A…BE7D, 0x1e38…8885, 0x4f96…1DC9, 0xebED…FE29, 0xbd4D…d4B7, 0xA310…7396, 0x936C…9EF3, 0x0D23…0E9, 0x4C30…099f. Per Aave docs, composed of 'highly active entities within the Aave DAO, such as service providers and delegates.' The guardian can cancel governance proposals and payloads (veto power) but cannot execute or upgrade. GranularGuardian (0x4457cA11…) has SOLVE_EMERGENCY_ROLE and RETRY_ROLE for cross-chain emergency management on CrossChainController only. Signer identities are not fully publicly enumerable from on-chain data alone — per docs they are service providers and delegates, making insider/non-insider classification uncertain.
    C5
    On-chain governance uses AAVE, stkAAVE, and aAAVE token-weighted voting via Governance V3 at 0x9AEE…BC7. MIN_VOTING_DURATION = 259200s (3 days) read on-chain. ACHIEVABLE_VOTING_PARTICIPATION = 5,000,000e18 (5M AAVE). Docs: Short Executor proposals require 3-day voting period and 1-day timelock; Long Executor proposals require 10-day voting period and 7-day timelock. Voting configs per access level are set via getVotingConfig(uint8) but the API endpoint was blocked during this run. Docs confirm quorum and vote differential requirements exist.
    C6
    The Protocol Guardian (5-of-9 multisig at 0xCe52ab41…) holds EMERGENCY_ADMIN role and can pause markets and cancel proposals/payloads. This is a separate emergency power from the main upgrade/governance path. Per Aave docs, this guardian is 'responsible for acting swiftly in emergency situations to protect the protocol.' The guardian can pause but pausing is time-bounded by the need for governance to unpause or the guardian to lift the pause. The guardian CANNOT upgrade contracts or change implementations — only cancel/pause.
    C7
    POWER TIER — T1 (FUND-CRITICAL) is reachable on the Short Executor (Level 1) path. The Executor at 0x5300… is the ACL Admin for Aave V3 and can call PoolAddressesProvider.setPoolImpl() to replace the Pool implementation (holding user funds), set oracle sources via AaveOracle, and configure reserve parameters via PoolConfigurator. These are T1 functions (replace implementation of fund-holding contracts, change oracle sources). The Long Executor (Level 2) handles T3 governance-internal changes with a 7-day timelock. The guardian's pause power is also T1-scoped (can freeze withdrawals) but is veto/pause only, not an upgrade path.
    Why is this consensus tentative?
    • only 0/4 sources have a public chat share link
    • total support weight 0.38 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-6 (autorun) no url claude-opus-4-7 no url gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  3. Ability to exit tentative 3/3 models agree AI-only 0/3 with chat share link
    Aave V3 withdraw/repay/liquidationCall are gated by ReservePaused; 5-of-9 Protocol Guardian Safe (EMERGENCY_ADMIN) can call setPoolPause unilaterally with NO time cap on the paused state — pause persists until same admin clears it. No escape hatch, no auto-expiry.
    Verdict

    Choosing red because withdraw/repay/repayWithATokens/repayWithPermit/liquidationCall all delegate to library validators that revert with Errors.ReservePaused() when the reserve's paused bit is set. The pause bit is set/cleared by PoolConfigurator.setReservePause/setPoolPause, gated by onlyEmergencyOrPoolAdmin, callable by either the EMERGENCY_ADMIN_ROLE holder (Aave Protocol Guardian Safe 0x2CFe3ec4d5a6811f4B8067F0DE7e47DfA938Aa30, verified 5-of-9 Gnosis Safe) or POOL_ADMIN_ROLE holder (Aave Governance v3 Executor Lvl1, 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A, timelocked governance). Critically, neither setPoolPause nor setReservePause take a maximum-duration parameter that bounds the paused state: MAX_GRACE_PERIOD = 4 hours caps only the post-unpause liquidation grace window, not the pause itself. There is no auto-expiry, no escape-hatch / forced-exit mechanism, and no separate already-finalized-claim path that bypasses the pause guard - withdrawal IS the exit, and it is pause-gated. The 5-of-9 emergency-admin multisig can therefore freeze user withdrawals indefinitely without a governance vote, matching the slice's red criterion 'ANY actor (including governance) can pause CLAIMS of finalized exits indefinitely'. Functions are directly callable on-chain via Etherscan Write-as-Proxy and any wallet (no frontend dependency).

    Steelman argument
    Steelman argument withdraw/repay/liquidationCall all revert under ReservePaused; setPoolPause and setReservePause are callable by a 5-of-9 multisig (EMERGENCY_ADMIN) with NO time cap on the paused state itself, no auto-expiry, no escape hatch. Per the slice rubric 'ANY actor (including governance) can pause CLAIMS of finalized exits indefinitely' = red.
    Evidence (7)
    E1
    User-facing exit functions on Pool: withdraw(asset,amount,to), repay(asset,amount,interestRateMode,onBehalfOf), repayWithATokens(asset,amount,interestRateMode), repayWithPermit(asset,amount,interestRateMode,onBehalfOf,deadline,permitV,permitR,permitS), liquidationCall(collateralAsset,debtAsset,borrower,debtToCover,receiveAToken). All public/virtual/override and delegate to SupplyLogic.executeWithdraw / BorrowLogic.executeRepay / LiquidationLogic.executeLiquidationCall.
    E2
    ValidationLogic enforces pause guards: validateWithdraw -> require(!isPaused, Errors.ReservePaused()); validateRepay -> require(!isPaused, Errors.ReservePaused()); validateLiquidationCall -> require(!collateralReservePaused && !principalReservePaused, Errors.ReservePaused()). All exit paths are pause-gated; freeze gates only NEW debt creation (validateBorrow) and supply, not repay/withdraw.
    E3
    PoolConfigurator.setPoolPause(bool paused) external onlyEmergencyOrPoolAdmin -> calls setPoolPause(paused, 0); setReservePause(asset, paused, gracePeriod) public onlyEmergencyOrPoolAdmin. MAX_GRACE_PERIOD = 4 hours but the require(gracePeriod <= MAX_GRACE_PERIOD) only fires when UNPAUSING and bounds the post-unpause liquidation grace window. The PAUSE itself is a boolean with no expiry timestamp - it persists until explicitly unpaused.
    E4
    Two pause paths: (1) EMERGENCY_ADMIN_ROLE held by Protocol Guardian 0x2CFe3ec4d5a6811f4B8067F0DE7e47DfA938Aa30 (verified 5-of-9 Gnosis Safe), unilateral pause without governance. (2) POOL_ADMIN_ROLE held by 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A (Aave Governance v3 Executor Lvl1, timelocked). Emergency-admin path has no time cap; pool-admin path requires governance vote.
    E5
    Aave V3 has NO queued redemption, NO daily withdrawal cap, NO multi-block claim phase. SupplyLogic.executeWithdraw burns aTokens and transfers underlying in the same call/block. Only constraint is reserve liquidity and health factor.
    E6
    Aave V3 has NO permissionless escape-hatch / forced-exit mechanism. Pool.sol exposes no function that bypasses ValidationLogic.validateWithdraw's ReservePaused require. There is no time-locked auto-unpause, no governance-bypass exit, no aToken redemption path that ignores Pool state.
    E7
    Etherscan exposes Pool proxy under 'Write as Proxy', delegating to verified implementation. withdraw/repay/repayWithATokens/repayWithPermit/liquidationCall are all directly callable via Etherscan Web3 Connect or any generic wallet/SDK without any Aave-frontend dependency. Recent transaction history confirms organic non-frontend calls. No referrer check, no signed-attestation required.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/3 sources have a public chat share link
    • total support weight 0.12 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 no url gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  4. Autonomy tentative 3/3 models agree AI-only 0/3 with chat share link
    Aave V3 has multi-layered oracle safety (CAPO caps, fallback, PriceOracleSentinel, Umbrella) and 1-day/7-day governance timelocks, but per-reserve oracle sources are governance-mutable on a 1-day delay (Level 1 executor) plus Risk-Steward multisig fast-paths; March 2026 CAPO misconfig caused ~$27M and April 2026 Kelp/rsETH bridge exploit pushed ~$200M of bad debt into V3 markets. Impacted TVS realised ~1-2% (~$200M of ~$13.6B).
    Verdict

    Choosing orange because Aave V3 Core Lending (Ethereum + L2s, ~99% of $13.6B TVS) holds the dominant share; GHO module (~$200M GHO outstanding, <2% of TVS) and Umbrella Safety Module are smaller. The core architecture is verifiable on-chain: AaveOracle (0x54586bE62E3c3580375aE3723C145253060Ca0C2) reads per-asset Chainlink/CAPO sources with a configurable fallback, gated by POOL_ADMIN/ASSET_LISTING_ADMIN roles held by Executor Lvl1 (1-day timelock via PayloadsController) and bypassable for narrow params by Risk Stewards (1-of-1 / 2-of-2 multisig with on-chain constraints). PriceOracleSentinel and CAPO caps are LIVE on-chain mitigations against external oracle anomalies. Two real 2026 incidents bound the grade: (a) March-2026 CAPO snapshot/timestamp misconfiguration caused ~$27M unfair wstETH liquidations (DAO reimbursed via treasury), (b) April-2026 Kelp DAO LayerZero bridge exploit minted unbacked rsETH that an attacker deposited as Aave V3 collateral on Ethereum + Arbitrum, leaving ~$200M of bad debt that the DAO is socializing. Aave's smart contracts functioned as designed in (b) - the loss came from an opt-in third-party LRT - but rsETH was not isolation-mode-only and the bad debt cross-cuts the WETH reserve via shortfall. Together with the 1-day-only timelock on most oracle-relevant actions (Level 1) and the Risk Steward fast-path, this fits Stage 1 / orange: external dependency failures can degrade performance and create bounded principal loss but cannot trivially drain the protocol; mitigations are partial and have been observed to fail.

    Steelman argument
    Steelman argument External dependency failures can cause bounded performance degradation and bounded principal loss (March-2026 CAPO: ~$27M, refunded; April-2026 Kelp: ~$200M, partly covered by Aave + DeFi-United bailout), but defense-in-depth (CAPO caps, PriceOracleSentinel for L2 sequencer outages, Umbrella slashing, Protocol Guardian freeze, governance timelocks of 1-day / 7-day, isolation mode and supply caps per reserve) prevents catastrophic protocol-wide drains, and the contracts themselves continued functioning as designed during both incidents.
    Evidence (12)
    A1
    AaveOracle (0x54586bE62E3c3580375aE3723C145253060Ca0C2) is the only oracle entrypoint for the Pool. Per-reserve assetsSources mapping holds one Chainlink-compatible aggregator address per asset; for LSTs/LRTs (wstETH, rsETH, weETH, ezETH, osETH) Aave uses CAPO (PriceCapAdapter) adapters wrapping Chainlink feeds with a max-yearly-growth cap on the exchange-rate ratio. getAssetPrice flow: if asset==BASE_CURRENCY return BASE_CURRENCY_UNIT; else read source.latestAnswer(); if price<=0 or no source set, fall back to _fallbackOracle. On Ethereum mainnet _fallbackOracle is currently the zero address per the deployed code, so a reserve with assetsSources[asset]==0 would revert.
    A2
    No off-chain reporter committee writes prices into Aave's contracts. Chainlink's own DON is upstream substrate not a committee that this protocol selects. CAPO snapshots are pushed by Risk Stewards (Risk Council multisig 0x8513e6f37dbc52de87b166980fa3f50639694b60) under on-chain constrained debounce (max 3% ratio change per 3-day window) - March-2026 incident showed the constraint is enforced on ratio but can be bypassed on snapshotTimestamp semantics, causing 2.85% underpricing. GHO Stewards multisig is 3-of-4 and adjusts GHO bucket capacities/borrow rates within bounds. Protocol Guardian is a 5-of-9 Safe holding EMERGENCY_ADMIN - pause-only, cannot mint/burn/finalize.
    A3
    Cross-chain dependencies: (i) GHO bridged to Arbitrum/Base/Avalanche/Gnosis/Mantle via Chainlink CCIP; (ii) Aave Governance V3 cross-chain message delivery uses a.DI Cross-Chain Controller with 2-of-3 consensus across LayerZero + Chainlink CCIP + Hyperlane; (iii) per-chain L2/sidechain canonical bridges secure the substrate. April-2026 Kelp DAO bridge incident (NOT an Aave bridge - third-party Kelp LayerZero bridge with 1-of-1 DVN config) minted unbacked rsETH that was deposited as collateral; ~$200M bad debt cross-cuts Aave V3 Core (Ethereum), Arbitrum, Base, Mantle, Linea, Avalanche, Ink.
    A4
    Aave lists LSTs (wstETH, weETH, osETH, rETH) and LRTs (rsETH, ezETH) as opt-in per-market reserves. Collateral chain depth is: Aave reserve -> LST/LRT token contract -> staking/restaking module -> Ethereum validators / EigenLayer AVSs (depth 2-4 levels). At each level, slashing/freeze power exists. April-2026 Kelp incident is the materialized version: a failure 2 levels deep (Kelp's bridge) effectively coined unbacked rsETH that propagated to Aave principal via collateralized borrow. rsETH was NOT isolation-mode-only on Aave V3 (listed as borrowable across multiple chains) so the failure leaked ~$200M of bad debt into general WETH reserves, requiring Umbrella + treasury + DeFi-United bailout to socialize.
    A5
    DeFiLlama forkedFrom for aave-v3 is empty / Aave V3 is the original (forks include Spark, Radiant, Hyperliquid native lending, etc.). No upstream dependency from a forked codebase.
    A6
    Active mitigations (status = LIVE on-chain unless otherwise noted): (i) AaveOracle fallback oracle slot - DEPLOYED but currently unset on Ethereum mainnet, partial mitigation only; (ii) CAPO PriceCapAdapter wrapping Chainlink feeds for LSTs/LRTs - LIVE, did NOT prevent March-2026 wstETH 2.85% underpricing; (iii) PriceOracleSentinel - LIVE on every L2 deployment; (iv) Reserve Pause / Reserve Freeze - LIVE; (v) Per-asset supply/borrow caps & isolation mode - LIVE; (vi) Umbrella Safety Module - LIVE for selected assets, used in April-2026 incident response; (vii) Risk Steward debounce/magnitude bounds - LIVE on-chain. Unmitigated: (a) AaveOracle fallback unset on Ethereum, (b) per-reserve oracle source has no second-opinion oracle nor on-chain sanity check inside Aave, (c) no per-block throughput caps independent of asset cap.
    A7
    Aave V3 deployed on Ethereum (substrate, ~82% of TVS at $11.22B / $13.64B per DeFiLlama) and on multiple L2s/sidechains. Each L2 deployment inherits its sequencer + canonical bridge trust model. Aave's PriceOracleSentinel disables borrows + adds liquidation grace period if the L2 sequencer feed reports down. Sequencer freeze does not steal funds but freezes positions; canonical bridge failure on the L2 itself is substrate.
    A8
    Liquidation bots are permissionless - anyone can call liquidationCall on the Pool. April-2026 Kelp incident demonstrated bot dependency: ~$300M borrow spike + frozen rsETH meant liquidations could not run on the unbacked positions; the Protocol Guardian froze + LTV-zero'd rsETH within hours, but bad debt (~$200M) crystallized. Failure mode is graceful (debt -> DAO socialisation via Umbrella + treasury) rather than catastrophic protocol-wide insolvency.
    A9
    Governance-mutable external dependency surface: (i) AaveOracle.setAssetSources and setFallbackOracle are gated only by onlyAssetListingOrPoolAdmins (ACLManager), no in-contract timelock - protection is governance-level: POOL_ADMIN role is held by Executor Lvl1 owned by PayloadsController enforcing 1-day timelock for Level 1, 7-day for Level 2. (ii) CAPO PriceCapAdapter.setCapParameters is callable by RISK_ADMIN or POOL_ADMIN - RISK_ADMIN held by Risk Stewards (Risk Council multisig, 1-of-1 / 2-of-2 with on-chain debounce constraints, NO timelock). (iii) PoolAddressesProvider.setPriceOracle could swap entire AaveOracle - Level 2 (7-day timelock). (iv) PoolConfigurator.setReserveInterestRateStrategy, freeze/unfreeze, supply/borrow cap changes - POOL_ADMIN (1 day) or RISK_ADMIN. (v) GHO facilitator add/remove + bucket capacity - GHO Stewards 3-of-4 multisig within bounds. Net: an external oracle source for any single asset can be hot-swapped after 1-day timelock by governance, OR within steward-bounded magnitudes with no timelock. This is the strongest A9 finding driving the orange grade.
    A6-incident-1
    March-10-2026 CAPO oracle incident on wstETH: a Risk-Steward update simultaneously updated snapshotRatio and snapshotTimestamp in a way that broke the implicit invariant between them. The cap held against single-update manipulation but the timestamp drift caused latestAnswer to return ~1.1939 while the live wstETH/stETH ratio was ~1.228, a 2.85% underpricing of wstETH collateral. Result: ~10,938 wstETH (~$27.1M) of borrower positions liquidated unfairly, ~499 ETH of liquidation bonuses captured by liquidators. DAO refunded via treasury. This is a materialized A6/A9 failure mode: the CAPO mitigation itself, mutated by the steward path with no timelock, caused user loss.
    A4-incident-2
    April-18-to-20-2026 Kelp DAO / rsETH incident: attacker exploited Kelp DAO's LayerZero V2 Unichain<->Ethereum bridge (1-of-1 DVN configuration) to mint 116,500 unbacked rsETH (~$292M, ~18% of rsETH circulating supply). Attacker deposited 89,567 of the stolen rsETH into Aave V3 across Ethereum Core and Arbitrum and borrowed ~$190M of WETH/other assets. Aave's contracts functioned as designed. Protocol Guardian froze rsETH and wrsETH markets across V3 deployments within hours and set LTV to 0. DAO raised ~$160M of needed ~$200M via 'DeFi United' (Lido, EtherFi, Ethena) + Stani Kulechov 5,000 ETH. Aave V3 TVL dropped from ~$26.4B to ~$17.9B over 2 days. Confirms A4 underlying-asset / A3 third-party-bridge propagation into general protocol bad debt despite per-market caps.
    A1-modules
    Sub-module enumeration with TVS weighting: (a) Aave V3 Core Lending (~$13.64B aggregated; Ethereum 82%, Arbitrum 4.3%, Avalanche 2.4%, others) - grade orange driven by A9 oracle-mutability + materialized incidents. (b) GHO module (~$200M GHO outstanding, <2% of TVS) - depends on Chainlink CCIP for cross-chain GHO and on the Aave Pool oracle for borrow-against-collateral; same orange tier. (c) Umbrella Safety Module - protective layer, semi-isolated. (d) Stata Token / ERC4626 wrapper - passthrough on aTokens. Weighted overall: Module A holds ~98% of TVS (orange), Modules B+C+D combined ~2% (orange). Weighted overall = orange.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/3 sources have a public chat share link
    • total support weight 0.12 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 no url gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  5. Open Access tentative 3/3 models agree AI-only 0/3 with chat share link
    Smart contracts are admission-permissionless; official frontend app.aave.com applies TRM Labs wallet screening + ToS restricted-jurisdiction enforcement. Independent A3b-ii paths exist (cp0x pi-aave-interface, direct contract calls) but are third-party-operated.
    Verdict

    Choosing orange because Aave V3 smart contracts are admission-permissionless (Pool.supply/withdraw/borrow/repay/liquidationCall/flashLoan are public virtual override with no whitelist/KYC modifier per Pool.sol @ commit 1e3d70c4151a94166ebc59e2eaa4aff6e6ba6978), but the official frontend app.aave.com applies A3-active enforcement via TRM Labs API integration which screens connected wallets and rejects flagged ones (publicly confirmed by Aave Labs in the 2022 dusted-wallets incident: 'We integrated TRM's API on the Aave IPFS frontend'), and the ToS at aave.com/legal/app/terms-of-service explicitly reserves the right to restrict access on the basis of Restricted Jurisdictions (Belarus, Cuba, Iran, North Korea, Russia, Syria, Venezuela, etc.) and to act when users attempt circumvention through VPNs or proxies. Independent A3b-ii paths exist (cp0x pi-aave-interface live at aave.cp0x.com under MIT license, direct contract calls via Etherscan, CLI/SDK), but they are operated by third parties or require technical capability and are not officially documented by Aave on its public landing pages. Per the rubric, A3-active screening on the official frontend without clearly-documented non-technical alternatives places this slice at orange, not green. Red is not appropriate because there is no contract-level whitelist, no on-chain blocklist updated by a single party, and no operator approval gating admission.

    Steelman argument
    Steelman argument The official protocol-branded frontend (app.aave.com, operated by Aave Interfaces Ltd / Aave Labs) actively screens wallet addresses against TRM Labs and explicitly enforces Restricted-Jurisdiction policy with anti-VPN-circumvention language, and while alternatives exist they are run by third parties (cp0x) or require CLI/Etherscan skills, so admission via the canonical interface is non-trivially gated for non-technical users.
    Evidence (9)
    A1
    Pool.sol user-facing functions supply, supplyWithPermit, withdraw, borrow, repay, repayWithPermit, repayWithATokens, liquidationCall, flashLoan, flashLoanSimple are declared public virtual override with no onlyWhitelisted/onlyRole/isAccredited/isKYCed/allowlist modifier. Only modifiers in Pool.sol are onlyPoolConfigurator, onlyPoolAdmin, onlyPositionManager(address onBehalfOf), onlyUmbrella - all gating admin operations, not user entry. grep on Pool.sol returned no matches for whitelist|allowlist|isAccredited|isKYCed|sanction.
    A2
    User-facing supply/withdraw/borrow/repay route to SupplyLogic.executeSupply / SupplyLogic.executeWithdraw / BorrowLogic.executeBorrow / BorrowLogic.executeRepay with user: _msgSender(); no off-chain keeper/sequencer/relayer approval is required to admit the action. Liquidations are open to any caller (liquidationCall is public). No operator committee gates admission.
    A3-active
    Aave Labs publicly confirmed runtime wallet screening on the official frontend in the August-2022 dusted-wallets incident: 'We integrated TRM's API on the Aave IPFS frontend, which is why some users may be experiencing trouble accessing the Aave app.' The governance forum thread 'Address Blocking and TRM Labs' confirms that Aave 'use[s] TRM Labs to scan for supposed illegal or sanctioned activity' with blocked accounts 'only banned from using their front end- not from using the Aave protocol entirely.' Satisfies evidentiary floor (d) public incident report + (c) named third-party screening provider.
    A3-passive
    ToS at aave.com/legal/app/terms-of-service Section 2.3: 'access to and use of the Services is prohibited for any person or entity that is located in, organized under the laws of, or ordinarily resident in any country or territory that is, or whose government is, the subject of comprehensive trade or economic sanctions ... including, without limitation, Belarus, Cote d'Ivoire, Crimea, Cuba, Donetsk PR, Iran, Iraq, Kherson, Liberia, Libya, Luhansk PR, Myanmar, North Korea, Russia, Sudan, Syria, Venezuela, Zaporizhzhia.' Anti-circumvention clause: 'The Company reserves the right ... if you attempt to circumvent such restrictions through virtual private networks, proxies, or similar technologies.' These are passive eligibility/attestation clauses; their grade-weight is ~0.25.
    A3b-i
    Aave's official frontend is also pinned to IPFS (referenced by Aave Labs as the 'Aave IPFS frontend' in the TRM incident statement). The same ToS defines 'Interface' as 'an independent interface providing one of the available applications through which users, via their self-custodial wallets, interact with the Aave Protocol' and 'Services' as 'both the Aave.com website ... and App.aave.com interface'. IPFS-pinned redistributions of the official UI remain bound by the same ToS and so are not an independent A3b-ii path.
    A3b-ii
    cp0x maintains pi-aave-interface, an independent permissionless frontend for Aave V3, deployed live at https://aave.cp0x.com (HTTP/1.1 200 from nginx, served from cp0x infrastructure, distinct legal entity from Aave Interfaces Ltd). Repo (github.com/cp0x-org/pi-aave-interface) is publicly accessible, MIT-licensed, README states 'An open-source, permissionless interface for the Aave protocol, designed to be fully permissionless and enable direct, unrestricted interaction with smart contracts.' Aave's TRM-labs-block incident report explicitly notes 'Users could still connect via CLI or forking the front-end to host in their environments.' These paths exist but are not officially advertised on aave.com landing pages and skew technical.
    A4
    Off-chain compliance tooling: TRM Labs API integrated on the official IPFS-hosted frontend to screen wallet addresses against sanctions lists (confirmed by Aave Labs in the dusted-wallets incident and the governance forum thread 'Address Blocking and TRM Labs'). Privacy Policy at aave.com/privacy-policy: 'We may collect the wallet address you use to connect to the Interface to block wallets that are associated with certain legally prohibited conduct from Interface.' No on-chain OFAC oracle (Chainalysis Sanctions Oracle) is checked by Pool.sol; screening is exclusively at the application/frontend layer.
    A5
    Read access: fully permissionless on-chain (any caller can call view functions getReserveData, getUserAccountData, getReservesList, etc. on the verified proxy 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2). Write access: permissionless at the contract layer (no modifier gates supply/withdraw/borrow/repay), but the official app.aave.com frontend gates write access by wallet via TRM screening + ToS jurisdictional self-attestation. The split between contract-level (open) and frontend-level (gated) is the central observation.
    A6
    Two canonical ToS endpoints exist: aave.com/terms-of-service (older, naming OFAC/UN/EU/HM Treasury sanction lists) and aave.com/legal/app/terms-of-service (newer, with explicit VPN/proxy circumvention clause). Operator entity: 'Aave Interfaces Ltd ... Aave Labs, Company, we, us, or our.' Privacy Policy at aave.com/privacy-policy contains the wallet-blocking disclosure verbatim.
    Why is this consensus tentative?
    • only 0/3 sources have a public chat share link
    • total support weight 0.12 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 no url gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

Aave V3 has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 240addresses
  • 11verified source
  • 0proxies

TVL adapter pinned at 683d369. Sourcecode fetched 2026-05-06. Control fetched 2026-05-07.

Arbitrumadmin ACLAdmin V30xff11…6327discovery———governance
Arbitrumadmin ACLManager V30xa726…4a0bdiscovery————
Arbitrumadmin PoolConfigurator V30x8145…021ediscovery————
Arbitrumfactory PoolAddressesProvider V30xa976…3cdbdiscovery———factory
Arbitrumguardian GranularGuardian0x4922…37cediscovery———guardian
Arbitrumoracle AaveOracle V30xb56c…c7c7discovery———oracle
Arbitrumoracle PriceOracleSentinel V30x7a9f…686bdiscovery———oracle
Arbitrumother AaveProtocolDataProvider V30x243a…c43bdiscovery————
Arbitrumother CrossChainController0xcbfb…29f0discovery————
Arbitrumpool Pool V30x794a…14addiscovery———token
Arbitrumtimelock PayloadsController0x8964…637cdiscovery———timelock
Avalancheadmin ACLAdmin V30x3c06…d090discovery———governance
Avalancheadmin ACLManager V30xa726…4a0bdiscovery————
Avalancheadmin PoolConfigurator V30x8145…021ediscovery————
Avalanchefactory PoolAddressesProvider V30xa976…3cdbdiscovery———factory
Avalancheguardian GranularGuardian0xc116…7b65discovery———guardian
Avalancheoracle AaveOracle V30xebd3…7c9cdiscovery———oracle
Avalancheoracle EmergencyOracle0x4118…ebeediscovery———oracle
Avalancheother AaveProtocolDataProvider V30x243a…c43bdiscovery————
Avalancheother CrossChainController0x27fc…0928discovery————
Avalancheother VotingMachine0x9b6f…494fdiscovery————
Avalanchepool Pool V30x794a…14addiscovery————
Avalanchetimelock PayloadsController0x1140…0b80discovery———timelock
Baseadmin ACLAdmin V30x9390…257adiscovery———governance
Baseadmin ACLManager V30x4395…fd33discovery————
Baseadmin PoolConfigurator V30x5731…96bediscovery————
Basefactory PoolAddressesProvider V30xe20f…d64ddiscovery———factory
Baseguardian GranularGuardian0xa1c6…f4bbdiscovery———guardian
Baseoracle AaveOracle V30x2cc0…e156discovery———oracle
Baseoracle PriceOracleSentinel V30x943a…74d6discovery———oracle
Baseother AaveProtocolDataProvider V30x0f43…c73adiscovery————
Baseother CrossChainController0x5294…04e2discovery————
Basepool Pool V30xa238…d1c5discovery————
Basetimelock PayloadsController0x2dc2…ab01discovery———timelock
Binanceadmin ACLAdmin V30x9390…257adiscovery———governance
Binanceadmin ACLManager V30x2d97…3877discovery————
Binanceadmin PoolConfigurator V30x67bd…9584discovery————
Binancefactory PoolAddressesProvider V30xff75…ba6ddiscovery———factory
Binanceguardian GranularGuardian0xe4fb…4383discovery———guardian
Binanceoracle AaveOracle V30x39bc…c697discovery———oracle
Binanceoracle EmergencyOracle0xcabb…f7f1discovery———oracle
Binanceother AaveProtocolDataProvider V30xc90d…5328discovery————
Binanceother CrossChainController0x9d33…fa19discovery————
Binancepool Pool V30x6807…e0cbdiscovery————
Binancetimelock PayloadsController0xe5ef…e627discovery———timelock
Celoadmin ACLAdmin V30x1df4…053ddiscovery———governance
Celoadmin ACLManager V30x7a12…314cdiscovery————
Celoadmin PoolConfigurator V30x7567…4691discovery————
Celofactory PoolAddressesProvider V30x9f7c…cea5discovery———factory
Celooracle AaveOracle V30x1e69…7e8bdiscovery———oracle
Celoother AaveProtocolDataProvider V30x2e0f…15eddiscovery————
Celopool Pool V30x3e59…3402discovery————
Celotreasury Collector0xc959…e9e7discovery———treasury
ethereumAaveProtocolDataProvider0x0879…31cdTVL✓———
ethereumPendlePrincipalToken0x3de0…0f49TVL✓———
ethereumAaveProtocolDataProvider0x4139…8cbdTVL✓———
ethereumPendlePrincipalToken0x62c6…38b7TVL✓———
ethereumPendlePrincipalToken0x9bf4…b375TVL✓———
ethereumPendlePrincipalToken0xaebf…6ce0TVL✓———
ethereumPendlePrincipalToken0xbc67…e10aTVL✓———
ethereumPendlePrincipalToken0xe6a9…49b3TVL✓———
ethereumAaveProtocolDataProvider0xe7d4…5758TVL✓———
ethereumPendlePrincipalToken0xe848…d7b2TVL✓———
Ethereumadmin (Aave V4 Access Manager — Ethereum)0x08ae…df01discovery————
Ethereumadmin (PoolAdmin / governance executor)0xee56…9413discovery———timelock
Ethereumadmin ACLManager V30xc2aa…85b0discovery————
Ethereumadmin DefaultIncentivesController0x8164…bfcbdiscovery————
Ethereumadmin EmissionManager0x223d…d974discovery————
Ethereumadmin PoolConfigurator V30x64b7…bb27discovery————
Ethereumgovernor Governance V30x9aee…2bc7discovery———governance
Ethereumguardian (governance guardian / payload cancellation guardian)0xce52…6710discovery———multisig
Ethereumguardian (Protocol Guardian / emergency admin)0x2cfe…aa30discovery———multisig
Ethereumguardian EmergencyRegistry0x73c6…c7e9discovery———guardian
Ethereumguardian GranularGuardian0x4457…51d4discovery———guardian
Ethereumoracle AaveOracle V30x5458…a0c2discovery———oracle
Ethereumother (PayloadsController)0xdaba…aec5discovery————
Ethereumother (PoolAddressesProvider — proxy admin for Pool/PoolConfigurator/ACLManager)0x2f39…4e9ediscovery———governance
Ethereumother (Prime Market PoolAddressesProvider)0xcfbf…b16ddiscovery————
Ethereumother AaveProtocolDataProvider V30x0a16…becddiscovery————
Ethereumother CrossChainController0xed42…b0e1discovery————
Ethereumother DataWarehouse0x1699…cf61discovery————
Ethereumother GovernanceDataHelper0x971c…1856discovery————
Ethereumother GovernancePowerStrategy0xa198…1e04discovery————
Ethereumother MetaDelegateHelper0x9436…85dcdiscovery————
Ethereumother PayloadDataHelper0xe3b7…e16adiscovery————
Ethereumother VotingDataHelper0x7797…50e8discovery————
Ethereumother VotingMachine0x6173…75ebdiscovery————
Ethereumother VotingPortalEthAvax0x33ac…5d79discovery————
Ethereumother VotingPortalEthEth0xf23f…e21fdiscovery————
Ethereumother VotingPortalEthPol0x9b24…36c3discovery————
Ethereumother VotingStrategy0x5642…a7f4discovery————
Ethereumpool (Aave V3 Pool proxy)0x8787…a4e2discovery————
Ethereumtimelock (ACL admin / executor)0x5300…192adiscovery———timelock
Ethereumtimelock (executor level 2)0x17dd…6957discovery———timelock
Ethereumtimelock (governance executor short)0xee56…9b17discovery———timelock
Ethereumtimelock (governance long executor)0xa700…963ediscovery———timelock
Ethereumtimelock (governance short executor)0x80c6…bcf8discovery———timelock
Ethereumtimelock (governance short executor)0x8513…9921discovery———timelock
Ethereumtimelock (short executor governance)0x220d…c540discovery———timelock
Ethereumtoken AAVE governance token0x7fc6…dae9discovery———governance
Ethereumtreasury Collector0x464c…e18cdiscovery———treasury
Ethereumvault (Aave V4 Core Hub — Ethereum)0xcca8…26c9discovery———vault
Ethereumvault (Aave V4 Plus Hub — Ethereum)0x0600…536adiscovery———vault
Ethereumvault (Aave V4 Prime Hub — Ethereum)0x9438…f931discovery———vault
Fantomadmin ACLAdmin V30x39cb…c949discovery———governance
Fantomadmin ACLManager V30xa726…4a0bdiscovery————
Fantomadmin PoolConfigurator V30x8145…021ediscovery————
Fantomfactory PoolAddressesProvider V30xa976…3cdbdiscovery———factory
Fantomoracle AaveOracle V30xfd6f…0754discovery———oracle
Fantomother AaveProtocolDataProvider V30x69fa…0654discovery————
Fantompool Pool V30x794a…14addiscovery————
Harmonyadmin ACLAdmin V30xb2f0…cd2ddiscovery———governance
Harmonyadmin ACLManager V30xa726…4a0bdiscovery————
Harmonyadmin PoolConfigurator V30x8145…021ediscovery————
Harmonyfactory PoolAddressesProvider V30xa976…3cdbdiscovery———factory
Harmonyoracle AaveOracle V30x3c90…80addiscovery———oracle
Harmonyother AaveProtocolDataProvider V30x69fa…0654discovery————
Harmonypool Pool V30x794a…14addiscovery————
Lineaadmin ACLAdmin V30x8c2d…7f88discovery———governance
Lineaadmin ACLManager V30xbf32…dbb5discovery————
Lineaadmin PoolConfigurator V30x812e…bfa2discovery————
Lineafactory PoolAddressesProvider V30x8950…73f4discovery———factory
Lineaguardian GovernanceGuardian0x056e…1f4ediscovery———guardian
Lineaguardian GranularGuardian0xc1cd…ca16discovery———guardian
Lineaoracle AaveOracle V30xcfda…95e9discovery———oracle
Lineaother CrossChainController0x0d3f…df52discovery————
Lineapool Pool V30xc47b…a8acdiscovery————
Lineatimelock PayloadsController0x3bce…e074discovery———timelock
mantleAaveProtocolDataProvider0x487c…3b68TVL + disc✓———
mantleuser0xb873…313cTVL✗———
Mantleadmin ACLAdmin V30x7088…cb7bdiscovery———governance
Mantleadmin ACLManager V30x810d…1115discovery————
Mantleadmin PoolConfigurator V30x7197…8626discovery————
Mantlefactory PoolAddressesProvider V30xba50…4d5fdiscovery———factory
Mantleoracle AaveOracle V30x47a0…e8dfdiscovery———oracle
Mantleoracle PriceOracleSentinel V30x64df…252ediscovery———oracle
Mantlepool Pool V30x458f…1422discovery————
MegaETHadmin ACLAdmin V30xe2e8…4e19discovery———governance
MegaETHadmin ACLManager V30x390d…1c3ddiscovery————
MegaETHadmin PoolConfigurator V30xf15d…dabbdiscovery————
MegaETHfactory PoolAddressesProvider V30x46dc…a478discovery———factory
MegaETHoracle AaveOracle V30x4211…4f21discovery———oracle
MegaETHother AaveProtocolDataProvider V30x9588…b403discovery————
MegaETHpool Pool V30x7e32…1c28discovery————
Metisadmin ACLAdmin V30x6fd4…8718discovery———governance
Metisadmin PoolConfigurator V30x69fe…45a6discovery————
Metisfactory PoolAddressesProvider V30xb9fa…d7afdiscovery———factory
Metisguardian GranularGuardian0x61be…36b5discovery———guardian
Metisoracle AaveOracle V30x38d3…6f8ediscovery———oracle
Metisoracle PriceOracleSentinel V30x2b5e…828adiscovery———oracle
Metisother CrossChainController0x6fda…7f70discovery————
Metispool Pool V30x90df…6a57discovery————
Metistimelock PayloadsController0x2233…5524discovery———timelock
Optimismadmin ACLAdmin V30x746c…09bfdiscovery———governance
Optimismadmin PoolConfigurator V30x8145…021ediscovery————
Optimismguardian GranularGuardian0x6c52…a03bdiscovery———guardian
Optimismoracle AaveOracle V30xd81e…0c77discovery———oracle
Optimismother (PoolAddressesProvider — Optimism)0xa976…3cdbdiscovery————
Optimismother CrossChainController0x48a9…d4cadiscovery————
Optimismpool Pool V30x794a…14addiscovery————
Optimismtimelock PayloadsController0x0e1a…e7c4discovery———timelock
plasma—0x02fc…5dd8TVL————
plasma—0x54dc…aa44TVL————
plasma—0x93b5…8c9aTVL————
plasma—0xab50…cc82TVL————
plasma—0xf2d6…419fTVL————
Plasmaadmin ACLAdmin V30x47aa…4d6adiscovery———governance
Plasmaadmin ACLManager V30xa860…9c06discovery————
Plasmaadmin PoolConfigurator V30xc022…d2d9discovery————
Plasmafactory PoolAddressesProvider V30x061d…05e9discovery———factory
Plasmaguardian GovernanceGuardian0x19ce…4be6discovery———guardian
Plasmaguardian GranularGuardian0x6066…2684discovery———guardian
Plasmaoracle AaveOracle V30x33e0…aaa5discovery———oracle
Plasmaoracle EmergencyOracle0xf61f…85cfdiscovery———oracle
Plasmaother CrossChainController0x6434…8cd6discovery————
Plasmapool Pool V30x925a…5e12discovery————
Plasmatimelock PayloadsController0xe76e…2a1ddiscovery———timelock
Polygonadmin ACLAdmin V30xdf7d…b233discovery———governance
Polygonadmin PoolConfigurator V30x8145…021ediscovery————
Polygonguardian GranularGuardian0x0d2c…0a02discovery———guardian
Polygonoracle AaveOracle V30xb023…8bd1discovery———oracle
Polygonoracle EmergencyOracle0xdafa…a23fdiscovery———oracle
Polygonother (PoolAddressesProvider — Polygon)0xa976…3cdbdiscovery————
Polygonother CrossChainController0xf6b9…ef0ddiscovery————
Polygonother VotingMachine0xc8a2…420ddiscovery————
Polygonpool Pool V30x794a…14addiscovery————
Polygontimelock PayloadsController0x401b…637cdiscovery———timelock
Scrolladmin ACLAdmin V30xc1ab…4a24discovery———governance
Scrolladmin ACLManager V30x7633…8081discovery————
Scrolladmin PoolConfigurator V30x32bc…9b7fdiscovery————
Scrollfactory PoolAddressesProvider V30x6985…dd04discovery———factory
Scrollguardian GranularGuardian0xa835…ced4discovery———guardian
Scrolloracle AaveOracle V30x0442…54f3discovery———oracle
Scrollother CrossChainController0x0307…ad0adiscovery————
Scrollpool Pool V30x11fc…cffediscovery————
Scrolltimelock PayloadsController0x6b6b…c3fediscovery———timelock
Soneiumadmin PoolConfigurator V30x1607…5a02discovery————
Soneiumfactory PoolAddressesProvider V30x8240…4c5bdiscovery———factory
Soneiumgovernor ExecutorLvl10x47aa…4d6adiscovery———governance
Soneiumguardian GovernanceGuardian0x19ce…4be6discovery———guardian
Soneiumguardian GranularGuardian0xd8e6…6656discovery———guardian
Soneiumoracle AaveOracle V30x2004…7fa1discovery———oracle
Soneiumoracle PriceOracleSentinel V30xc0ba…dcbediscovery———oracle
Soneiumother CrossChainController0xd92b…4d6ediscovery————
Soneiumpool Pool V30xdd3d…a38bdiscovery————
Soneiumtimelock PayloadsController0x44d7…f0cfdiscovery———timelock
Sonicadmin ACLAdmin V30x7b62…1ee7discovery———governance
Sonicadmin ACLManager V30x3a79…3b5adiscovery————
Sonicadmin PoolConfigurator V30x50c7…e2f0discovery————
Sonicfactory PoolAddressesProvider V30x5c2e…6900discovery———factory
Sonicoracle AaveOracle V30xd63f…4b30discovery———oracle
Sonicother AaveProtocolDataProvider V30xc0a3…f2cddiscovery————
Sonicpool Pool V30x5362…eaa3discovery————
X Layeradmin ACLAdmin V30xe2e8…4e19discovery———governance
X Layeradmin ACLManager V30xc8f2…190ediscovery————
X Layeradmin PoolConfigurator V30x1408…d2f2discovery————
X Layerfactory PoolAddressesProvider V30xdff4…e092discovery———factory
X Layeroracle AaveOracle V30x91fc…e2c6discovery———oracle
X Layerother AaveProtocolDataProvider V30x6c50…138fdiscovery————
X Layerpool Pool V30xe3f3…f116discovery————
xDaiadmin ACLAdmin V30x1df4…053ddiscovery———governance
xDaiadmin ACLManager V30xec71…2614discovery————
xDaiadmin PoolConfigurator V30x7304…5d16discovery————
xDaifactory PoolAddressesProvider V30x3661…2132discovery———factory
xDaiguardian GranularGuardian0x4a9f…2602discovery———guardian
xDaioracle AaveOracle V30xeb0a…f7c4discovery———oracle
xDaioracle EmergencyOracle0xf937…f84ddiscovery———oracle
xDaiother AaveProtocolDataProvider V30xf1f5…fa70discovery————
xDaiother CrossChainController0x8dc5…6c9fdiscovery————
xDaipool Pool V30xb502…26d8discovery————
xDaitimelock PayloadsController0x9a1f…756bdiscovery———timelock
zkSync Eraadmin ACLAdmin V30x04ce…d020discovery———governance
zkSync Eraadmin PoolConfigurator V30x0207…f40ediscovery————
zkSync Erafactory PoolAddressesProvider V30x2a39…6cb7discovery———factory
zkSync Eraguardian GovernanceGuardian0x4257…547ediscovery———guardian
zkSync Eraguardian GranularGuardian0xe0e2…a228discovery———guardian
zkSync Eraoracle AaveOracle V30xc7f5…0088discovery———oracle
zkSync Eraother CrossChainController0x8008…a92cdiscovery————
zkSync Erapool Pool V30x78e3…c43cdiscovery————
zkSync Eratimelock PayloadsController0x2e79…96f1discovery———timelock

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Website
https://aave.com
Twitter
@aave
GitHub
9 repositories
Docs
https://aave.com/docs
Governance forum
https://governance.aave.com
DefiScan
DefiScan · Stage 0

Security

[:] Source: DEFI@home quorum
Audits
64 audits
Bug bounty
https://immunefi.com/bug-bounty/aave/
Security contact
https://github.com/aave-dao/aave-v3-origin/blob/main/SECURITY.md

Technical

[:] Source: DEFI@home quorum
Voting token
AAVE Ethereum: 0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9
Deployed contracts
https://aave.com/docs/resources/addresses
Upgradeability
Upgradeable

Provenance

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Review status
listed
Updated
2026-06-02 13:51 UTC

Hallmarks

  1. Apr '21Start Ethereum V2 Rewards
  2. Oct '21Start AVAX V2 Rewards
  3. Oct '21Potential xSUSHI attack found
  4. Apr '22Start AVAX Rewards
  5. May '22UST depeg
  6. Jun '22stETH depeg
  7. Aug '22Start OP Rewards
  8. Apr '26KelpDAO hack