[ARFC] Aave V4 Activation on Ethereum Mainnet

Summary

This proposal seeks community approval to deploy Aave V4 to Ethereum Mainnet through a security-first initial setup with conservative risk parameters and a deliberately narrow Hub and Spoke configuration. Aave V4 introduces a modular architecture where Liquidity Hubs hold shared liquidity and Spokes define distinct borrowing environments with governance-bounded exposure.

This design preserves the depth and efficiency of unified liquidity while allowing for more precise risk management and support for a broader range of market structures. A deployment on Ethereum Mainnet would establish the foundation for V4 as Aave’s next-generation credit infrastructure.

Motivation

Aave is the leading liquidity protocol in DeFi. V4 builds on that position by extending the architecture to support a much broader financial system onchain. As onchain credit expands across more collateral types and risk profiles that form new market structures, Aave needs a framework that can keep liquidity unified while allowing markets to be configured to their own parameters.

Capital Efficiency, Risk Pricing, and Credit Expansion

The next phase of onchain finance brings a new range of market requirements:

New collateral types: Collateral with hard maturities, constrained redemption, or offchain counterparty exposure requires tighter exposure boundaries, and market logic that does not force unlike risks into the same assumptions.

Credit structures: Positions shaped by duration, payout profile, or defined repayment paths require borrowing terms and liquidation logic that can follow the structure of the position itself rather than a single generalized market design.

Productive infrastructure: Cash-flow-backed markets which involve productive infrastructure require borrowing terms, pricing, and exposure limits that reflect scalable energy output, recurring cash generation, and longer-duration repayment profiles.

Supporting new market needs has often meant deciding whether unlike token exposures should share the same borrow curve, reserve configuration, and liquidity base, or they can be moved into isolated markets that preserve cleaner boundaries but require separate liquidity and separate growth. In Aave V4, Spokes keep those market-specific rules and risk boundaries separate, drawing from a Hub that contains deep liquidity reserves.

Credit lines make each Spoke’s access explicit and bounded, so novel markets can be introduced without merging unlike risks into the same market configuration or forcing isolated liquidity bootstrapping each time.

Once market logic is separated, borrowing costs can be matched more closely to the risk being introduced. V4 provides an additional risk pricing mechanic at the collateral level, so stronger positions are not diluted by weaker ones, and more complex token exposures contribute premium in line with their risk profile. Thus, suppliers are compensated on terms that more closely reflect the risk drawn from shared liquidity, and protocol revenue benefits directly from diverse exposure.

As exposure diversifies with more Spokes drawing from shared liquidity, the accounting model is challenged to keep supplier claims, borrower debt, and liquidation flows consistent across the deployment. In Aave V4, supply and debt are tracked through shares, so different borrowing environments can apply different market logic while still settling cleanly against the same balance sheet. Liquidity claims, debt, and liquidation state remain consistent even as Spokes diverge in how they price and manage risk.

Taken together, these changes evolve Aave beyond a single generalized lending design. Liquidity depth is maximized, risk is priced with precision, and a wider range of lending activity can be supported onchain, within one framework, while segregating risk. This positions Aave to become the infrastructure for global onchain finance.

Specification

This proposal covers the initial Ethereum Mainnet deployment of the Aave V4 codebase, the intended launch topology, the rollout path, the implementation and control model, the initial asset universe for risk parameterization, and the security basis for activation. Final parameter values remain subject to risk provider review and will be included in the activation AIP.

Hub and Spoke Configuration

The initial deployment is similar to the three-Hub layout currently under discussion with Core, Prime, and Plus Hubs. In that candidate setup, Core serves as the default liquidity and routing venue, Prime is designed for suppliers seeking a more controlled collateral posture, and Plus is designed for strategy-heavy stablecoin activity that should scale behind its own caps and pause conditions rather than push Core-wide limits.

Core Hub

Spoke	Collateral	Borrowable
Main Spoke	wETH, wstETH, weETH, wBTC, cbBTC, USDT, USDC, LINK, AAVE	wBTC, cbBTC, wETH, USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC
Lido Spoke (e-Mode)	wstETH	wETH
EtherFi Spoke (e-Mode)	weETH	wETH
Kelp Spoke (e-Mode)	rsETH	wETH
Lombard BTC Spoke (e-Mode)	LBTC	wBTC, cbBTC
Gold Spoke	XAUt	USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC
Forex Spoke	USDT, USDC, EURC	USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC

Prime Hub

