Aave V3

Aave V3 is the third major version of Aave, a non‑custodial lending/borrowing (money market) protocol deployed across multiple EVM chains and some non‑EVM networks like Aptos. It uses the AAVE governance token. Basic identification

• Name: Aave Protocol V3 (often “Aave v3”)
• Website: aave.com (implied by docs and repos titles, but protocol site claims are “unverified marketing claim” unless cross‑checked)
• Docs: Aave V3 section of Aave Docs, e.g. “Aave V3 Overview” and “Smart Contracts” pages.
• Category: DeFi lending/borrowing / collateralized money market protocol.
• Launch date: Multiple independent sources state Aave V3 launched in March 2022.
• Native / governance token: AAVE token for governance and staking. Chains / deployments Independent docs summarise that Aave V3 runs on 20+ deployments including Ethereum, Arbitrum, Optimism (OP Mainnet), Polygon, Avalanche, Base, BNB Chain (BSC), Gnosis, Linea, Celo, Mantle, Sonic, Plasma, Monad, and others; some older deployments like Fantom and Harmony are deprecated. Support for Aptos, MegaETH, Xlayer, Soneium and similar very new chains is Not verifiable as of 2026‑08‑27 under the given data. Core contract pattern (v3 markets) Per Aave Docs and independent address books, each deployment has at least:
• PoolAddressesProvider (central registry).
• Pool (main user‑facing lending pool).
• PoolConfigurator (risk & parameter config). Examples with ≥2‑source cross‑check:
• Ethereum mainnet (Aave V3 “Core”):
• PoolAddressesProvider: 0x2f39d218133AFaB8F2B819B1066c7E434Ad94E9e.
• Pool: 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2.
• PoolConfigurator: 0x64b761D848206f447Fe2dd461b0c635Ec39EbB27.
• Arbitrum / many L2s (canonical v3 market):
• PoolAddressesProvider: 0xa97684ead0e402dC232d5A977953DF7ECBaB3CDb.
• Pool: 0x794a61358D6845594F94dc1DB02A252b5b4814aD.
• PoolConfigurator: 0x8145eddDf43f50276641b55bd3AD95944510021E. Independent address‑books note that these three addresses are reused across “most” L2 networks (Arbitrum, Optimism, Avalanche, etc.). Explorer verification status Contract lists from GitHub/docs indicate that these addresses correspond to Aave V3 core contracts with published ABIs and verified source links. Direct on‑chain verification is Not verifiable as of 2026‑08‑27 under current tool constraints. Fork lineage & code changes
• Aave V3 is a major evolution of Aave V2, developed in‑house by Aave’s core team rather than an external fork; it introduces features such as e‑mode, isolation mode, siloed reserves, and improved L2‑specific Pool (L2Pool.sol) logic.
• The aave‑v3‑core GitHub repository is a continuation of the v2 codebase with refactored modules, not a fork of another protocol.
• Multiple audits exist for Aave V3 (from firms like Certora, Sigma Prime, et al.), but specific reports and coverage for all recent chains are Not verifiable as of 2026‑08‑27 from the retrieved snippets.
• No evidence surfaced of malicious modifications in third‑party forks of Aave V3 in the data retrieved; however, absence of evidence is not proof of absence and should not be treated as comprehensive coverage.

Aave V3 appears to be a real, mature product rather than a pure landing page: the official app at app.aave.com presents live market views, supply/borrow flows, and market-specific entry points, while the documentation includes product guides plus a GraphQL API for market data, user positions, and transaction preparation. The docs also describe developer tooling (AaveKit React/TypeScript/API) and the GitHub repo is active, which is consistent with a maintained production stack rather than a template site. Live deposit/withdraw functionality is supported in the app’s UI, including supply and withdraw flows, and the site copy explicitly references instant withdraws for some markets. On the product side, this looks like an operational dapp with multi-market support across Aave V3 deployments, not a static marketing site. Open API: yes. Aave’s documentation explicitly states that AaveKit exposes a GraphQL API and provides the endpoint for querying chains, market data, user positions, and transaction-building flows. No obvious broken-link or fake-metrics evidence was surfaced in the retrieved sources, but that is not fully verifiable from web snippets alone. Not verifiable as of 2026-08-26.

Additional Aave V3 core and periphery audits providing independent review and formal reasoning around math libraries, interest rate calculations, and protocol invariants.

• Report date / scope: ABDK 27‑01‑2022 (Aave V3 core); SigmaPrime 27‑01‑2022 (second‑round core + periphery).
• Link: DeepWiki lists 27-01-2022_ABDK_AaveV3.pdf and 27-01-2022_SigmaPrime_AaveV3.pdf in the audits directory.
• Findings: Mixture of medium and low‑severity findings on numerical precision, parameterization, and invariant documentation; no public critical issues recorded.
• Fix status: Marked as addressed prior to or shortly after launch; follow‑up documentation treats these reports as closed.
• Bytecode‑match: Not verifiable as of 2026‑08‑26 for any of the specified chains.

Multiple formal verification and audit reports for Aave V3 upgrades (virtual accounting, v3.1, v3.4, risk‑steward, and later v3.7). These focus on proving safety properties, checking invariants, and validating upgrade diffs.

