AAVE V4

Identification (as of October 10, 2026). Aave V4 is the official Aave Protocol V4, a DeFi overcollateralized lending/borrowing protocol. Website: Aave; documentation: Aave V4 technical docs. Native/governance token: AAVE (V4 has no separate native token).

Mainnet launches: Ethereum — March 30, 2026; Avalanche — July 15, 2026. Contracts and verification. Primary hubs identified:

• Ethereum Core Hub: 0xCca852Bc40e560adC3b1Cc58CA5b55638ce826c9; additional Ethereum hubs are Plus 0x06002e9c4412CB7814a791eA3666D905871E536A, Prime 0x943827DCA022D0F354a8a8c332dA1e5Eb9f9F931, and Global Dollar 0x62d63197660c080236193CA60b70E49A08E90368.
• Avalanche Core Hub: 0xd07369fAE4A5BB13c9Ce446B052c7867B1AbDf6e. The Ethereum addresses cross-check between Aave’s deployed-contracts page and the official address book; Avalanche is cross-checked by the address-book-derived deployment record and Snowtrace. Dune cross-check: Not verifiable as of October 10, 2026. Ethereum explorer verification could not be independently confirmed because Etherscan blocked retrieval; Snowtrace displayed the Avalanche address and an implementation, but the proxy page reported no matching source entries. Therefore, full requested two-source-plus-Dune verification is incomplete. Fork lineage. This is not an unaffiliated fork; it is Aave Labs’ official successor codebase, maintained in Aave’s repository. It substantially changes V3’s pool model into modular Hub-and-Spoke architecture: shared liquidity hubs, specialized spokes, risk premiums, dynamic configuration, new position managers, reinvestment, and a V4 liquidation engine. Audits/security. Published reviews include Trail of Bits, Blackthorn, ChainSecurity, Sherlock, and Certora formal verification. Similar-fork malicious-modification history. A documented Aave fork, LND, was exploited after modifying Pool Admin privileges—material evidence that fork-specific governance/access-control changes can be dangerous.

Aave V4 appears to have a real product surface, not just a landing page: the docs describe programmatic integration, user position management, supply/borrow/repay/withdraw flows, and a public GraphQL API for v4 with no API key required. The docs also explicitly say Aave V4 supports withdrawal actions and that users can supply, borrow, repay, withdraw, and monitor positions through the interface/SDKs. The maturity signal is strong on documentation and developer tooling, but live end-user operational maturity is only partially verifiable from the available web evidence.

The public docs and changelog indicate a v4 launch on Ethereum mainnet and testnet/interface work, while governance updates describe an Aave Pro interface for v4 and an early-access Aave App, suggesting active productization rather than a static marketing site. For broken links, fake metrics, and template-sign checks, not verifiable as of 2026-10-10. The retrieved sources do not expose a full site crawl or UI inspection, so there is no reliable evidence here of broken links or template reuse.

Open API: yes. The docs state a public Aave GraphQL API for v4 at api.v4.aave.com/graphql with no API key required.

Aave V4 has an active bug bounty program hosted on Sherlock. It was live since May 18, 2026, with a stated maximum payout of up to $3.5M. The program scope on Aave’s security page says it covers the Aave V4 bug bounty, and a governance proposal confirms the first payout under the Aave V4 program occurred in May/June 2026.

The exact payout parameters by severity are not fully disclosed in the retrieved sources; one governance discussion references proposed/current ranges for Aave V4 and an Aave security page lists the program as live, but the detailed Sherlock scope page content was not fully captured here. Reported results: at least one valid submission was paid out, described as the first payout under the Aave V4 bug bounty program. Because on-chain verification is unavailable in this run, any more precise bounty-result totals are not verifiable as of 2026-10-10.

Dependency & counterparty risk — Aave V4 (Ethereum, Avalanche) dependency_failure_active: false — no active dependency failure was identified in the reviewed sources as of October 10, 2026. This is not an on-chain verification. max_exposure_pct: null — Not verifiable as of October 10, 2026. Dune MCP was unavailable, so aggregate exposure by dependency, chain, or counterparty cannot be calculated. Key dependencies and scenarios

