The Evolution of Aave: V2, V3, and V4

Aave keeps getting better with every version: V2 laid the groundwork, V3 improved risk control, and V4 increases capital efficiency while unifying liquidity. We will look at Aave’s evolution in this article, but mainly focus on V4’s design. Readers should be familiar with lending protocols and how they work.

How Aave Works

At its core, Aave is a lending protocol where suppliers deposit assets into liquidity pools and receive aTokens in return, which represent their deposited balance and accrue interest over time. Borrowers take loans from those pools by depositing collateral worth more than the amount they borrow (overcollateralization). Each borrower has a health factor — a ratio that represents how safe their position is, calculated from their collateral value relative to their debt. A health factor above 1 means the position is sufficiently collateralized; when it falls below 1, the protocol allows liquidators to repay part of the debt in exchange for a discounted portion of the collateral — this mechanism keeps the system solvent.

Interest rates are not fixed; they are determined by the utilization of each pool. When a pool has plenty of available liquidity, borrowing is cheaper. As utilization rises and available liquidity decreases, rates increase sharply to incentivize repayments and attract new deposits. This dynamic model helps maintain balance between supply and demand while protecting the protocol from excessive risk.

Aave is governed by its community through on-chain governance. AAVE token holders vote on protocol changes — from adding new assets and adjusting risk parameters to deploying new markets. This means that many of the risk settings and parameters discussed throughout this article — such as asset listings, LTV ratios, and supply caps — are not hardcoded; they can be adjusted by governance over time as market conditions evolve.

V2

V2 was a solid foundation. It was a major upgrade that made the protocol more flexible, efficient, and user-friendly. It improved capital efficiency and gave users more control over their collateral and debt management.

The key theme across V2’s features is reducing the number of steps users need to manage their positions, while opening up new possibilities through flash loans and delegation.

• Collateral Swap: Users can swap their collateral without withdrawing it. If the collateral becomes risky, it can be exchanged for another asset (e.g., a stablecoin) in a single transaction. This helps reduce liquidation risk.
• Repay With Collateral: Users can repay their debt directly with their collateral in a single transaction, rather than withdrawing, swapping, and repaying in multiple steps. This saves time and gas.
• Debt Tokenization: V2 represents each borrower’s debt as non-transferable on-chain tokens that automatically reflect accrued interest over time.
• Stable/Variable Rates: Borrowers can hold both stable and variable-rate debt for the same asset from the same wallet, giving them more control over their borrowing strategy. They can also switch between stable and variable rates at any time, depending on market conditions.
• Batch Flash Loans: V2 allows borrowing multiple assets in a single Flash Loan, enabling more complex DeFi strategies.
• Flash Liquidations: Previously, a liquidator needed their own capital to repay a borrower’s debt and earn the liquidation bonus. With flash loans, Aave V2 allows liquidators to use the protocol’s own liquidity to perform liquidations without needing upfront capital.
• Native Credit Delegation: Users can delegate their borrowing power to someone else. The delegatee borrows without collateral, while the delegator earns additional yield but takes the risk.

V3

V3 builds on V2’s foundation with a strong focus on risk isolation and smarter capital efficiency. Treating blue-chip and long-tail assets the same way is not feasible given their different risk profiles. Because V2 applied uniform risk parameters to all assets in a shared pool, adding volatile or illiquid tokens would expose the entire pool — including blue-chip deposits — to their downside risk. This limited the range of assets the protocol could safely list. V3 addresses this with its new features. It also deprecated stable-rate borrowing, leaving variable rates as the only borrowing mode.

• Isolation Mode: For protocol health and protecting the protocol from a crash, new or more volatile assets can’t be added directly. Isolation mode enables long-tail assets to be supported without systemic risk to the entire protocol. When users use an asset that is listed in Isolation Mode, they can only borrow specific assets (commonly stablecoins because their price won’t fluctuate as other assets), restricted by the protocol, and they can’t use any other asset as collateral alongside that isolated asset. Each isolated asset also has a debt ceiling — a cap on the total amount that can be borrowed against it — limiting the protocol’s exposure if that asset’s price collapses.