• Key report dates / scopes:
• Jan 2022: formal verification of Aave V3 initial release.
• 30‑04‑2024: Aave V3.1 virtual accounting feature.
• 11‑06‑2025: Aave V3.4 core changes and related AIP governance proposal.
• 29‑03‑2026: Aave V3.7 formal verification (risk‑steward and broader protocol).
• Links: Paths in Aave V3 origin audits directory (e.g., certora/Aave_V3_Formal_Verification_Report_Jan2022.pdf, 2026-03-29_Certora_Aave-v3.7.pdf) and Certora’s own Aave V3 risk‑steward report page.
• Findings: Mainly specification gaps, corner‑case invariant violations, and recommended constraint tightening; these are tracked as medium/low items, with no public critical exploitable bugs reported.
• Fix status: Reports describe fixes and re‑verification cycles; DeepWiki’s audit history for v3.4–v3.7 notes issues as resolved or explicitly documented.
• Bytecode‑match: For all chains (Aptos through Xlayer), Not verifiable as of 2026‑08‑26.

Initial Aave V3 core and periphery audit for v3.0, covering lending pool, tokens, configuration, and peripheral adapters across main deployment set (multi-chain by same codebase). The report identifies several medium and low‑severity issues (e.g., edge‑case interest math, configuration and access‑control nuances), all reported as fixed or acknowledged prior to public launch.

• Report date / scope: 01‑11‑2021, "Aave V3" core/periphery smart contracts.
• Link: Hosted in the audits/ directory of the Aave V3 origin/core GitHub (DeepWiki paths like 01-11-2021_OpenZeppelin_AaveV3.pdf).
• Findings: No critical; a handful of high/medium and several low/info findings across upgradeability patterns, parameterization, and liquidation/interest edge cases (per secondary summaries).
• Fix status: All high/medium issues marked remediated or design‑accepted before v3 deployment; follow‑up reviews confirm resolutions.
• Bytecode‑match / deployed code: Whether this specific report byte‑matches all live deployments on Aptos, Arbitrum, Avalanche, BSC, Base, Celo, Ethereum, Gnosis, Linea, Mantle, MegaETH, Monad, OP Mainnet, Plasma, Polygon, Sonic, Xlayer is Not verifiable as of 2026‑08‑26 (no on‑chain tooling available this turn).

Security audits for Aave V3 point releases maintained by BGD Labs, including v3.3.0 and Liquid eModes, focusing on diff review and new feature safety.

• Report date / scope:
• v3.3.0 smart contracts security audit (update package) – date in 2025 (exact day in PDF).
• Liquid eModes smart contracts audit – update of collateral/borrowing modes for specific assets.
• Link: Public PDFs Aave-v3.3.0-Audit-Report.pdf and Aave-Liquid-eModes-Audit-Report.pdf on Oxorio’s site.
• Findings: A small number of medium and low‑severity issues around configuration risks and edge‑case interactions of new modes; no critical/high exploitable bugs disclosed in summaries.
• Fix status: Reports state that all significant findings were fixed or properly mitigated before or shortly after deployment of the updates.
• Bytecode‑match: Across the listed chains, exact coverage is Not verifiable as of 2026‑08‑26.

Early Aave V3 core audit focused on security of lending logic, reserve configuration, and cross‑asset interactions.

• Report date / scope: 14‑01‑2022; Aave V3 core smart contracts.
• Link: Referenced as 14-01-2022_PeckShield_AaveV3.pdf in the Aave V3 origin audit directory via DeepWiki.
• Findings: Mix of high/medium and lower‑severity issues, primarily around risk of misconfiguration and certain edge‑case behaviors; no disclosed critical vulnerabilities in the public summaries.
• Fix status: Reported as remediated/accepted prior to production deployment; later audits treat these as historical findings.
• Bytecode‑match: Not verifiable as of 2026‑08‑26 for any listed chain.

Comprehensive Aave V3 core protocol security assessment for the initial release, focusing on protocol invariants, liquidation mechanisms, interest rate models, and upgradeability.

• Report date / scope: Dated around 07‑01‑2022; assessment window November 29, 2021; smart contracts for Aave V3 core.
• Link: Public PDF 07-01-2022_TrailOfBits_AaveV3.pdf hosted in Aave V3 origin/core GitHub; mirrored by external audit archives.
• Findings: No uncensored criticals reported in public summaries; several high and medium findings related to invariant assumptions, edge‑case liquidation behavior, and configuration safety.
• Fix status: Issues documented as remediated or acknowledged with design changes before v3 launch; DeepWiki and security summaries treat the audit as fully addressed.
• Bytecode‑match / deployed code: Per‑chain bytecode matching for Aptos, Arbitrum, Avalanche, BSC, Base, Celo, Ethereum, Gnosis, Linea, Mantle, MegaETH, Monad, OP Mainnet, Plasma, Polygon, Sonic, Xlayer is Not verifiable as of 2026‑08‑26.

Yes. Aave V3 has an active bug bounty program, with the current Immunefi program listed as live since 18 October 2023. Separately, Aave’s earlier GitHub-hosted Aave Protocol V3 bug bounty states it started on 16 March 2022 and covered the Aave Protocol V3 core repository. Parameters: the Immunefi program advertises a maximum bounty of $1,000,000, with critical rewards capped at 10% of funds directly affected; public materials also list payout tiers of $50,000–$1,000,000 for critical, $10,000–$75,000 for high, $10,000 for medium, and $1,000 for low severity. The Aave governance proposal says scope includes Aave v3 and related protocol components, with payouts handled through governance in stablecoins or AAVE, and monthly batching to avoid governance overload. Results: the web sources confirm the program exists and define its reward structure, but they do not provide a verifiable public total of submissions, payouts, or disclosed exploit outcomes specific to the active program. Not verifiable as of 2026-08-26.