• Shared-liquidity contagion: V4’s Hub-and-Spoke design shares Hub liquidity across Spokes. A deficit or bad debt originating in one Spoke can therefore impair suppliers across that Hub. Ethereum borrowing is concentrated in WETH, USDG, USDC, USDT and frxUSD; governance materials report approximately 96% of WETH debt associated with leveraged weETH positions.
• Oracle risk: Reserve pricing is governance-selected and relies on external oracle infrastructure, including Chainlink. Failure, staleness, delayed updates, or manipulation—particularly for thinly traded LSTs, wrapped assets, and stablecoins—could cause mispricing, under-collateralized borrowing, or cascading liquidations.
• LST/restaking exposure: Ethereum includes wstETH and weETH; the rsETH route was reportedly frozen/limited after risk concerns. Principal scenarios are LST discount, delayed redemption, validator/restaking failure, or liquidator illiquidity.
• Bridges and wrapped assets: Avalanche’s initial Hub includes BTC.b and WETH.e, creating bridge, wrapper, issuer, and redemption dependencies. Avalanche also uses sAVAX, exposing the market to liquid-staking and AVAX basis risk.
• Stablecoins: USDC, USDT, EURC, GHO and additional assets such as USDG/frxUSD introduce issuer insolvency, freezing, reserve, regulatory, and depeg risk. A stablecoin depeg could impair collateral, borrowing liquidity, and liquidation proceeds. GHO additionally depends on Aave governance and facilitator controls.
• Custodians/CEX/MMs/RWA SPVs: No direct CEX, market-maker, custodian, or RWA-SPV exposure was verifiable from the reviewed sources for the specified deployments. Exact indirect exposure is Not verifiable as of October 10, 2026. Primary failure paths: oracle outage/manipulation; bridge or wrapper insolvency; LST/restaking depeg; stablecoin freeze/depeg; or a Spoke-level exploit producing Hub-wide liquidity impairment.

Aave V4 organizes custody as a Hub-and-Spoke system: user-facing Spokes handle deposits, withdrawals, borrowing, and repayment, while a shared Liquidity Hub centrally holds liquidity and enforces accounting and caps on each Spoke. For the proposed/marketed custodied collateral lending design, the underlying crypto is kept with an external custodian (Anchorage in the proposal), and Aave uses a non-transferable onchain receipt token (CoCT) plus Chainlink synchronization to represent and track that offchain custody position. On the provided sources, this means custody is not entirely native-onchain for that institution-specific flow; the real asset stays with the custodian, while the protocol tracks the loan against receipt tokens and isolated Hub/Spoke parameters.

Key-management organization — Aave V4

• DAO governance is the normal control plane. Configuration changes, permissions, asset listings, and upgrades are prepared as governance payloads, voted on by the Aave DAO, queued through the governance executor/timelock, and then executed on the relevant chain. V4’s Config Engine standardizes payload construction but does not itself constitute a signing authority.
• Core privileges are split by architecture. The Liquidity Hub is described as immutable and controls shared liquidity accounting and emergency-stop functionality. Spokes are upgradeable modules handling market logic, reserve configuration, and oracle interactions. This concentrates the highest-risk upgrade authority in governance-controlled pathways rather than individual operator keys.
• Initial hardening uses a V4 Security Council multisig. During the launch/hardening phase, it can perform narrowly defined security and maintenance actions, including emergency protection and certain deployment/configuration operations. Its authority is intended to reduce over-reliance on full governance-cycle latency; after hardening, routine updates are expected to return to AIPs and approved stewards, while emergency pause/freeze powers remain. A V4 maintenance update was explicitly executed through the Security Council multisig.
• Risk authority is delegated and bounded. On Ethereum and Avalanche, the V4 Risk Steward design grants revocable authority over specified Hub, Spoke, and oracle-risk parameters, constrained by role separation, cooldowns, and maximum-change limits. It is not a general upgrade key.
• Emergency response is a separate multisig layer. Aave’s Protocol Emergency Guardian is configured as a 4-of-7 multisig and can pause markets, freeze reserves, and take time-sensitive risk actions across deployments. Individual signers are intentionally not publicly attributed. This should not be assumed to be identical to the V4 Security Council. Assessment: The model is layered separation of powers: DAO/timelock for durable changes, Security Council for launch and maintenance, bounded Risk Stewards for parameter operations, and an emergency guardian for rapid containment. Not verifiable as of October 10, 2026: the V4 Security Council’s exact signer set and signing threshold from the reviewed public sources. Dune was unavailable, so no on-chain key/role verification was performed.