https://aave.com/docs/aave-v3/overview

• Siloed Borrowing: While Isolation Mode restricts what can be borrowed against risky collateral, Siloed Borrowing restricts what happens when a user borrows a risky asset itself. When a user borrows an asset that is marked as siloed, they cannot borrow any other asset in the same position — their borrowing is “siloed” to that single risky token. However, they are free to use any collateral they choose, and there is no debt ceiling. This mechanism isolates the risk of volatile or potentially manipulable assets on the borrowing side rather than the collateral side.
  The distinction is important: Isolation Mode protects the protocol from risky collateral, while Siloed Borrowing protects it from risky borrowed assets. Together, they give V3 a layered risk framework.
• Efficiency Mode (E-mode): While the features above restrict riskier assets, E-Mode does the opposite for correlated assets — it loosens parameters to improve capital efficiency. When assets are correlated in price (for example, different stablecoins like USDC and DAI, or different wrapped versions of ETH), the risk of one crashing relative to the other is low. E-Mode takes advantage of this by grouping correlated assets into categories and offering users who supply and borrow within the same category a significantly higher loan-to-value (LTV) ratio than standard mode. This means users can borrow more against their collateral and face fewer unnecessary liquidations from small price fluctuations between correlated assets.

Due to strong risk management, V3 also has supply and borrowing caps for assets. A supply cap limits the total amount that can be deposited, reducing overexposure. A borrow cap limits the total amount that can be borrowed, preventing a single asset from draining liquidity or creating outsized insolvency risk.

While these mechanisms operate at the asset and position level, V3 also has structural risk separation at the market level. For example, the Core market is Aave’s main general-purpose pool, but it prioritizes safety and stability — not every asset or strategy belongs there. Listing a new asset on Core means exposing the entire pool’s liquidity to that asset’s risk profile, so governance is naturally conservative about what gets in.

This is where separate market instances come in. V3’s architecture allows governance to deploy independent markets on the same network, each with its own liquidity pool, asset list, and risk parameters tailored to a specific use case. A market built around leveraged staking strategies, for example, can offer LTVs far more aggressive than Core would allow, because its entire risk model is designed around highly correlated assets. For suppliers, these specialized markets can offer more attractive yields because they serve concentrated, high-demand borrowing activity. For borrowers, they provide access to higher leverage and parameters that wouldn’t be possible in a general-purpose pool.

V4

Before we look at the V4’s design, let’s think about why it is needed.

Despite V3’s design, a problem persisted: liquidity fragmentation. In V3, to isolate risk, liquidity was fragmenting; it operates through separate markets on different networks. Each market — such as Core or Prime on Ethereum — has its own liquidity pool and set of supported assets; each one has a unique risk profile. When users deposit assets, they do so into a specific market; other markets can’t access that liquidity. As a result, funds supplied to one market can only be borrowed within that same market and are not shared across others.

This structural separation creates a “bootstrapping” problem: to try new things or add new assets, a new market is needed, since the core market should not take those risks. And those new markets are competing with the core market, which brings significant challenges for them.

This creates a chicken-and-egg problem: Users won’t supply their assets if liquidity is insufficient, and liquidity will be insufficient if users don’t supply their assets; thus, other users won’t be able to borrow. Also, low liquidity carries its own risks, such as sudden interest rate spikes, and can cause a market to fail to survive, even if it has potential. Because of this design, liquidity wasn’t used efficiently and was fragmented between markets. Markets compete with each other for the same users and deposits.

Users also have to compare different markets to determine where their deposits will earn higher yields, since rates vary based on each market’s liquidity and risk profile. This makes the experience more complex for end users, who must actively monitor conditions and move capital accordingly, often leading to inefficient allocation.