Aave V3’s main counterparty dependencies are oracle providers, wrapped-asset bridges, and the issuers/managers of the assets it lists; for most markets, price discovery relies on Chainlink feeds, and Aave’s risk framework explicitly requires Chainlink price feeds where market-rate pricing is used. Aave also maintains a formal oracle-deprecation process for long-tail assets, which is a direct signal that stale or vulnerable feeds are treated as a live risk rather than a hypothetical one. The largest structural risk is oracle/manipulation risk on thinner collateral markets. Aave’s own risk repository notes that *siloed assets* are used for assets with potentially manipulable oracles so they can be supply-only and not used as collateral. That means if an asset’s spot market is thin or easily moved, Aave mitigates by limiting how the asset can be used, but residual liquidation and bad-debt risk remains if pricing fails or moves abruptly. A second major dependency is bridge and wrapped-asset exposure on non-native collateral and liquidity. On chains such as Arbitrum, Avalanche, Base, Linea, Mantle, OP Mainnet, Polygon, and others, Aave markets commonly include bridged or wrapped versions of major assets; if the bridge, wrapper, or canonical asset contract is impaired, the protocol can inherit depeg or redeemability risk through the collateral base. This is especially relevant for stablecoins and liquid staking tokens, where a peg break or validator/redeemer stress can transmit directly into Aave’s collateral valuation and liquidation engine. Aave also has concentrated stablecoin exposure across chains, including USDC, USDT, DAI, FRAX, LUSD, and chain-specific stable assets referenced in its risk files and governance discussions. These assets introduce issuer and market-maker/custodian dependence: USDC-like assets depend on the solvency and redemption capacity of their issuers and banking partners, while LSD/LST and restaking-linked assets depend on validator economics and underlying protocol health. Not verifiable as of 2026-08-26: any chain-by-chain TVL exposure percentages, exact bridge names for every deployed market, CEX/MM inventory dependence, or RWA issuer/SPV exposure specific to Aave V3 on Aptos, Celo, Gnosis, MegaETH, Monad, Plasma, Sonic, or Xlayer, because those were not independently verifiable from the available sources in this run.

Aave V3 is organized as a non-custodial lending protocol: users supply assets to protocol smart contracts, receive aTokens in return, and keep self-custody of their positions rather than handing assets to a central operator. Custody is therefore onchain and user-controlled, not held in a centralized wallet; supplied tokens remain in publicly accessible smart contracts, while borrowing is represented by variable debt tokens that track each user’s obligation. Risk and collateral are managed per-market and per-chain: Aave V3 uses separate markets on different networks, and assets supplied in one market can only be borrowed within that market. Protocol operations are governed by AAVE token holders and limited emergency roles can pause reserves for risk management, but they cannot freeze or alter individual user positions. If you want the shortest version: users keep custody, smart contracts hold the pooled liquidity, and governance/risk controls only manage protocol rules—not individual funds.

Aave V3 has no clearly documented protocol-level exploit incident in the gathered sources. The main incident-related item found is a 2022 white-hat disclosure / critical vulnerability report that led to temporary pauses on several markets, but the exact affected chains, loss amount, reimbursement, and remediation details are not fully verifiable from the available sources.

Aave’s bug bounty program is live through Immunefi, with critical smart-contract bug rewards up to $1,000,000 in the gathered source snapshot; Aave governance has also discussed ad hoc and expanded bounty programs, including a later proposal to raise core V3 critical rewards to $5 million, but that update is from 2026 and outside the core incident record.

Aave V3’s key management is organized as non-custodial smart-contract control, not by a centralized operator holding user funds. Users keep control of their assets in onchain contracts, while protocol-wide permissions are separated into roles governed through Aave’s access-control system. The core technical paper says these roles are managed in the ACLManager, which tracks role holders and lets a role admin manage them; the PoolAddressesProvider manages protocol components and can update pointers to modules such as the ACLManager or Pool implementation. Aave’s documentation also says the protocol is governed by AAVE token holders, with onchain governance deciding key parameters and asset listings.

Aave V3 uses a per-market, upgradeable proxy architecture: the Pool is proxied and owned by the market’s PoolAddressesProvider, which is itself owned by Aave Governance; the provider acts as the factory/admin for proxies and can change implementations. The ACLManager governs permissioned roles, and the docs state that role admins are managed through DEFAULT_ADMIN_ROLE, with EMERGENCY_ADMIN able to pause/unpause the pool or individual reserves. The Pool’s admin functions are callable by PoolConfigurator, while governance controls implementation changes and sensitive permissions. For the listed deployments, the architecture and control surface are not uniform across all chains, and some chain-specific details are not verifiable from the gathered material. The sources explicitly confirm Aave V3 docs for Ethereum-style markets, Aptos ACL permissions, and several governance discussions that describe transparent proxy / ProxyAdmin patterns on specific deployments such as X Layer and MegaETH, but those are market-specific governance posts rather than a complete canonical inventory. Not verifiable as of 2026-08-26 for the full address-by-address matrix across Aptos, Arbitrum, Avalanche, BSC, Base, Celo, Ethereum, Gnosis, Linea, Mantle, MegaETH, Monad, OP Mainnet, Plasma, Polygon, Sonic, and Xlayer. The clearest risk statement is that Aave V3 is *upgradeable*, so a compromised governance/admin path can change implementations, risk parameters, or pause reserves; however, users should generally still be able to withdraw through the Pool unless the market is paused or a more severe exploit affects solvency/liquidity. The materials gathered here do not provide an on-chain-measured timelock delay, nor do they verify renounced roles; those are Not verifiable as of 2026-08-26. Architecture map: Governance → PoolAddressesProvider (market admin) → Proxy/PoolConfigurator → Pool/Reserve logic; ACLManager sits alongside this to enforce roles, with EMERGENCY_ADMIN as the main pause authority. Worst case if keys are compromised: an attacker with upgrade/admin authority could upgrade logic, alter configuration, or pause markets; if liquidity remains and pauses are limited, exits may still be possible, but if the attacker deploys malicious logic or the market becomes insolvent, user exit/freeze risk becomes material. This is an architecture-level risk inference from the documented permissions, not an on-chain verified incident.

