Aave v4

The scheduled date is the outside bound. Kill criteria are checked every day, and a trigger reopens the memo that week.

TRACKING, NOT ALLOCATING. Aave v4 launched on Ethereum in March 2026 with three separate Liquidity Hubs—Core, Prime, and Plus—and ten initial Spokes after roughly 345 cumulative days of security review supported by a $1.5M DAO budget. The code work is serious; the production record is necessarily short. The architectural change is more important than the version number: a Hub owns and prices pooled liquidity, while Spokes define collateral, borrowing, liquidation, and risk-premium rules. Separate Hubs are solvency boundaries, but every Spoke attached to one Hub shares that Hub’s assets. Bad debt from one badly parameterized collateral Spoke is realized against the same Hub liquidity, bounded by add/draw caps rather than hard isolation. Inter-Hub credit lines add another controlled contagion path. That is more expressive and potentially more capital-efficient than v3, but it increases the number of contracts, configurations, and governance decisions that determine a supplier’s true exposure. Under review until Core, Prime, and Plus have enough live liquidation and withdrawal history to be assessed separately, and until the v3-to-v4 migration shows that production scale is not outrunning risk operations.

Kill criteria: the events that revoke this verdict
• Reopen a named Hub and asset only after at least 12 months of production history and one liquidation above 1% of that Hub’s TVL without bad debt or withdrawal impairment
• The proposed-size withdrawal must execute from the exact Hub and asset below 50 basis points while trailing-30-day utilization remains below 90%
• Every connected Spoke, per-asset add cap, draw cap, liquidation configuration, pause authority, and inter-Hub credit line must be reproducible from executed governance and live contracts
• Any Spoke draw cap above 10% of its Hub’s matching-asset liquidity, or any inter-Hub credit line lacking a published loss boundary, prevents reopening
• Any core exploit, Hub bad debt, failed proposed-size withdrawal, or unaudited Hub, Spoke, oracle, or configurator upgrade keeps allocation at zero
• Re-review migration when v3 liquidity falls below two times v4 liquidity on the same chain and asset; protocol-wide TVL ratios are insufficient

The research file

The mechanism

Aave v4 separates custody and liquidity accounting from user-position logic. A Liquidity Hub holds the underlying assets, tracks total shares, utilization, indexes, and base interest rates, and authorizes Spokes to add or draw each asset within governance-set caps. Users do not transact with the Hub directly. They enter through a Spoke, which defines accepted collateral, loan-to-value rules, liquidation behavior, and any additional risk premium. One Hub can therefore serve a general lending Spoke, multiple correlated-asset e-Mode Spokes, or specialized markets without each bootstrapping an independent pool.

The benefit and the liability are the same shared pool. A supplier earns from aggregate utilization of an asset across the Hub. Riskier borrowers can be charged a Spoke-level premium, but pricing risk does not erase loss allocation: the initial-configuration analysis by Aave Labs, TokenLogic, Chaos Labs, and LlamaRisk states that if one collateral listing liquidates poorly, resulting bad debt is realized against that Hub’s liquidity regardless of which Spoke created the position. Add and draw caps bound exposure. Separate Hubs create harder solvency boundaries, while asset-specific inter-Hub credit lines can deliberately bridge them up to a cap. The client position must therefore be identified as asset plus Hub plus supplying Spoke, not simply “Aave v4 USDC.”

Who controls it

Aave DAO governance authorizes Hubs and Spokes, sets add and draw caps, approves collateral and liquidation parameters, configures risk premiums and credit lines, and can pause supported operations through the protocol’s access-control system. Aave Labs deployed the initial system; DAO risk service providers make parameter recommendations and governance payloads execute changes. Unlike Morpho Blue’s immutable base, v4 is explicitly modular and designed so that new or upgraded Spokes can connect without migrating Hub liquidity. The governance surface is correspondingly a live part of the credit analysis.

The initial Ethereum topology is intentionally tiered. Core is the general-purpose Hub and main source of inter-Hub credit. Prime is positioned for suppliers seeking a more controlled ETH/BTC collateral posture. Plus contains Ethena-adjacent stablecoin strategies behind separate caps and pause conditions. At genesis the three Hubs supported ten Spokes. Those labels are mandates, not guarantees: the live collateral set, cap utilization, credit-line draw, admin roles, and governance payload determine actual exposure. A front end that shows all positions together must not cause this registry to blend them.

The record