Scope/status (as of October 10, 2026). Aave V4 is deployed on Ethereum and Avalanche; Dune MCP was unavailable, so on-chain event decoding, exact timelock measurement, and current proxy-admin ownership are Not verifiable as of October 10, 2026. Addresses. Ethereum: AccessManager 0x08aE3BE30958cDd1847ec58fFfd4C451a87fDF01; HubConfigurator 0x1F0753480bB03EaA00863224602267B7E0525C3d; SpokeConfigurator 0x9BFFf48BFb5A7AE70c348d4d4cb97E8DEFa5389a; Core Hub 0xCca852Bc40e560adC3b1Cc58CA5b55638ce826c9. Avalanche Core Hub is reported as 0xd07369fAE4A5BB13c9Ce446B052c7867B1AbDf6e; exact Avalanche registry and proxy-admin addresses are Not verifiable as of October 10, 2026. Architecture / upgradeability. Users → Spokes/TokenizationSpokes → Hub → assets; configurators and position managers are peripheral control planes. Hubs hold pooled assets; Spokes handle supply, withdraw, borrow, repay, liquidation and oracle interactions.

Hubs are described as immutable in the audit, while Spokes and TokenizationSpokes are upgradeable proxies. The permissions book assigns upgrades primarily to the 5/8 V4 Security Council; some configurators are non-upgradeable and selected hubs/spokes are governance-upgradeable. Privileged actions. HubConfigurator can add/deactivate/halt assets and spokes, change caps, fees, fee receivers, interest-rate strategies and reinvestment controllers. SpokeConfigurator can change oracle sources, collateral factors, liquidation settings, pause/freeze reserves and position managers.

TreasurySpoke’s Security Council owner can withdraw and transfer treasury-held assets. These are material freeze, oracle, fee, strategy and upgrade powers. Admin-drain assessment. admin_can_drain=true: a compromised 5/8 Security Council could upgrade user-facing Spokes/TokenizationSpokes or alter privileged routing/configuration; TreasurySpoke also exposes owner-controlled withdrawals/transfers. This is not equivalent to a direct Hub sweep, but it is a credible governance-key compromise path to user-fund loss.

Users can normally withdraw through Spokes, subject to liquidity, collateral and pause conditions; emergency pausing can block withdrawals. Audit. ChainSecurity reported 0 critical and 0 high findings for the reviewed code version, with reported issues addressed; deployment-bytecode equivalence and other audit reports’ unresolved counts are Not verifiable as of October 10, 2026. Risk flags. Renounced roles: Not verifiable as of October 10, 2026. Timelock delay: Not verifiable as of October 10, 2026. Worst case: council compromise enables malicious proxy upgrades, oracle/parameter manipulation, reserve freezing, or treasury extraction; shared-Hub contagion can spread losses across connected Spokes.

ChainSecurity — Tokenization Spoke Security Audit

Trail of Bits — Security Review

Sherlock — Collaborative Audit Report

Blackthorn — Security Review

ChainSecurity — Security Audit

Certora — Formal Verification, Libraries

Aave V4 is the current-generation deployment of the established Aave ecosystem, not an apparently unrelated namesake: available reporting identifies Aave Labs as the original author and key contributor to Aave Protocol, with V4 live on Ethereum and Avalanche. The documented founder and CEO is Stani Kulechov, a publicly identified executive who has represented Aave Labs in launch and institutional-finance discussions. Founders, team, and prior outcomes

• Kulechov is publicly associated with Aave Labs and Aave’s earlier protocol development; the reviewed evidence does not provide a complete, independently verified roster of V4 employees, directors, or beneficial owners. Not verifiable as of October 10, 2026.
• Aave Labs’ prior product record includes Aave Protocol, the GHO stablecoin, and Horizon, an institutional/tokenized-real-world-asset lending platform. These indicate an operating product organization rather than a single-purpose web front, although the reviewed sources do not independently verify corporate revenues, headcount, or audited financial statements.
• A reported Kelp DAO cross-chain exploit created unbacked rsETH that was used as collateral in Aave markets; Aave contracts were reportedly not breached, but Aave froze affected rsETH/wrsETH markets and experienced substantial deposit outflows. This is a material *dependency and contagion* incident, not evidence of an Aave core-contract exploit. Public status, credibility, and physical presence
• Founder identity is public; the broader V4 team is not fully transparent in the evidence reviewed. Credibility is supported by Aave’s long-running protocol history, live deployments, and continued governance/development activity, but security and counterparty risks remain material.
• A real, independently verified office address, legal domicile, onshore/offshore structure, and beneficial-ownership record were not established from the reviewed independent sources. Not verifiable as of October 10, 2026. > Reality-check limitation: No raw on-chain verification was available in this run. Therefore founder-linked ownership, treasury control, team wallets, V4 TVL/exposure by Ethereum versus Avalanche, and claimed business scale are Not verifiable as of October 10, 2026. Claims appearing only in Aave materials should be treated as unverified marketing claims. Overall, the evidence supports a real and publicly led DeFi organization behind Aave V4, but it does not establish a fully transparent corporate footprint or independently verify all team, jurisdiction, office, ownership, and financial claims.