Aave V3 is built by the broader Aave ecosystem, whose core corporate and leadership structure is public, founder‑led, and based in Europe/UK rather than being an anonymous or purely “web‑front” project. Founders & key people

• The protocol was originally created by Stani Kulechov, a Finnish/Estonian founder and long‑time public figure in DeFi.
• Kulechov first launched ETHLend in 2017, later rebranded to Aave ("ghost" in Finnish) and evolved into a major DeFi lending protocol.
• He holds a Master’s degree in Law from the University of Helsinki and is consistently described as Founder & CEO of Aave / Avara in major fintech, exchange, and media profiles.
• Avara (formerly Aave Companies) is the software company behind Aave, the GHO stablecoin, Lens Protocol, and other Web3 products, with Kulechov as founder/CEO. Team, publicity, and credibility
• Leadership is fully public, with Kulechov present on LinkedIn, conference bios, bank interviews (e.g., Citi), major exchange educational content, and crypto media.
• Background coverage shows a multi‑year track record in DeFi, from ETHLend to Aave V2/V3, and now GHO and Lens, with repeated participation in mainstream and institutional events.
• No evidence in these sources of Kulechov or the core team being pseudonymous; the project is consistently framed as a professionally managed company in the Web3/DeFi sector. Corporate reality: office, onshore/offshore
• Multiple independent profiles state that Kulechov and the Aave/Avara organization are based in London, England, indicating a real physical presence and staff hub rather than only a web‑front.
• Avara/Aave is described as a software / technology company building DeFi and Web3 social infrastructure, implying standard corporate operations (employees, product lines, institutional partnerships).
• Details like precise legal entities, registration jurisdictions, and any subsidiaries are not verifiable as of 2026‑08‑26 from the data reviewed and would require corporate registry checks. Prior projects & risk‑relevant history
• ETHLend (pre‑Aave) is widely cited as one of the first DeFi dApps, later rebranded into Aave without a recorded catastrophic failure in the profiles consulted.
• Public sources highlight Aave as a large, long‑standing DeFi protocol; specific exploit/hack history for Aave V3 or its precursors is not verifiable as of 2026‑08‑26 within the retrieved biographical/PR‑style material, so this remains a separate risk check.

Aave V3 is generally regarded as a blue‑chip DeFi lending protocol with strong security and regulatory standing, but like all large DeFi systems it carries non‑zero smart‑contract, governance, and regulatory risk. Founders / team / investors

• Aave was founded by Stani Kulechov and is one of the earliest large DeFi lending markets; V3 is the latest major version. This long operating history and open‑source development contribute to a relatively strong reputation in institutional circles (synthesis of general industry coverage; not tied to a single retrieved article). Security audits and formal verification
• Aave V3 has undergone multiple independent audits by firms including Trail of Bits, OpenZeppelin, PeckShield, Sigma Prime, ABDK, OtterSec, Spearbit and formal verification by Certora, as summarized both in Aave’s public security materials and in independent summaries.
• Recent audits of V3.1–V3.3 (e.g., by OtterSec and others) reported no critical or high‑severity issues in scope at the time of review.
• An AI‑assisted security review across Aave V3 and V4 reported that none of the validated findings were Critical/High; remaining issues were Low/Informational, and reviewers stated user funds were not at risk from those items.
• Audit case studies document high‑severity issues (e.g., flash loan utilization‑ratio manipulation) that were discovered and remediated before or during v3.4 development. Incidents and criticisms
• Publicly discussed vulnerabilities in V3 (e.g., flash loan usage ratio inflation) have been described in post‑mortem style case studies, with status noted as fixed.
• Criticisms in independent analysis include: reliance on oracles and potential manipulation risk, limits of audits/formal verification, and governance transparency concerns. Rug pull / fraud / insolvency allegations
• There is no evidence in current independent reporting of Aave V3 being associated with a rug pull, protocol‑level fraud, or borrower insolvency crisis that rendered the core protocol insolvent. (Synthesis across retrieved security and regulatory coverage; none allege fraud.) Regulatory / legal status
• The U.S. SEC conducted a multi‑year investigation into Aave/Labs and the AAVE token and closed it without recommending enforcement action, according to multiple independent reports and a letter cited therein.
• Coverage characterizes this closure as reducing immediate U.S. regulatory risk, while noting it is *not* a formal exoneration and the agency could revisit Aave in future.
• Some commentary notes ongoing regulatory uncertainty around DeFi lending and AAVE’s longer‑term classification, but there is currently no active enforcement case reported against Aave. Unresolved concerns (high‑level)
• Smart‑contract and oracle risks remain structural (acknowledged explicitly in Aave’s own security materials).
• Governance and transparency (e.g., complexity of risk parameter changes, reliance on expert teams) are cited as areas needing continuous oversight.
• On‑chain verification of TVL, per‑chain exposure, and incident impact is Not verifiable as of 2026‑08‑26 within this answer, because direct on‑chain querying was not available.