V3 separated liquidity to isolate risk, and V4 isolates risk while unifying liquidity. It achieves this through three core elements: Liquidity Hubs, Spokes, and Risk Premiums. Now we can look at V4’s design.

Liquidity Hubs

V4 unifying liquidity through Liquidity Hubs. They are the liquidity source for Aave v4, and liquidity will be collected here rather than split across markets. Each L1/L2 will have at least one Hub, with the potential for multiple Hubs if governance requires distinct risk envelopes.

The Hub is responsible for system-wide accounting and enforces global invariants — for example, total borrows can never exceed total supply, and which Spokes are authorized to access which assets. It controls Spoke access through credit lines (how much a Spoke can borrow) and debit lines (how much it can add), defined by governance and adjustable based on Spoke performance and risk. This way, no single Spoke can drain more liquidity than the system allows.

Because liquidity is no longer fragmented, utilization improves — the same assets serve borrowing demand from multiple Spokes simultaneously, unlocking better rates for both suppliers and borrowers. From a supplier’s perspective, deposits go into the Hub’s shared pool rather than a specific market. This means suppliers are no longer forced to choose between markets or monitor which one offers the best yield. Their liquidity is automatically available to all authorized Spokes, and their returns reflect the aggregate borrowing demand across the system — weighted by the risk premiums each borrower pays.

From a supplier’s perspective, deposits go into the Hub’s shared pool rather than a specific market. This means suppliers are no longer forced to choose between markets or monitor which one offers the best yield. Their liquidity is automatically available to all authorized Spokes, and their returns reflect the aggregate borrowing demand across the system — weighted by the risk premiums each borrower pays.

Spokes

Users won’t be able to interact directly with Hubs. They will interact with the Spokes, and Spokes will interact with the Hubs. Users will withdraw or supply to the Spokes.

https://aave.com/blog/understanding-aave-v4s-architecture

Spokes operate with their own local controls, including caps, emergency stops, accountings, and customizable risk parameters tailored to specific use cases. While they can optimize these settings independently, their access to shared liquidity is still governed by the Hub. This ensures flexibility at the Spoke level without compromising system-wide stability. They are modular; they don’t affect each other when added or removed.

V4 can support V3’s functionality and risk management. Isolation Mode and E-mode can be implemented in a Spoke while accessing the Hub’s liquidity, with the necessary limits, of course.

Each Spoke will make the entire system more efficient. Liquidity is better utilized across multiple use cases, while users access specialized features without fragmenting assets to the isolated markets. Instead of starting from scratch each time, innovation builds on proven infrastructure. Each successful Spoke makes the platform more attractive to future builders, creating positive feedback loops rather than zero-sum competition.

Risk Premiums

In V3, borrow rates were determined by the supply and demand; fixed for the borrowed asset. The rate was the same regardless of what collateral backed the position:

https://aave.com/blog/aave-v4-risk-premiums

V4 changes this: the borrowing rate no longer depends solely on supply and demand. With User Risk Premiums, users pay a borrowing rate based on the quality of their collateral; everyone pays their risk. No one subsidizes riskier borrowers.

https://aave.com/blog/aave-v4-risk-premiums

Assets now have a Collateral Risk score: low for blue-chip assets like ETH and higher for more volatile, long-tail assets. If someone has risky collateral, then they will pay a higher rate than those who use a blue-chip asset as collateral. The Hub sets a base rate based on supply and demand, like V3, but users pay an extra rate if their collateral’s quality is low. Their borrowing cost reflects the actual risk of their collateral, so each user pays for the risk they bring to the system.

This encourages users to provide higher-quality collateral, thereby improving overall system stability. Instead of covering the risk of weaker positions, users with ETH or other top-tier assets get better rates. At the same time, suppliers earn returns that match the risk of the collateral behind each loan, making the system more balanced for both borrowers and suppliers.

Risk Premiums operate at three levels.

