Greetings, Aave community!
Over the past year, we have been focused on delivering a major evolution in the Aave Protocol architecture. Development is feature‑complete and the codebase is in final internal review. A multi‑track security program is underway: formal verification has entered a new phase, external reviews are in progress, and multiple independent firms are engaged for layered manual audits in the coming weeks. Service providers have already received the feature‑complete codebase for early testing; whitepaper and developer documentation to follow. We will publish the codebase and architecture documentation for community review and deploy a public testnet with an initial set of Spokes.
This post provides an update on the current state of Aave V4 and what’s next as we move closer to its public release, building on the original Temp Check proposal.
Summary
The rationale behind Aave V4 stems from real technical limitations encountered with Aave V3’s monolithic architecture. In V3, each market is self‑contained and deploying a new one often requires bootstrapping liquidity from scratch, which fragments liquidity and yield profiles across networks. Growth typically relies on token incentives or rented liquidity, capital that is opportunistic by nature and tends to depart once rewards diminish. There is a lack of native mechanism for pricing risk beyond asset exposure: interest rates today do not differentiate based on collateral quality.
Aave V4 aims to address these limitations with a hub and spoke design that rethinks scalability, modularity, and capital efficiency. By decoupling functionality into independently deployable modules (Spokes), the architecture achieves three immediate benefits: more flexible risk management, easier support for asset classes with unique characteristics, and stronger liquidity network effects through Hub‑level pooling. This modularity also paves the way for dynamic risk configuration, enhanced liquidation mechanics, and differentiated borrowing costs via Risk Premiums, all delivered within a more composable codebase.
Current State
-
Codebase: Feature‑complete; undergoing final internal review, gas profiling, and schema checks before the codebase is shared with service providers and the broader community.
-
Security: @Certora formal‑verification campaign launched a new phase following the preliminary analysis completed so far; external security researchers started reviewing the code; @Certora manual review is planned to kick‑off in September; Engage multiple independent audit firms for layered manual reviews.
-
Service Providers demo: A private walkthrough of Aave V4 took place at EthCC Week in Cannes to walk service providers through the feature complete codebase and gather early feedback. Attendees included @TokenLogic, @LlamaRisk, @ChaosLabs, @ACI, and @kpk. A separate deepdive workshop had previously been held with @bgdlabs.
-
Service Providers access to the codebase: Distribute the feature‑complete codebase, whitepaper, and developer documentation to key service providers for early integration testing and feedback.
-
New Aave Interface: A new version is in active development, featuring a unified wallet‑level dashboard across Spokes; the preview will ship alongside the public testnet.
-
Internal devnet: A multi‑Spoke devnet is already live, enabling end‑to‑end testing of core workflows flows.
Next Steps
-
Public codebase: Publish the codebase and architecture documentation, enabling independent review.
-
Public testnet: Deploy Aave V4 to a public testnet with an initial set of Spokes.
Specification
Liquidity Hubs and Spokes
The Liquidity Hub functions as the protocol’s central liquidity contract. Each Spoke registers with the Hub, draws liquidity, and, upon repayment, returns both a base rate set at the Hub level and an asset specific risk premium tied to its collateral composition. Because every market taps the same pool, capital remains fungible across use cases while still allowing differentiated borrowing costs.
A single Hub can serve many Spokes simultaneously, maximizing utilization while containing complexity. Finally, all asset accounting follows ERC‑4626 rounding guarantees, giving integrators predictable share‑price behavior that simplifies downstream integrations and risk modeling.
Both eMode and Isolation Mode are implemented as dedicated Spokes. Users can therefore hold traditional, eMode, and Isolation positions within a single wallet, eliminating the need for separate feature‑specific accounts while preserving their distinct risk treatments. This architecture also streamlines asset onboarding: Yield‑bearing derivatives such as Pendle PT tokens can be listed in a dedicated Spoke without creating a new eMode category, further simplifying both the codebase and governance overhead.
New Aave Interface
The team is developing a new Aave Interface alongside Aave V4 to provide a unified, wallet level view across Liquidity Hubs and their Spokes. The Interface will let users discover and compare Hubs, inspect each Hub’s Spoke configuration (supported assets, supply/borrow caps, and risk parameters), and route supply and borrow actions to a selected Hub from one place. Users will also be able to explore Risk‑Config IDs and Risk Premium curves directly in‑app, improving transparency for onchain risk.
The preview release is planned to accompany the public testnet, enabling the community and service providers to trial multi‑Hub workflows and provide feedback before mainnet.
Protocol immutability
V4’s codebase is intentionally compact, prioritizing clarity and auditability. It is being formally verified alongside continuous fuzz‑testing to minimize the risk of latent logic faults. By default, the core contracts are deployed without upgrade hooks. Once live, they are immutable, yet the system remains extensible because new functionality can still be introduced through additional Spokes. Importantly, immutability does not constrain liquidity provisioning: Liquidity Hubs can make liquidity available to newly registered Spokes and adjust market‑level parameters in real time, preserving operational flexibility while keeping the core code frozen. Risk configurations remain mutable and subject to governance; parameters can be adjusted onchain unless explicitly locked immutably.
Should governance later deem upgradeability necessary, minimal proxy contracts can be layered on top of the existing Hub without affecting its state. Whether to adopt such proxies or preserve full immutability will ultimately be decided by the Governor as part of the release process.
Innovation Possibilities
For developers, the modular Hub‑and‑Spoke framework means new functionality can live in self-contained Spokes while drawing from the same liquidity source. Builders can introduce novel components and tooling without modifying the immutable core, unlocking fresh opportunities for onchain innovation.
Risk managers gain a live control surface: Dynamic Risk Configuration allows onchain updates to Collateral Factors and Liquidation Bonuses, while Spoke‑level supply and draw caps and per‑asset Risk Premium curves can be tuned in real time. Simulation work completed during the research phase provides a solid blueprint for implementing adaptive risk models once governance approves.
Core Features
The table below reconciles the governance approved proposal with the current Aave V4 scope: what is included at launch, what is planned for post launch, and what has been set aside after research. During research and implementation, some features were added where they improved safety, efficiency, or user experience, and others were omitted when they proved inapplicable. This snapshot is intended to give stakeholders a clear status for each feature.
| Feature | Source | Status |
|---|---|---|
| New Efficient Architecture | Proposal | Launch |
| Liquidity Hubs (Unified Liquidity Layer) | Proposal | Launch |
| Risk Premiums | Proposal | Launch |
| Dynamic Risk Configuration | Proposal | Launch |
| Position Managers | New | Launch |
| Reinvestment | New | Launch |
| Liquidation Engine V4 | Proposal | Launch |
| Multicall | New | Launch |
| Umbrella Integration | New | Launch |
| Permissionless Architecture | New | Post Launch |
| Fuzzy-controlled Interest Rates | Proposal | Post Launch |
| Vaults and Smart Accounts | Proposal | Post Launch |
| New Oracle Design | Proposal | Post Launch |
| Automated Assets Offboarding | Proposal | Post Launch |
| Automated Treasury Management | Proposal | Under Review |
| Stronger GHO integration | Proposal | Under Review |
| Actions | Proposal | Omitted in favor of Position Manager |
| Excess Debt Protection | Proposal | Omitted in favor of Umbrella |
Aave V4 Launch Features
At launch, v4.0 will ship with a focused feature set designed to bootstrap initial adoption and protocol efficiency. Additional capabilities will be introduced in phases, prioritized by demand, security considerations, and governance inputs, so the system can scale safely while incorporating real‑world feedback. The features below constitute the scope for day one.
Risk Premiums
Aave V4 replaces uniform, market‑wide borrow rates with a three‑tier Risk Premium system that prices credit according to collateral quality. The Liquidity Hub still quotes a base rate that moves with supply and demand, but every asset now carries a Collateral Risk (0–1000 %) reflecting its own risk characteristics brought to the protocol. Collateral Risk is configured at the Spoke level as part of the Spoke’s risk parameters; the same asset may therefore carry different Collateral Risk values across different Spokes. When a user supplies multiple assets the protocol aggregates them into a User Risk Premium, scaling that borrower’s interest accrual proportionally. At the market level, each Spoke’s Spoke Risk Premium is calculated on demand (not persisted), representing the average risk of all open positions, which feeds into supplier yields and further aligns incentives.
Borrow costs are recalculated on every supply, withdrawal, borrow, repay, or liquidation, and governance can force an immediate refresh during volatile conditions. High‑quality collateral such as WETH therefore pays only the base rate, whereas tokens with weaker liquidity or higher volatility pay a surcharge that grows with risk. By linking pricing directly to collateral composition, Aave V4 rewards users who collateralize stronger assets, supports listing of heterogeneous tokens without implicit subsidy, and provides risk managers with real‑time, onchain tools to manage aggregate exposure.
Ideally, the User Risk Premium would update continuously to reflect its dynamic nature, keeping it aligned with the latest state of a user’s position. However, this is not feasible on EVM networks because each update requires an onchain transaction. In practice, the User Risk Premium is recalculated when the user performs actions that change collateralization (withdraw, borrow, repay) or when anyone permissionlessly triggers an update (updateUserRiskPremium) if it benefits that position. If a user remains inactive, the premium remains unchanged. In exceptional situations, the Governor can force‑update a user’s premium to reflect the most recent collateral parameters, even without user interaction, particularly when risk has increased between interactions.
Dynamic Risk Configuration
In V3, a single global risk setting per asset meant any parameter change (especially lowering the collateral threshold) immediately affects every open position and could cause unexpected liquidations. Aave V4 moves to co‑existing configurations: whenever governance adjusts a Collateral Factor or a Liquidation Bonus, the protocol creates a new configuration and assigns it a Risk‑Config ID. Existing positions continue under the ID they opened with; new positions use the latest ID. In exceptional cases, governance may migrate positions.
Each market tracks its current Risk‑Config ID, and each user position snapshots the ID that applied when it became risk‑bearing. That snapshot refreshes only when the user takes a risk‑increasing action (for example, borrowing more or withdrawing collateral); if the user reduces risk, the snapshot can remain on the prior configuration. This keeps operations predictable for users while allowing governance to tighten parameters for new activity.
For governance, Risk‑Config IDs reduce overhead: parameters can be updated without retroactive shocks, and older IDs can still be modified if needed. In normal conditions, the system naturally updates at the moment of user interaction, avoiding constant governance intervention.
Finally, a built‑in safety guard checks the latest configuration whenever a user attempts a health‑decreasing action. If the position remains sustainable under the latest rules, the engine rebinds the snapshot to the new ID and allows the action. If the latest rules would make the position unsafe, the action is blocked.
Liquidation Engine
V4’s Liquidation Engine moves from fixed close‑factor liquidations to a health‑targeted model. Instead of always allowing liquidators to seize a fixed percentage, liquidations repay just enough debt and/or seize just enough collateral to restore the position to a governance‑defined Health Factor threshold, reducing unnecessary borrower impact. The close factor therefore becomes variable (sized to bring the account back to safety) while remaining bounded by risk limits.
To align incentives during stress, the liquidation bonus is dynamic via a reverse‑Dutch auction: as a position’s Health Factor deteriorates, the bonus increases linearly and the protocol fee decreases correspondingly, rewarding faster intervention on riskier accounts. The engine also embeds deficit accounting that aligns with the forthcoming Umbrella module and reserve‑factor logic.
Position Managers
Governor‑approved Position Managers can, with explicit user approval, execute user‑facing actions on a user’s behalf, such as supply, withdraw, borrow, restore/repay, toggle use‑as‑collateral, and trigger a risk‑premium refresh. Governance can activate or deactivate a Position Manager; users may grant per‑account approvals only to active managers, and can revoke those approvals at any time. All manager‑initiated calls carry an explicit on‑behalf‑of address that identifies the position being modified. Managers may also renounce their role.
To simplify integrations, legacy patterns are removed and similar flows are expected to be handled via account‑abstraction or by Position Managers themselves. The whitelist and approval checks introduce a small per‑operation overhead, while the requirement to approve only active managers is primarily a UX guardrail that could be relaxed if gas becomes a priority. Additional sanity checks (e.g., limiting third‑party repayments) can be added through governance if deemed useful.
Reinvestment
Aave V4 includes a Reinvestment Module that can allocate idle liquidity from the Liquidity Hub to external strategies. The module is intentionally strategy‑agnostic: it provides the infrastructure without prescribing how strategies operate. Whether and how it is used is a governance decision, including leaving it disabled, which leaves the core system unchanged. Decisions on how to implement appropriate strategies and how to handle associated risks will be up to the Governor. It is offered as an optional tool to support capital efficiency when the Governor deems it appropriate.
Multicall
Aave V4 exposes a native multicall designed for batching user actions into a single transaction. The current plan is to adopt OpenZeppelin’s Multicall pattern so common flows (such as supply and set as collateral) can be executed together for improved gas efficiency and fewer signing steps, while remaining composable with external contracts.
This enables it to batch multiple actions into one transaction and significantly reduce gas overhead while improving composability with external contracts. integrators to batch multiple actions into one transaction and significantly reduce gas overhead while improving composability with external contracts.
UX Improvements
Because positions across standard, eMode, Isolation Mode, and future Uni‑CDP spokes all map back to a single Liquidity Hub, a unified dashboard can display heterogeneous positions without bespoke edge‑case logic, simplifying the front‑end codebase.
Post Launch Features
After v4.0, the feature set will expand incrementally. The items below are candidates for subsequent releases and will progress as research concludes, audits complete, and governance signals demand. Ordering may change based on evidence from testnet and mainnet usage.
Permissionless Architecture
Institutional treasuries and onchain service providers increasingly want to “own their infrastructure,” operating isolated instances of Aave liquidity without relying on governance‑gated deployments. V4’s hub‑and‑spoke architecture is engineered for this possibility: anyone can permissionlessly deploy a new Liquidity Hub, register Spokes, and rely on Dynamic Risk Configuration to enforce asset‑level parameters automatically. Whether the Governor ultimately endorses an open‑access model or maintains a allowlisting layer remains a governance choice, yet the codebase is fully prepared for either path. Similarly, the Governor will also determine the economics of sharing Hubs with the Aave DAO.
Chainlink’s forthcoming onchain Oracle Directory complements this vision by offering a validated registry of price feeds that new Hubs can adopt out‑of‑the‑box. The diagram below outlines a reference flow for self‑service onboarding of Hubs, Spokes, and oracles, illustrating how a permissionless ecosystem could function while preserving risk isolation and transparent auditability.
Fuzzy‑controlled Interest Rates
Preliminary analysis was conducted and validated using fuzzy‑logic controllers to adjust borrow‑curve slopes and kink points in real time. This remains a research initiative for now and efforts are focused on validating the theoretical model and defining data‑feed requirements with Chainlink.
Vaults and Smart Accounts
We have conducted design‑level research on Smart Accounts that could host isolated collateral under a single address, segregating collateral and enabling delegated borrowing.
New Oracle Design
Aave Labs and Chainlink have held discovery sessions on a multi‑feed oracle framework that filters outliers and reacts to anomalies. The collaboration has produced a high‑level blueprint that needs further analysis.
Under Review Features
These items are under active research and, pending validation and governance approval, may be proposed for inclusion in future versions.
Automated Treasury Management
Reverse‑Dutch auctions would automatically convert reserve‑factor inflows into a predefined target asset (e.g., ETH or a stablecoin) once volume thresholds are met, streamlining treasury operations and reducing governance overhead. This remains a research‑only concept for now, with design parameters still under discussion.
Stronger GHO integration
Research is ongoing to embed GHO more deeply into V4. Ideas under consideration include settling soft liquidations directly in GHO, allowing native GHO minting against collateral, giving borrowers the option to pay stablecoin interest in GHO, and introducing an emergency redemption mechanism to support peg stability. All initiatives remain exploratory and are subject to further technical validation and governance approval.
By mid September, a roadmap post will detail the Aave V4 go to market strategy (security program, public testnet, DAO coordination, and related milestones), and outline the steps for the production launch of Aave V4, providing visibility and engaging the DAO and its service providers (SPs) to coordinate efforts.
Aave Labs