Aave V3 is a multi-chain, non-custodial lending/borrowing market: users deposit supported assets to earn variable supply yield, and borrowers post overcollateralized assets to borrow from the pool. The economic model is primarily organic, because yield comes from borrower interest and liquidation fees; any rewards/incentives are secondary and network-specific, not the core source of return. Strategy / asset flow: assets flow *in* as deposits and *out* as withdrawals, while borrow demand and liquidations create the yield stream for suppliers. The protocol is best characterized as market-neutral for lenders and directional for borrowers; the platform itself is not a directional fund. It does support collateralized leverage behavior via borrowing against deposited collateral, but it is not a restaking protocol. Collateral / mechanics: Aave’s model relies on overcollateralization, with asset-specific risk parameters determined by governance. Withdrawals are generally permissionless, but actual availability depends on pool liquidity and utilization; there are no protocol-wide lock-ups disclosed in the sources reviewed. Fees / protocol revenue: DefiLlama shows Aave V3 with about $122.21m annualized revenue and $5.01m 30d revenue as of the latest snapshot surfaced in the search results, while an independent 2026 analysis reports roughly $227.1m all-time protocol revenue for Aave V3 and $1.70b all-time fees. Because these are aggregator / secondary-source figures, they should be treated as estimates rather than on-chain verified facts. Chains / TVL: Official documentation says Aave V3 is deployed on Ethereum, Polygon, Avalanche, Arbitrum, Optimism, Base, BNB Chain, Scroll, Metis, Gnosis, ZKsync Era, Linea, Sonic, Celo, Soneium, Plasma, Fantom, and Harmony, with several newer deployments noted in the access page. External dashboards disagree on the exact count: one source says 17 chains and $25.4b TVL across 154 pools, while another shows ~20 chains and ~$26.2b TVL; without on-chain verification in this run, the precise chain-by-chain split is Not verifiable as of 2026-08-26. APY / sustainability: Aave V3 APY is variable and utilization-driven rather than fixed; the dominant source of yield is borrower demand, so APY is usually sustainable when lending demand, collateral quality, and liquidations remain healthy, and falls when utilization declines. I could not verify a reliable APY history series or volatility breakdown in this run, so that is Not verifiable as of 2026-08-26. Key risk read: the main economic risks are utilization collapse, bad collateral quality, and liquidity fragmentation across many chains; the main strength is that the model is mostly self-funded by market activity rather than subsidies.

Aave V3 treasury/reserve economics are governance-controlled and chain-specific, but only partial reserve-location facts are verifiable here. The protocol docs state that reserve income is minted to treasury via mintToTreasury(address[] assets) and that RESERVE_TREASURY_ADDRESS() returns the Aave treasury address controlled by governance. Governance also describes the treasury as DAO-controlled, with no single entity able to access funds without an on-chain governance vote. Verified reserve/treasury addresses found in governance records include Avalanche Aave v3 treasury 0x467b92aF281d14cB6809913AD016a607b5ba8A36 and Polygon Aave v3 treasury 0x7734280A4337F37Fbf4651073Db7c28C80B339e9. A governance forum post also cites Arbitrum Aave Treasury V3 at 0x053D55f9B5AF8694c503EB288a1B7E552f590710. Composition and policy: treasury inflows are the reserve-factor share of borrowing interest, minted as aTokens on each reserve; risk-parameter docs say reserve factors are calibrated by asset risk, roughly 10% for less risky assets up to 35% for riskiest assets, and governance proposals can push reserve factors much higher for deprecating assets. The treasury is also used by DAO governance for incentives and ecosystem spending. On-chain balances, custody balances by chain, and cross-chain TVL/exposure are not verifiable as of 2026-08-26 without on-chain query access. Attestations/audits referenced in retrieved material exist for the V3 codebase, but a protocol-wide treasury balance attestation is not verifiable as of 2026-08-26.

Aave V3 uses the existing AAVE token (no separate v3 token). All tokenomics below refer to AAVE. 1. Native token & basic metrics

• Name/ticker: Aave (AAVE).
• Main contract (Ethereum): 0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9.
• Total supply: 16,000,000 AAVE (fixed).
• Circulating supply, market cap, FDV: Not verifiable as of 2026-08-28 (requires live market data). 2. Utility & governance role
• Governance: AAVE is the governance token of the Aave Protocol; holders vote in Aave Governance V3 on risk parameters, asset listings, deployments (including each V3 market on different chains) and treasury use.
• Safety Module / staking: AAVE can be staked in the Safety Module to backstop protocol shortfalls; stakers receive incentives (AAVE emissions plus protocol fees, depending on governance decisions).
• Aave V3 itself does not introduce a new token; all governance remains centered on AAVE across chains. 3. Revenue share, buybacks, burns
• Risk-parameter changes (interest rate curves, reserve factors) allow part of protocol revenue to accrue to the Safety Module / treasury as decided by governance.
• Historically, Aave has executed token buybacks and treasury management via governance proposals, funded from protocol treasury and fees.
• Exact current rates, shares, and any ongoing burns are Not verifiable as of 2026-08-28 without on-chain or up-to-date analytics. 4. Emissions & unlocks
• The AAVE supply is fixed at 16M with no ongoing mint schedule.
• Incentive emissions (e.g., Safety Module rewards, liquidity mining) come from the Aave DAO treasury and are defined in individual governance proposals, not by an automatic emission curve.
• Historical vesting/unlock schedules for team/investors are described in early AAVE migration and token distribution posts, but whether all announced unlocks executed on-chain is Not verifiable as of 2026-08-28. 5. Allocations & holder concentration
• High-level allocations (ecosystem reserve/treasury, team, investors, community) were set at AAVE genesis, but precise current balances, insider wallets, and top-holder concentration are Not verifiable as of 2026-08-28 without direct on-chain queries. 6. Token controls & listings
• AAVE is an ERC‑20 without arbitrary minting; governance can upgrade protocol contracts but not inflate AAVE beyond 16M.
• No credible evidence of blacklist or fee-switch logic in the AAVE token contract itself.
• AAVE has deep DEX and CEX liquidity (Uniswap, major centralized exchanges), but exact depth and share per venue are Not verifiable as of 2026-08-28. 7. Multi-chain note
• Aave V3 runs on many chains (Arbitrum, Polygon, Optimism, Avalanche, etc.), but AAVE remains the single governance / utility token; local bridged wrappers do not have independent tokenomics.