Asset Liquidity Premiums are the foundation. When an asset is added to the protocol, it is given a risk score based on its quality and liquidity. The safest assets receive very low scores (for example, 0%), while more volatile or less liquid assets receive higher ones (for example, 200% or more). For instance, ETH may have a 0% risk score, whereas a newer token could carry a significantly higher premium. Governance can revise these scores over time as market conditions evolve.

User Risk Premiums reflect a user’s overall collateral quality. When a user uses multiple assets as collateral, the protocol calculates a weighted average based on each asset’s value and risk score. A user who supplies both a low-risk and a higher-risk asset will have a User Risk Premium that falls between the two asset premiums, with greater weight given to the asset that represents a larger share of their collateral.

Spoke Risk Premiums capture the average risk within a Spoke. Since different Spokes can serve different use cases and user profiles, each Spoke maintains its own aggregate risk level. This allows borrowing rates to account not only for individual risk, but also for the broader risk environment of the Spoke.

As a result, borrowing costs reflect actual risk at the asset, user, and Spoke level.

Importantly, existing positions are not affected by changes to risk parameters — users remain under their previous configuration unless they take on additional risk (e.g., by borrowing more, withdrawing collateral, or disabling collateral). This lets governance change risk settings and introduce new reserve rules only for new positions, while existing positions keep their original parameters, avoiding unnecessary liquidations for existing users.

Liquidation In V4

In V3, when a borrower’s health factor falls below 1, a liquidator can repay part of the borrower’s debt and receive a portion of the collateral plus a fixed liquidation bonus. The amount that can be repaid is controlled by a fixed close factor, usually 50%, but which can reach 100% when the health factor drops very low.

While this mechanism is simple and protects the protocol from bad debt, it has limitations: the fixed close factor can cause over-liquidation even when a small repayment would restore solvency, and the static liquidation bonus does not reflect how risky a position is, giving liquidators the same incentive regardless of how far underwater the position has fallen.

V4 changes this liquidation mechanism with new dynamic parameters. Instead of a fixed close factor that can liquidate half or all of the collateral, it uses a target health factor that repays only enough debt to restore the position to a target health factor set at the Spoke level, which prevents over-liquidation.

https://aave.com/blog/aave-v4-liquidations

V4 uses a variable liquidation bonus rather than a fixed one. The liquidation bonus scales with the risk of the position: the lower the health factor falls, the higher the bonus; the closer a position is to the liquidation threshold, the lower the bonus. It encourages liquidators to close risky positions.

https://aave.com/blog/aave-v4-liquidations

V4 also takes a different approach to dealing with dust debt (very small remaining debt amounts that are inefficient to keep open because liquidation is uneconomical). If, after a liquidation, the remaining debt or collateral would fall below the DUST_LIQUIDATION_THRESHOLD , the liquidator must fully clear the position. This prevents the accumulation of small leftover balances.

Conclusion

Aave’s evolution from V2 to V4 reflects a clear architectural shift. V2 expanded usability and flexibility. V3 strengthened risk isolation to safely support a broader range of assets. V4 takes the next step by separating risk management from liquidity fragmentation — isolating risk at the Spoke level while unifying capital at the Hub level.

By introducing shared liquidity, more precise risk pricing, and dynamic liquidation mechanics, V4 aims to create a more scalable and capital-efficient lending architecture. Instead of forcing innovation into isolated markets that compete for liquidity, V4 enables specialized environments to build on a common liquidity base. Thus, the protocol can expand without sacrificing safety — aligning incentives across suppliers and borrowers.

The following sources were helpful in preparing this article:

• Understanding Aave V4's Architecture
• Aave V4 Risk Premiums
• Aave V4 and the Unified Liquidity Thesis
• How V4 Turns Aave Into DeFi's Operating System
• How Aave V4 Handles Risk Isolation Without Fragmenting Liquidity
• Aave V4's New Liquidation Engine
• The Aave Protocol V2
• Aave v4 Overview
• Aave V3 Overview

---

The Evolution of Aave: V2, V3, and V4 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.