Ethereum v4 became active after DAO approval in March 2026. The public repository lists reviews by ChainSecurity in January and March 2026, Blackthorn in February, and Trail of Bits in February, alongside formal verification, invariant tests, fuzzing, independent researchers, and a six-week Sherlock contest with more than 900 verified participants. Aave reports roughly 345 cumulative review days and a $1.5M DAO-ratified security budget. No reviewed source identifies a successful v4 core exploit or bad-debt event through this review date.

That clean record is only months long and has not yet faced the scale or market history of v3. Governance expanded caps repeatedly after launch: LlamaRisk’s sixth round in June proposed about $167M of additional capacity across the three Hubs—$107M Core, $36M Prime, and $24M Plus—and set expired Pendle PT add caps to zero. This demonstrates active lifecycle management, but it also shows how quickly the configuration surface changes. The April monitoring update says Aave Labs and Certora were still building production invariant and configuration visibility while cap growth proceeded.

The exit

A supplier withdraws through the relevant Spoke, but liquidity comes from its Hub. The practical exit constraint is Hub-level available liquidity for that asset after all connected Spokes’ borrowing, not the utilization displayed for one collateral strategy in isolation. Prime is designed to improve predictability for ETH and BTC collateral suppliers, yet assets imported through a Core credit line are still limited by that line and the source Hub. Plus stablecoin exits depend on its own supply, strategy borrowing, and any cross-Hub support.

The registry should measure withdrawable liquidity by Hub and asset, then map every connected Spoke and credit line that can consume it. A low-utilization Spoke can coexist with a highly utilized Hub; conversely, a capped Spoke can contain a risky strategy even while the Hub remains liquid. Approval requires a monitor that can reconstruct that topology and alert before a client discovers the distinction at withdrawal time.

The comparison

Aave v3 markets are self-contained pools: each instance has its own asset set, liquidity, utilization, and shared collateral risk. This fragments identical assets across Core, Prime, and other instances but makes the solvency boundary comparatively legible. V4 moves that boundary to the Hub and makes user behavior modular through Spokes. It can reuse liquidity and price collateral risk more precisely, but a supplier must now reason about a graph rather than one pool.

Morpho takes the opposite path: each immutable market is isolated, while a curator vault aggregates markets for users. V4 centralizes liquidity first and lets governance authorize controlled risk modules around it. Neither design is inherently safer. For this mandate, mature v3 remains preferred because its failure and governance record exists at scale; v4 earns approval only after its capital-efficiency claim is demonstrated without making exposure attribution or withdrawal monitoring less defensible.

Open questions

The next review must inventory every live Hub, Spoke, asset, add cap, draw cap, risk premium, liquidation configuration, pause authority, and inter-Hub credit line on each proposed chain. It must report available liquidity and bad debt by Hub rather than in one protocol total; verify the deployed implementations and admin roles against governance payloads; and test whether Aave Pro makes the Hub identity and cross-Hub exposure visible before a transaction. Production evidence still missing includes a large liquidation through each Hub, a period of sustained high utilization, a credit-line contraction, and a safe Spoke upgrade. Until those paths are observed rather than merely audited, zero allocation is the evidence-based decision.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• Aave v4 Ethereum launch record · primary · accessed 2026-08-15
  Supports: Ethereum activation, initial Hubs and Spokes, launch posture
• Aave v4 architecture · primary · accessed 2026-08-15
  Supports: Hub custody and accounting, Spoke position rules, credit lines
• Aave v4 risk-isolation design · primary · accessed 2026-08-15
  Supports: Hub solvency boundary, Spoke caps, shared liquidity risk
• Aave v4 initial Hub-and-Spoke configurations · primary · accessed 2026-08-15
  Supports: Core Prime Plus topology, bad-debt allocation, add and draw caps
• Aave v4 Ethereum activation ARFC · primary · accessed 2026-08-15
  Supports: activation governance, initial parameterization, security-first scope
• Aave v4 adoption paths · primary · accessed 2026-08-15
  Supports: migration plan, Hub growth, risk-operation pacing
• Aave Labs March 2026 development update · primary · accessed 2026-08-15
  Supports: mainnet readiness, architecture delivery, security work
• Aave Labs April 2026 development update · primary · accessed 2026-08-15
  Supports: production monitoring, invariant work, configuration tooling
• Aave v4 code and audit repository · primary · accessed 2026-08-15
  Supports: deployed code, audit reports, formal verification and tests

Inherited controls

The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.