Bitcoin (and tokenized BTC) collapsing below $10,000 creates a severe but largely *idiosyncratic* risk for Aave V3 BTC-backed borrowers, not a systemic insolvency risk for the protocol, assuming oracles remain functional and markets stay liquid. Key mechanics

• Aave V3 requires over-collateralization and tracks each position via Health Factor (HF); if HF falls near 1, positions become eligible for liquidation.
• BTC collateral on Aave is mostly via wrapped forms (e.g. WBTC, BTC.b, FBTC, cbBTC) across Ethereum and L2s/sidechains.
• BTC-like assets have high but not extreme LTV / LT versus ETH/blue-chip collateral; third-party reviews cite ~73% max LTV and ~78% liquidation threshold for WBTC/cbBTC, i.e. 22–27% price buffer before liquidation for maxed-out positions. Impact of BTC < $10,000 1. Collateral value shock
• If BTC drops from, say, $60k to below $10k (>80% drawdown), almost all high-LTV BTC-backed loans will breach their liquidation thresholds.
• Positions already running below conservative LTVs could survive if they had low leverage and diversified collateral (e.g., mix of stablecoins/ETH and BTC), but pure BTC-levered borrows become liquidation-prone. 2. Liquidation dynamics
• Aave’s design incentivizes third-party liquidators via a liquidation bonus (~5–7% per independent review), who buy underpriced collateral by repaying user debt.
• In an orderly but sharp crash, liquidators should clear undercollateralized BTC positions as long as:
• Oracles reflect market prices correctly and promptly.
• Off-chain markets still quote BTC/WTBC/FBTC liquidity. 3. Protocol solvency and bad debt risk
• Aave’s main systemic risk is bad debt: if BTC price gaps down faster than liquidators can act, or if markets freeze, some loans may fall below 100% collateralization before liquidation, leaving deficits.
• Given Aave governance’s conservative BTC parameters and supply caps (e.g. BTC.b supply-only on certain instances, borrowing disabled or constrained), exposure is intentionally bounded.
• However, the *absolute* on-chain size of BTC reserves per chain is Not verifiable as of 2026-08-26 under current data-access limits. 4. Cross-chain heterogeneity
• Different Aave V3 instances (Ethereum core, Base, Mantle, Monad, etc.) use chain-specific caps for BTC-like assets (e.g., BTC.b on Core, FBTC on Mantle) to limit local risk concentration.
• This implies stress losses would be fragmented by chain, reducing the chance of a single, protocol-wide solvency event. Residual institutional concerns
• Oracle and liquidity risk: a flash crash or oracle failure could temporarily undermine liquidation efficacy, creating bad debt.
• Tokenized BTC counterparty risk (WBTC custodians, bridge risk for BTC.b/FBTC) is orthogonal but amplified in stress.
• Governance risk: parameters (LTV/LT, caps) can change via governance; recent changes show active tuning of LTVs and modes across chains.

Assuming the largest collateral asset on a given Aave V3 deployment depegs -20% vs its reference (ETH or USD), the primary risk is bad debt from under‑collateralized accounts that cannot be fully liquidated within oracle and market constraints. Below is a generic stress interpretation across the listed chains; exact magnitudes are Not verifiable as of 2026-08-26. 1. Mechanics of a 20% collateral depeg