Spoke	Collateral	Borrowable
Bluechip Spoke	wETH, wstETH, wBTC, cbBTC	USDT, USDC, GHO, coreUSDT, coreUSDC, corefrxUSD, coreEURC

Plus Hub

Spoke	Collateral	Borrowable
Ethena Ecosystem Spoke	PT-sUSDe, PT-USDe, sUSDe, USDe	USDT, USDC, USDe, GHO, coreUSDT, coreUSDC, corefrxUSD
Ethena Correlated Spoke	PT-sUSDe, PT-USDe, sUSDe, USDe	USDe

Each supported asset in each Hub comes with its own tokenization form through a Tokenized Spoke, allowing deposits to be wrapped into tokenized supply positions without enabling borrow capabilities. Tokenized supply positions are ERC-4626 compliant, allowing them to be used in integrations built on top of Aave V4.

Note, borrowable tokens with the core prefix are credit lines from the Core Hub, and tokens drawn from other Hubs will have an appropriate prefix. The initial list of assets included in this configuration are:

• AAVE
• EURC
• GHO
• LBTC
• LINK
• PT-sUSDe
• PT-USDe
• RLUSD
• USDC
• USDT
• USDe
• USDG
• XAUt
• coreEURC
• coreUSDC
• coreUSDT
• corefrxUSD
• cbBTC
• frxUSD
• rsETH
• sUSDe
• wBTC
• wETH
• weETH
• wstETH

Parameters will be provided by Risk Service Providers and included in the AIP.

Rollout

The rollout will begin on Ethereum Mainnet with a deliberately narrow initial activation surface, with security and controlled production hardening taking priority over immediate growth. It will bring V4 online with conservative parameters and minimal assets, so the DAO can observe early liquidity routing, utilization concentration, and credit-line draw behavior.

Supply and borrow caps will be carefully monitored and adjusted over time per risk providers recommendations to grow the protocol with a security first approach. When live conditions support it, the DAO can lift caps, extend or resize credit lines, onboard additional assets, and configure new Hubs or Spokes.

Implementation

Aave Labs will deploy the V4 system and prepare the initial configuration in line with the architecture approved by governance and the final recommendations of the risk service providers. Activation will occur through a subsequent AIP that includes the deployed contract addresses together with the finalized launch parameters.

Within the V4 architecture, the Liquidity Hub is the immutable coordinator for shared liquidity and emergency-stop functionality, while Spokes are upgradeable modules that manage user-facing lending logic, reserve configuration, and oracle interactions. Each Hub maintains the registry of authorized Spokes, sets the relevant caps, and enforces the core accounting invariants that govern shared liquidity and debt across the system.

Guardian Roles

At launch, Aave V4 will use a Protocol Security Council that operates in a role similar to the Guardian framework in Aave V3. During the initial hardening phase, this council will hold the emergency powers needed to safeguard the protocol. Those permissions are expected to step down after hardening, at which point updates will proceed through AIPs and approved stewards, while the council retains pause and freeze powers for emergencies only.

A Stewardship Council is outside the initial launch scope and, when introduced, will come through a follow-up proposal in a role similar to Aave V3 Risk Stewards. Risk changes during the hardening phase are expected to be limited.

Security

The security basis for launch reflects a year-long review process embedded throughout V4 development. Across that process, V4 underwent roughly 345 days of cumulative security review spanning manual audits, formal verification, invariant testing, fuzzing, and a public security contest, supported by a $1.5 million DAO-ratified security budget.

Published materials already include audit reports from Trail of Bits, Blackthorn, and ChainSecurity, together with dedicated invariant and fuzz testing across core V4 components. More information on Aave V4’s security approach can be found in the Security by Design post.

The relevant materials are being compiled here: https://github.com/aave/aave-v4/tree/main/audits

Aave V4 Interface and Documentation

At launch, Aave V4 will be hosted on a dedicated interface at pro.aave.com rather than within app.aave.com. Supporting materials are available through the Aave V4 technical docs in the core repository and the public Aave V4 documentation, both of which will continue to be expanded as the system moves toward activation.

Next Steps

1. Seek community feedback and risk analysis.
2. If community consensus is reached, raise to Snapshot.
3. If the Snapshot outcome is positive, escalate to an AIP, with full risk parameters included, to deploy and activate Aave V4 to Mainnet.

Disclaimer

Aave Labs is the primary contributor to Aave V4 and is directly involved in its design, development, and deployment planning. Aave Labs received compensation to develop Aave V4 under the Aave Labs Service Provider Contract.

Copyright

Copyright and related rights waived via CC0.