Scope note. The available evidence concerns the Aave V4 deployments on Ethereum and Avalanche. On-chain verification, including chain-by-chain TVL/exposure, is Not verifiable as of October 10, 2026 because the required on-chain data access was unavailable. No Dune query ID or execution ID can therefore be provided. Reputation and security

• Aave is an established DeFi lending protocol; V4 launched on Ethereum in March 2026 and on Avalanche in July 2026.
• Aave Labs reports approximately 345 cumulative days of security work, including audits, formal verification, fuzzing, invariant testing, and a public contest with more than 900 participants. These are protocol-reported claims and should not be treated as independent validation.
• The reported auditors and reviewers include Trail of Bits, ChainSecurity, Blackthorn, Certora, Stermi, and Josselin. Aave states that published reports found no high-severity vulnerabilities and that findings were remediated and revalidated. The underlying audit conclusions and residual risks were not independently verified here. Founders, investors, and governance
• Stani Kulechov is identified in the available reporting as Aave’s founder. A verified V4-specific investor roster was Not verifiable as of October 10, 2026.
• Independent reporting alleges increasing concentration of control around Aave Labs, citing a claim that Aave Labs controlled approximately 23% of AAVE supply and that Aave Chan Initiative leader Marc Zeller announced a wind-down amid “structural governance problems.”
• BGD Labs reportedly declined to renew its technical-contributor relationship, while Chaos Labs reportedly left amid workload and disagreements regarding V4’s architecture. These reports indicate governance and contributor-continuity concerns, not proof of misconduct. Fraud, rug, insolvency, legal, and sanctions risk
• No sourced evidence in the retrieved material establishes that Aave V4 is a fraud, rug pull, insolvent protocol, sanctioned entity, or subject to a court or regulator enforcement action. Each item is Not verifiable as of October 10, 2026 from the available evidence. Overall assessment: Aave V4 has a comparatively strong disclosed security-review profile, but the principal unresolved concerns are centralization of governance influence, dependence on Aave Labs, contributor turnover, and the limited operating history of a newly deployed architecture. The “zero high-severity findings” statement remains a protocol-reported claim rather than an independently verified assurance.

Scope/status. Aave V4 is confirmed live on Ethereum (March 30, 2026) and Avalanche (July 15, 2026). The selected slug also currently tracks Arc, which is outside the requested scope. Economic model. This is a permissionless, overcollateralized lending market—not a standalone yield farm. Users supply supported assets into a shared Hub and receive interest-bearing positions; borrowers post collateral and pay variable interest.

Yield is primarily borrower interest, with additional protocol income from retained liquidity fees and liquidation fees. V4 Spokes impose asset-specific collateral factors, caps, interest-rate curves, risk premiums, and emergency halts. Assets/exposure. Ethereum and Avalanche launch assets include major crypto, stablecoin, and correlated assets; Avalanche’s Core Hub lists WAVAX, sAVAX, BTC.b, USDC, USDT, WETH.e, and EURC. Exposure is therefore directional for supplied/borrowed volatile collateral, although stablecoin or correlated-asset markets can be approximately market-neutral.

No native lock-up is described: withdrawals are generally available subject to liquidity, reserve status, caps, and maintaining a safe health factor. Leverage/looping/restaking. Users can create leverage by recursive supply/borrow loops, but the protocol itself is not inherently leveraged, restaking-based, or dependent on an external yield strategy. V4 can authorize reinvestment controllers to move idle Hub liquidity into external strategies; deployment and exposure are governance-dependent. Fees/revenue. DefiLlama reports, as retrieved October 10, 2026: TVL $668.56m, active loans $410.76m, 30-day fees $877,910, and 30-day protocol revenue $124,872. Revenue is not distributed to AAVE holders in the cited dataset.

Average supply APY is 1.81%; APY history/volatility and sustainability are Not verifiable as of October 10, 2026 without a reproducible time series. TVL. DefiLlama: Ethereum $443.92m (66.4% of global tracked TVL), Avalanche $30.79m (4.6%), Arc $193.85m (29.0%). Within the requested two-chain subtotal ($474.71m), Ethereum is 93.5% and Avalanche 6.5%. TVL rose 68.9% over 30 days.

Dune TVL/product/chain trend and reconciliation are Not verifiable as of October 10, 2026; Dune MCP was unavailable. Risk conclusion. Returns are demand-sensitive and variable, not fixed; sustainability depends on borrow utilization, asset liquidity, oracle quality, liquidations, and governance risk. Subsidy share is Not verifiable as of October 10, 2026.