• Aave V3 uses LTV and liquidation thresholds (LT) per asset. A 20% drop in the largest collateral:
• Instantly lowers Health Factors (HF) for all users using that collateral.
• Pushes high‑LTV accounts below LT, triggering liquidations.
• If the asset is an LST/LRT (e.g., wstETH, weETH) or a stablecoin, this is exactly the class of peg risk Aave risk partners model as depeg scenarios. 2. Likely risk concentration pattern
• On major L1/L2 deployments (Ethereum, Arbitrum, Base, OP, Polygon), recent research shows collateral exposure is highly concentrated in ETH‑linked LSTs (wstETH, weETH, etc.) and WETH.
• A 10% weETH depeg already leaves Aave close to balanced collateral vs debt in simulations; a 20% shock would materially increase insolvency risk if parameters are not tightened.
• Smaller chains (Celo, Gnosis, Linea, Mantle, BSC, Aptos, etc.) tend to have more fragmented liquidity and thinner liquidator coverage, so the same percentage shock can translate to higher realized bad debt share of TVL. 3. Expected protocol‑level impacts
• Liquidation waves: A 20% shock generates large liquidation volumes in the affected markets; historical parameter changes (e.g., stETH LT/LTV adjustments) were specifically aimed at reducing liquidation cascades and insolvencies under depeg.
• Bad debt formation: If secondary‑market depth and oracle updates cannot keep up, liquidations may not fully cover debt, leaving net insolvent value. Gauntlet’s earlier assessments target <1% net insolvent value of protocol assets under stress, but a 20% targeted depeg of the largest collateral is beyond their typical baseline shocks.
• Cross‑chain asymmetry: Chains with:
• Deep spot/liquid staking liquidity and strong liquidator networks (Ethereum, Arbitrum, Base) are more likely to keep bad debt small as % of TVL.
• Thin liquidity or newer deployments (e.g., Plasma, Linea, emerging L2s) face elevated risk that a single large account creates chain‑level bad debt. 4. Governance and risk‑control expectations
• Under the current Aave Risk Framework, persistent peg deterioration or oracle instability can make an asset a deprecation candidate (freeze, LTV/LT cuts, or off‑boarding).
• For pegged assets in E‑Mode, any sustained >1% deviation already breaks eligibility; a 20% depeg would almost certainly force removal from E‑Mode, LTV=0, and aggressive winding down. Chain‑by‑chain TVL, top collateral, and exact bad‑debt exposure under this stress are Not verifiable as of 2026-08-26 without direct on‑chain analysis.

There is no public evidence that the Aave DAO, Aave companies, or core owners have committed fraud. However, several *stress‑scenario* vectors exist that institutional risk managers should consider. ### 1. Governance / DAO Misconduct Scenario

• Aave is governed by Aave DAO via on‑chain governance using AAVE and stkAAVE, with proposals executed by a Safety Module and the Aave Guardian (multisig).
• A malicious coalition of large token holders, a compromised governance actor, or collusion between the DAO and core team could:
• Push a proposal that changes risk parameters (LTV, caps, interest rate models) to benefit an affiliated trading entity.
• Authorize listing of a worthless or insider‑controlled asset, then drain liquidity via borrow/loop strategies.
• Redirect treasury or Safety Module funds to related parties under vague “service” agreements. No such events are documented in public sources; prior major issues (e.g., frozen assets after Curve exploits, listing parameter errors) are treated as risk events / misconfigurations, not fraud. Stress assumption: governance capture leading to abusive proposals. ### 2. Treasury / Service Provider Conflicts
• Aave Companies (e.g., Aave Labs) and service providers are funded by Aave DAO treasury through grants and service contracts.
• Stress scenario:
• Overpayment, self‑dealing, or opaque related‑party arrangements (e.g., DAO funds flow to entities economically controlled by key DAO voters without clear value).
• Misrepresentation of deliverables or KPIs for funded R&D or ecosystem programs. Public governance records show structured proposals, budgets, and reporting, but do not fully eliminate information asymmetry or soft corruption risk. Not verifiable as of [2026‑08‑26] whether any specific transfer constitutes fraud. ### 3. Cross‑Chain Deployment / Operator Abuse
• Aave V3 runs on multiple L1/L2s (Ethereum, Polygon, Avalanche, Arbitrum, Optimism, Base, etc.).
• Deployments and upgrades often rely on chain‑specific multisigs/guardians to bootstrap or hotfix.
• Stress scenario: a chain‑specific multisig (or its signers) is compromised or colludes to:
• Deploy altered contracts with hidden backdoors on a smaller chain.
• Change reserves or interest models to siphon value. Specific multisig behaviors and signer integrity are Not verifiable as of [2026‑08‑26] without on‑chain analysis. ### 4. Legal / Regulatory Fraud Angle
• No major enforcement actions or fraud allegations against Aave DAO or Aave Labs appear in recent regulatory or mainstream coverage.
• Regulatory risk centers on unregistered securities / lending, KYC/AML, consumer protection rather than fraud per se. Institutional stance: treat fraud by DAO/owners as a *low‑frequency, high‑severity* tail risk driven by governance capture, treasury misuse, or multisig compromise, and mitigate via per‑chain governance/ops review, signer due‑diligence, and strict exposure limits.

Primary yield source for Aave V3 is borrower interest plus ancillary fees (flash loans, liquidations, swaps, MEV recapture) paid into each reserve; supplier APY is this income minus the reserve factor cut to the treasury. A 30‑day period with *negative primary yield* at the protocol level is therefore very unlikely in current conditions, but specific assets or chains can effectively deliver negative or near‑zero net yield to suppliers over 30 days via rate dynamics and incentives. Current yield context (cross‑chain)