Scope: Aave V4 is a live, multi-chain lending system, but its user-supplied reserves are not the same as Aave DAO treasury assets. V4 uses shared Hubs plus Spokes; the dedicated Treasury Spoke is a contract-controlled custody bucket, while lending liquidity remains in Hub accounting. Treasury addresses

• Ethereum V4 Treasury Spoke: 0xB9B0b8616f6Bf6841972a52058132BE08d723155.
• Avalanche V4 Treasury Spoke: 0x2C4Aea1A5F000889c6DfFE8f52377aFc2CB113a6. Composition / custody
• Avalanche V4’s shared Core Hub supports WAVAX, BTC.b, USDC, USDT, WETH.e and EURC; the AVAX-correlated market adds sAVAX.
• Ethereum V4 has multiple Hubs and many Spokes, including Core, Plus, Prime and Global Dollar configurations. Listed assets include ETH derivatives, BTC wrappers, stablecoins, AAVE, LINK, GHO, tokenized gold and others. This is protocol liquidity composition, not verified treasury ownership.
• Treasury Spoke functions include supply, supplySkimmed, withdraw, and transfer; control is assigned to the V4 Security Council. Avalanche permissions identify the same control model. Balances / liabilities
• Dune MCP was unavailable in this run; therefore on-chain balances, token-by-token composition, USD valuation, liabilities/borrowings, and chain-level exposure percentages are: Not verifiable as of October 10, 2026.
• No reserve-specific proof-of-reserves or balance attestation was identified. Published V4 audits and formal verification address smart-contract/security properties, not current asset balances. Not verifiable as of October 10, 2026. Reserve policy: governance/risk parameters, caps and market configuration are managed through V4 governance, configurators, stewards and the Security Council; the older DAO asset-management guideline targets capital preservation and ecosystem funding, but is not a V4-specific current reserve statement.

Aave V4 has no separate native token. It uses Aave’s existing AAVE governance/safety token; the canonical Ethereum contract is 0x7fc66500c84a76ad7e9c93437bfc5ac33e2ddae9 (18 decimals). AAVE is bridged/represented on other networks, but governance balances remain rooted on Ethereum. Supply/valuation (October 10, 2026): total/max supply 16.0M AAVE; circulating supply 15.436M; market cap approximately $2.675B; FDV approximately $2.772B. Utility and value accrual: AAVE, stkAAVE and aAAVE provide governance power over listings, parameters, upgrades and treasury decisions. AAVE can be staked in the Safety Module, used as collateral, and may receive staking/incentive rewards.

Governance approved a buyback program funded by protocol revenue, with a stated annual budget of up to $50M; purchased AAVE is sent to the Ecosystem Reserve, not burned. There is no direct revenue dividend to holders. Historical allocation: 13M AAVE came from LEND migration: public sale 10M (62.5%), core developers 0.9M (5.625%), UX 0.6M, management/legal 0.6M, promotions/marketing 0.6M, unexpected costs 0.3M. The Ecosystem Reserve received 3M (18.75%).

No distinct original investor allocation was disclosed. Emissions/unlocks: the announced reserve-emission program initially proposed 250k AAVE each for safety and ecosystem incentives in year one, but a complete current emissions/unlock calendar and whether every announced release occurred on-chain are Not verifiable as of October 10, 2026. Concentration: an Etherscan snapshot reports top-5 holders at 30.93%, top-10 at 41.74%, and top-100 at 77.87%; the largest labeled balances include stkAAVE, the Ethereum AAVE V3 reserve, Ecosystem Reserve, and exchange wallets. Insider attribution is Not verifiable as of October 10, 2026. Contract controls: no public mint or blacklist function and no transfer-fee switch were detected; supply is described as fixed. The token uses a proxy architecture, so upgrade-admin control remains a governance/security consideration; current controlling address is Not verifiable as of October 10, 2026. Liquidity/listings: major centralized listings include Binance, KuCoin, Bybit, Coinbase and OKX; Uniswap and Balancer are principal DEX venues.

Reliable current DEX liquidity depth by chain is Not verifiable as of October 10, 2026.

A Bitcoin drop below $10,000 would be a severe stress event for Aave V4 because Aave liquidations trigger when a position’s health factor falls below 1.0, and health factor is defined as collateral value divided by debt value. Aave says liquidations are meant to restore solvency, and V4’s liquidation engine can repay just enough debt to bring a borrower back to a configurable target health factor. For the Ethereum and Avalanche V4 deployments, the main risk channel is not protocol insolvency at the first shock, but forced deleveraging and possible bad debt if collateral cannot be liquidated fast enough during a rapid price move or if external liquidity is insufficient.

Aave explicitly notes that rapid collateral declines and insufficient liquidity can cause bad debt, though it frames such deficits as expected but generally small in magnitude under normal conditions. A BTC crash would be most dangerous for any BTC-correlated collateral spokes and any positions using BTC-like assets as collateral or as a hedged leg, because correlated drawdowns can push many accounts below liquidation thresholds at once. Governance risk discussions for V4 specifically warn that correlated exposures can accumulate at the hub level even when individual spoke caps look safe, and that BTC- or ETH-correlated collateral can create concentrated liquidation dynamics under severe drawdowns.

What I cannot verify from the available sources is the current chain-specific BTC exposure, collateral mix, and solvency buffer for Aave V4 on Ethereum and Avalanche. Not verifiable as of 2026-10-10. The practical stress verdict is: high liquidation pressure, possible temporary borrowing constraints, and elevated bad-debt risk on any BTC-linked or highly correlated positions, but the exact protocol loss estimate is Not verifiable as of 2026-10-10 without on-chain exposure data.

A 20% depeg of the largest collateral is a material stress event, but the exact loss absorption or bad-debt outcome for Aave V4 on Ethereum and Avalanche is Not verifiable as of 2026-10-10 because no on-chain position, exposure, or chain-level collateral concentration data is available in the provided sources. What can be verified is that Aave V4 liquidations are designed to restore a borrower to a configurable target health factor rather than a fixed close factor, and liquidators can only repay enough debt to bring the position back toward that target. For stress interpretation, the key protocol risk is whether the depegged asset is large enough, relative to the current collateral mix and liquidation depth, that liquidations cannot clear positions fast enough before losses exceed the liquidation buffer.

Aave governance materials also state that V4 risk is managed through per-Spoke draw caps and collateral-factor settings, but the actual exposure by chain is not provided in the sources here. If you want a quantified answer, the missing inputs are: largest-collateral token on each chain, its supply share, liquidation threshold / collateral factor, borrow concentration against it, and current liquidation capacity. Without those, the stress result cannot be computed reliably from the available evidence.

Scope and limitation — as of October 10, 2026. Aave V4 is live on Ethereum and Avalanche, but Dune is unavailable in this run. Therefore, the largest borrower/counterparty and its exposure are Not verifiable as of October 10, 2026. The scenario below treats the top borrower on each chain as insolvent; Ethereum and Avalanche must be assessed separately because liquidity and deficits are hub-specific. Ethereum — hypothetical largest borrower default

• Expected loss path: borrower stops servicing debt → the relevant Spoke’s liquidationCall seizes and sells collateral. Loss equals residual debt after liquidation proceeds, liquidation incentives, and any accrued surplus. No numeric estimate is verifiable.
• Who absorbs it: the deficit is attributed to the Hub asset from which liquidity was drawn, potentially affecting suppliers connected to that Hub. V4’s shared-Hub design means one Spoke’s bad debt can reduce solvency for other Spokes using the same Hub.
• Compensation/backstop: the Spoke calls reportDeficit; the Hub records the shortfall. Configured DAO deficit offsets apply first; Umbrella then burns corresponding staked aTokens/supplied shares to eliminate the asset-specific deficit. Coverage is limited to eligible assets and available capacity; any remainder is borne economically by suppliers.
• Smart-contract impact: Spoke → liquidationCall → Hub.reportDeficit → Hub deficit ledger → Umbrella/authorized elimination burns supply shares; borrower position is cleared, while supplier share value or withdrawable liquidity falls if coverage is insufficient. Avalanche — same insolvency scenario
• Expected loss path: identical contract sequence, but isolated to the relevant Avalanche Hub/asset and its connected Spokes; no automatic cross-chain reimbursement is implied. Avalanche V4 uses a Core Hub with Main, AVAX-Correlated, and Forex Spokes.
• Absorption and compensation: the affected Avalanche Hub suppliers absorb uncovered loss; eligible Umbrella coverage and any DAO offset provide first-loss protection, subject to configured limits. Cross-chain contagion is therefore indirect—through governance, liquidity migration, or correlated asset prices—not a direct transfer of the deficit. Bottom line: the principal counterparty-loss risk is not borrower insolvency alone, but liquidation shortfall plus inadequate asset-specific Hub/Umbrella coverage.