• Aggregators tracking Aave V3 report average APY ~1.3–1.7% across pools.
• Recent 30‑day fee/revenue metrics show positive fees and revenue, e.g. DeFiLlama and Octopus Tracker show Aave V3 generating tens of millions of USD in fees over 30d, with ~USD 13–36m of protocol revenue.
• Governance data summarizing multichain performance shows all major Aave V3 deployments (especially Ethereum, L2s) with positive rolling 30d revenue and non‑trivial TVL. What “primary yield source negative 30d” means here
• At protocol level: 30d net interest and fee income < 0. Given the design, this would require:
• Systematic large‑scale bad debt not fully covered by liquidations,
• Or sustained subsidization where the protocol pays out more (e.g., incentives) than it earns in interest/fees. None of the cited analytics show such a regime: they record positive 30d fees and revenue.
• At asset/chain level (more realistic stress):
• Supply APY ≈ 0 while users still incur costs (gas, bridging, oracle risk), producing *effective* negative yield to suppliers even if gross interest ≥ 0.
• Highly utilized markets can flip if governance slashes rates (e.g., risk‑off changes) while oracle or stablecoin depeg events impose losses on suppliers not compensated by interest.
• Chains with low utilization and shallow borrowing (smaller L2s, sidechains) may show near‑zero supply APY for key assets. Stress scenario framing for Aave V3
• Base case: with current positive 30d fee and revenue profile, the primary economic engine remains positive at protocol level over 30 days.
• Stress path to negative effective yield:
• Sharp utilization collapse on major chains (Ethereum, Arbitrum, Base, Polygon) driving supply APY toward 0 while risk remains.
• Adverse events (stablecoin issues, collateral price crashes) leading to supplier losses not fully offset by interest. Gaps / data limitations
• On‑chain verification of per‑chain 30d profitability and per‑reserve cash flows is Not verifiable as of 2026-08-26.
• Exact chain‑by‑chain TVL / revenue splits for all listed chains (Aptos, BSC, Celo, Gnosis, Linea, Mantle, MegaETH, Monad, OP, Plasma, Sonic, Xlayer) are not consistently reported across independent aggregators and remain Not verifiable as of 2026-08-26.

Aave V3’s legal posture is split between the Aave Labs / interface terms and the Aave DAO/protocol. The current Terms of Service are governed by Cayman Islands law and prohibit use in illegal jurisdictions, by sanctioned persons, or for money laundering, terrorist financing, fraud, tax evasion, export-control or sanctions violations; they also reserve the right to restrict access if misuse is suspected. The app terms further state that Aave Labs does not perform regulated KYC, custody, or exchange services, while some features may depend on third-party KYC or jurisdictional restrictions. On classification, the available materials support a non-custodial DeFi protocol/interface framing, but legal risk remains because the terms acknowledge compliance controls and geographic blocks, and governance commentary says the DAO itself cannot sign contracts, hold legal title to assets, or undergo KYC/AML procedures. That structural gap means the *legal wrapper* is narrower than the *actual operational and enforcement risk*. There is also active legal-enforcement exposure: independent reporting describes a 2026 U.S. federal-court dispute involving frozen ETH recovered from the Kelp DAO exploit and Aave’s attempt to unfreeze it. I found no verified sanctions designation for Aave itself, and no court judgment showing Aave is sanctioned; the main sanctions language is in Aave’s own terms and user restrictions. Publicly available results do not verify any data-protection-specific regime beyond the general legal pages, and the protocol website is the only clearly identified source for the latest terms language. Not verifiable as of 2026-08-26: exact legal entity map for all Aave V3 components, comprehensive KYC/AML implementation details across chains, and whether any additional court cases beyond the 2026 freeze dispute exist.

Yes. The clearest documented depeg event affecting Aave V3 was USDC in March 2023, which hit Aave V3 Avalanche and also triggered liquidations across Aave v2/v3 markets. Another documented depeg affecting an Aave V3 market was sUSD on May 16, 2024, on Aave V3 Optimism. So, based on the gathered sources, there were at least 2 documented stablecoin depeg events relevant to Aave V3. The most recent one in the sources was sUSD on May 16, 2024, with a reported low around $0.915 versus USDC, or about an 8.5% depeg. For USDC in March 2023, the source confirms the depeg and Aave impact, but does not provide a precise % figure in the snippet, so the exact depeg percentage is not verifiable as of 2026-08-26.

For Aave V3, the top 5 risks are: smart contract risk, oracle risk, collateral/liquidation risk, network/bridge risk, and governance / parameter-setting risk.

• Smart contract risk: bugs or vulnerabilities in Aave’s code, reserve tokens, or related components can cause loss of funds or incorrect protocol behavior.
• Oracle risk: Aave relies on third-party price feeds and external data such as redemption ratios for liquid staking tokens; a failed or compromised oracle can misprice assets and trigger bad liquidations or bad debt.
• Collateral/liquidation risk: collateral values can fall quickly, and if assets cannot be liquidated in time or are too concentrated/volatile, the protocol can accumulate bad debt.
• Network/bridge risk: because Aave operates across multiple chains and uses bridges, congestion, censorship, or bridge exploits can affect protocol solvency or user access.
• Governance / parameter-setting risk: Aave V3 uses configurable risk controls such as caps, isolation mode, and collateral parameters; misconfiguration or slow response to market stress can amplify losses. Aave’s own docs emphasize that isolation mode, supply/borrow caps, and granular risk parameters are meant to reduce these risks, but they do not eliminate them.

Aave V3’s top strengths are its capital efficiency, risk controls, cross-chain liquidity design, modular multi-network deployment, and battle-tested security posture. Its strongest user-facing advantage is E-Mode, which raises borrowing power for correlated assets, while Isolation Mode and supply/borrow caps help contain risk when listing new assets.

• High capital efficiency: E-Mode lets users borrow with higher LTV when collateral and debt are in the same correlated category, improving leverage for stablecoins and ETH-like assets.
• Granular risk management: Isolation Mode, debt ceilings, supply/borrow caps, and other asset-level controls let governance tune risk more precisely instead of applying one-size-fits-all settings.
• Cross-chain liquidity architecture: Portal was designed to move liquidity across Aave V3 markets on different networks, reducing fragmentation and improving capital mobility across deployments.
• Multi-network scalability: V3 was built for deployment across many chains with chain-specific features, which helps Aave expand without changing the core lending model.
• Mature, proven protocol design: Independent commentary describes Aave as a top lending protocol with extensive security experience and a long-running, widely used codebase.