For the DAO or owners committing fraud scenario, I would rate Aave V4 as a moderate governance/insider-risk case, not a verified fraud case. The strongest available evidence shows a real control split: the DAO governs core protocol contracts, while Aave Labs controls the website, app, infrastructure, brand, and domains, which creates an avenue for conflict but is not itself proof of fraud. There are also credible reports of an active governance conflict around Aave V4.

Independent media reported that critics allege Labs is pushing users toward V4 and that recent governance dynamics may allow Labs-linked voting power to dominate some outcomes; another report described concerns that the new framework could shift value away from token holders. However, these are allegations and interpretations, not evidence that the DAO or owners have committed fraud. On the other hand, Aave’s own governance proposal and security materials state that V4 contract governance is managed by the DAO via Executor Level 1, with temporary Protocol Security Council control for certain single-controller components during hardening, and that multiple independent audits found no critical or high-severity vulnerabilities.

That reduces the likelihood of a straightforward “fraud by code” narrative, but it does not eliminate the risk of governance abuse, conflicted steering, or revenue redirection. The main stress points are therefore:

• Control asymmetry between DAO-governed contracts and owner-controlled brand/frontend/infrastructure.
• Potential revenue-routing conflicts if product revenue, branding, or migration incentives are structured to favor Aave Labs/Avara over token holders.
• Governance concentration risk if Labs-aligned voting power can carry proposals despite dissent. Bottom line: not verifiable as a fraud event as of 2026-10-10. The defensible assessment is elevated governance and insider-alignment risk, with fraud remaining an unproven but plausible stress scenario if control of branding, product distribution, or treasury flows were used to misappropriate value.

For a stress scenario with a negative primary yield source over 30 days, the main risk is that Aave V4’s reinvestment/yield-seeking layer stops contributing positive carry while funding or management costs remain, which can compress or invert net spread economics. Aave V4’s design explicitly routes idle capital into yield strategies via a reinvestment controller, so a sustained yield drawdown directly weakens that leg of the model. The relevant stress implications are:

• Lower protocol revenue from the yield sleeve: if the reinvested asset earns less than expected, the added fee income thesis deteriorates.
• Potential mismatch with target return assumptions: third-party analysis of Aave V4 allocation economics notes that observed yields can already run below modeled projections, implying that a further 30-day negative move would push the strategy further below hurdle rates.
• Higher stress on hub liquidity: V4 concentrates shared settlement liquidity at the hub, so weaker external yield can matter more when markets are already under stress and capital is concentrated across spokes. What is not verifiable as of 2026-10-10 from the provided sources:
• The actual 30-day return of the current primary yield source on Ethereum or Avalanche.
• Chain-specific exposure percentages to that source.
• Whether the source is currently negative net of fees, slippage, or rebalancing costs. Net assessment: a negative 30-day primary yield source is a bearish stress input for Aave V4 because it undermines the reinvestment module’s incremental revenue case and can worsen hub-level resilience under correlated stress, but the exact magnitude cannot be verified from the supplied evidence.

Scope confirmed: Aave V4 is live on Ethereum and Avalanche. Governance is not purely symbolic, but it is not the sole control layer. The proposal path is ARFC discussion → binding Snapshot → on-chain AIP vote → PayloadsController/timelock execution; standard execution has a 24-hour delay, while governance-permission changes use 7 days.

Cross-chain actions use Aave Delivery Infrastructure. Control split: Aave Labs develops the V4 code and maintains the principal frontend (app.aave.com). Its Terms state that Aave Labs does not operate or control the Protocol, while the frontend/IP remain company-controlled and can be discontinued independently.

The V4 permissions inventory shows most Ethereum and Avalanche Hub/Spoke proxies upgradeable by the V4 Security Council; only selected components are listed as Governance-controlled. The Council is a 5-of-8 multisig and holds broad upgrade, configuration, treasury-spoke withdrawal/transfer, and position-manager permissions. This is a material governance-centralization finding: token-holder governance can approve proposals and parameters, but the Council can bypass a fresh DAO vote for privileged V4 actions.

Independence of the eight signers is Not verifiable as of October 10, 2026. DAO assessment: real for proposal approval, treasury decisions, and some contracts; not sole controller of V4 upgrades. Therefore dao_governance=false under the supplied strict definition.

Because the Security Council can upgrade implementations and control TreasurySpoke transfers, admin_can_drain=true in the broad upgrade-authority sense; direct user-fund custody by Aave Labs is not indicated. Voting concentration and top AAVE holders via Dune: Not verifiable as of October 10, 2026. Company registration number, jurisdiction, and directors for Aave Labs: Not verifiable as of October 10, 2026.

Scope: Aave V4 is deployed on Ethereum and Avalanche, but the protocol is described in its Terms as decentralized, non-custodial software—not a company, lender, broker, exchange, or financial intermediary. Aave Labs states it develops the interface and tooling, while DAO-governed smart contracts execute on-chain transactions. Entity/jurisdiction: The identifiable legal operator for the interface is Aave Labs Ltd / Aave Labs, with Cayman Islands governing-law/forum language.

Aave Interfaces Ltd, the Aave App entity, is registered in the Cayman Islands. The DAO/protocol itself is not presented as a separate incorporated legal person. ToS/restrictions: Interface/app terms impose sanctions and restricted-jurisdiction exclusions, including OFAC/UN/EU/UK-sanctioned persons and comprehensively sanctioned territories; access may be region-blocked or terminated.

Arbitration and class-action waivers apply, subject to non-waivable consumer rights. KYC/AML: No general KYC requirement is stated for direct, permissionless interaction with the Aave V4 contracts. The front ends prohibit money laundering, terrorist financing, fraud, sanctions evasion and other unlawful use, and may apply compliance controls.

This creates a material distinction between permissionless protocol access and regulated or centralized ecosystem services. Classification/legal risk: No settled classification of AAVE, V4 lending activity, or Hub-and-Spoke vault instruments was verified. A U.S.

SEC filing records the sponsor’s counsel view that AAVE is not a security, while expressly acknowledging that regulators or courts could disagree. Legal risk remains jurisdiction-specific and includes securities, lending/credit, money-transmission, AML, sanctions, consumer-protection and tax exposure. Warnings/enforcement/court cases: The SEC meeting with Aave Labs was policy engagement, not an enforcement order.

A protocol/entity-specific active enforcement action, court judgment, or sanctions designation was not identified in the reviewed sources: Not verifiable as of October 10, 2026. Protocol-level legal structure does not eliminate practical attribution risk to Aave Labs, interface companies, DAO participants, developers, or governance-controlled service providers. Privacy materials rely principally on Cayman data-protection law and acknowledge limited ability to identify permissionless on-chain users.

Legal entity per GLEIF: AAVE LABS LTD. (LEI 635400TRMDMOYGUYRZ27; jurisdiction KY; registration ACTIVE). OFAC SDN screening of 'Aave Labs Ltd', 'Aave Interfaces Ltd for the application', 'AAVE V4': no match. SEC litigation and administrative release feeds: no mention.

Aave V4 does not issue its own stablecoin; Aave’s native stablecoin is GHO, but the V4 Avalanche/Ethereum deployments use external stablecoins such as USDC, USDT, and EURC in their listed markets. From the gathered web evidence, no stablecoin depeg event for the Aave V4 deployment is verifiable as of 2026-10-10, so the depeg count, last depeg date, and max depeg percentage cannot be confirmed from the available sources. The protocol is stable in the sense that its published V4 deployments are operational, but stablecoin depeg history for the specific assets used remains not verifiable as of 2026-10-10.

Aave V4’s principal risks arise from its new Hub–Spoke accounting model, oracle dependence, liquidation/solvency dynamics, privileged configuration, and multi-chain deployment. External audits reported no open high- or medium-severity findings in the reviewed code, but explicitly excluded third-party dependencies, deployment scripts, tests, and future code changes; therefore residual risk remains material. Chain-specific TVL, utilization, concentration, and exposure figures are Not verifiable as of October 10, 2026 because Dune on-chain verification is unavailable.

Aave V4’s top strengths are its unified liquidity, modular architecture, stronger risk segmentation, more efficient capital allocation, and more flexible governance/upgradability. The Hub-and-Spoke design lets a shared Liquidity Hub serve multiple specialized Spokes, so liquidity is less fragmented and can support diverse markets from one pool. This also enables more precise risk pricing, because borrowing rules and collateral types can be customized per Spoke without forcing everything into one uniform framework.

• Unified liquidity / network effects: capital sits in a shared Hub, which improves utilization and reduces fragmentation across markets on the same chain.
• Modularity and scalability: Spokes can be added, upgraded, or retired without reworking the whole protocol, making expansion into new use cases easier.
• Better risk management: V4 supports isolated risk per Spoke and collateral-specific risk premiums, allowing tighter control over heterogeneous assets and market structures.
• Capital efficiency: shared liquidity plus differentiated borrowing rules can improve rates and reduce idle capital, while supporting more complex credit markets.
• Governance flexibility: routine parameter changes and market-specific configurations can be managed more dynamically, reducing governance overhead and enabling faster adaptation.