Aave v4 and Capital Efficiency

Aave v4 aims to address this structural inefficiency.

Written by: Vaidik Mandloi

Translation: Block unicorn

Preface

At first glance, DeFi lending appears vast in scale, but its underlying operations are inefficient. The same assets are dispersed across multiple pools, markets, and chains. As a result, a large amount of funds sit idle—not due to a lack of borrowers, but because of improper liquidity allocation.

This structure arises from the way DeFi protocols manage risk. Instead of charging different rates to borrowers based on risk levels, protocols opt to create independent markets.

While this structure improves security, it also brings some unintended consequences. Even with the same underlying asset, each market requires its own liquidity. ETH deposited in the Aave core market cannot be used to fund loans in other independent markets, even if those markets have higher demand. Over time, protocols end up with the same asset scattered across multiple pools, each only partially utilized.

Aave v4 aims to solve this structural inefficiency. It centralizes liquidity and moves risk management to the system's edges. Different types of lending still exist, but they no longer require separate pools. The idea is simple: to make more efficient use of existing liquidity while controlling risk.

Why DeFi Lending Became Inefficient

DeFi lending protocols manage risk by dividing users into different markets rather than charging different prices.

When a protocol wants to support assets with varying risk levels, it doesn't finely adjust interest rates or collateral costs; instead, it creates independent markets. Assets deemed safe are grouped into one market, while newer or riskier assets are placed in independent markets with lower limits. High-leverage strategies are pushed into special modes, such as E-Mode. E-Mode is designed for assets with highly correlated price movements, like stablecoins or highly liquid staked tokens. Since these assets are highly correlated, the protocol allows users to borrow more aggressively.

Each market has its own set of rules and, more importantly, its own liquidity. This makes the system easier to control. If a problem arises in one market, losses are confined to that market. But this also means that even if the underlying asset is the same, liquidity cannot be shared across different markets.

For example, ETH provided in the Aave core market can only be borrowed by users within that market. If lending demand increases in an independent market, the protocol cannot automatically reallocate idle ETH from the core market to meet that demand. Liquidity can only be redistributed by users manually moving funds.

As Aave expands to support various assets and blockchains, this pattern repeats. Each new risk category requires a new market, and each market needs its own liquidity. This disperses assets across multiple pools, with none fully utilized. Even though total deposits grow, the protocol's ability to efficiently deploy capital fails to keep pace.

This structure also impacts pricing. Since borrowers are grouped by market rather than charged based on risk level, users within the same market often pay similar rates regardless of their collateral's actual safety. Risk does exist, but it's expressed through access restrictions rather than pricing. Safer positions indirectly subsidize riskier ones—not by design, but as a consequence of these limitations.

This creates a large, rigid system.

Funds exist but are bound by market barriers. Supporting more assets or strategies requires more pools, higher liquidity, and more dispersed capital flows. This is exactly what Aave v4 aims to address.

Separating Liquidity and Risk

The core idea of Aave v4 is simple, but it requires a complete change in how DeFi lending is built. Liquidity and risk do not have to coexist.

In previous versions, markets performed two tasks simultaneously: maintaining liquidity and enforcing risk rules. Because these functions were tightly coupled, the only way to change risk was to split liquidity. This led directly to the fragmentation of markets. Aave v4 seeks to break this coupling.

In v4, liquidity on each chain is concentrated in a place called the "Liquidity Hub." This hub isn't a user-facing market; it doesn't decide who can borrow, how much they can borrow, or what collateral is allowed. Its job is to hold assets, track supply and borrowing balances, calculate interest, and ensure the system as a whole remains solvent.

All user interactions happen elsewhere.

Next, Aave v4 replaces the concept of "markets" with Spokes. A Spoke is not a liquidity pool, but a set of rules determining who can access liquidity, under what conditions, and with what risk limits. When users borrow, they don't borrow directly from the Spoke but instead borrow from the Hub through the Spoke.

Because Spokes do not hold liquidity, Aave v4 no longer needs to create new pools whenever a different type of risk needs support. All assets are consolidated into a single balance sheet. The difference between Spokes is not where funds are stored but how they are used.

In earlier versions of Aave, these two aspects were inseparable. A market defined both the risk assumptions and the pool of funds backing them. If the protocol needed stricter rules, higher leverage, or different collateral handling, it had to create an independent market with its own deposits. Over time, this led to fragmented liquidity. The only way to change risk was to split capital.

Aave v4 removes this restriction by separating accounting from access control. The Hub exists solely to hold assets, track positions, and ensure system-wide solvency. It does not decide what assets can be used as collateral, what leverage is allowed, or which oracle is trusted. All these decisions are made by the Spoke. A Spoke is not a traditional market— it does not contain liquidity itself but defines a lending environment. When users borrow through a Spoke, they draw from the same underlying asset pool as everyone else but must follow specific rules. These rules determine how collateral is valued, the maximum borrowable amount, and how quickly positions are liquidated if they become unsafe.

This structure allows the protocol to express vastly different risk preferences without repeatedly deploying new capital. One Spoke can simulate today's conservative core market. Another can set strict caps and parameters for riskier assets, or allow higher leverage for correlated assets, similar to E-Mode. All these configurations can coexist without requiring dedicated pools upfront.

The key to avoiding dangerous situations is that Spokes do not have unlimited access to liquidity. Each Spoke has explicit caps set by governance. These caps define the risk exposure a Spoke can create and which asset types it can interact with. If a Spoke starts accumulating more risk than expected, its cap can be lowered. If the risk becomes completely unacceptable, the Spoke can be disabled entirely without affecting other parts of the system or forcing users to move funds.

This is where real capital efficiency improvements occur. Liquidity is no longer reserved to cater to specific borrower types or strategies but is available for the entire system and allocated through rules rather than separate pools. The protocol can support more assets and strategies without continually splitting its balance sheet into smaller, less efficient parts.

How Aave v4 Prices Risk

Liquidity sharing can only work if the protocol can distinguish between safe and unsafe participants. In earlier versions, this distinction was mainly structural. If you wanted safer lending, you went to a safer market. If you wanted higher leverage or riskier collateral, you were assigned to another pool. Price differences existed but were crude and only applied at the market level.

Aave v4 moves risk differentiation closer to the borrower level.

In v4, asset rates are still based on a benchmark rate determined by supply and demand at the Hub. What changes is the risk premium above the benchmark. Borrowers are no longer seen as interchangeable simply because they borrow the same asset. Borrowing costs now depend on the manner in which loans are collateralized.

When users borrow via a Spoke, the protocol assesses the risk of the position based on collateral, leverage, and the Spoke’s rules. If a position is deemed riskier, an extra fee called a risk premium is charged. Safer positions pay a risk premium close to the benchmark rate, while riskier positions pay a higher premium. Spokes play a subtle but important role: they not only control access to liquidity but also define how risk premiums are calculated and applied. Conservative Spokes may charge little or no premium since their allowed positions are already tightly restricted. Spokes that allow riskier collateral or higher leverage collect higher premiums to compensate the system for the additional risk.

These premiums flow back into the shared liquidity pool. Thus, liquidity providers are compensated not just for liquidity usage but also for the level of risk the system takes on. Capital is rewarded for supporting riskier activity, provided those risks are clearly priced.

Over time, this creates a feedback loop: if a certain type of lending risk becomes too high, its cost rises; if demand shifts to safer configurations, prices adjust accordingly. The protocol no longer needs to create new markets to reflect these differences—they are instead reflected directly in the interest rate. The result is a system closer to credit markets, where a borrower's value depends on their behavior and collateral, not just the market they enter. Liquidity is shared, but risk is no longer averaged.

Unified Accounting and Liquidation

Once liquidity is shared, the most obvious concern is about failure modes. If everyone borrows from the same balance sheet, what happens if something goes wrong? In earlier designs, fragmentation offered a crude form of protection. Since markets were isolated, losses were contained. The concern with unified liquidity is that risk could spread further.

Aave v4 addresses this by changing how the protocol accounts for positions and enforces solvency.

In v3, each market essentially maintained its own books. Solvency was assessed locally. Liquidations were triggered within pools, and losses were absorbed by that pool’s liquidity. This made markets easier to understand but meant the protocol lacked a global view of system-wide risk accumulation.

In v4, accounting moves to the Hub. The Hub maintains a unified view of assets, liabilities, and accrued interest across the entire protocol. Every loan, regardless of its Spoke of origin, is recorded on the same balance sheet. This enables the protocol to assess solvency globally rather than market by market. It always knows the total amount of liquid funds, outstanding debt, and remaining buffers.

When users open a position through a Spoke, that position is still subject to global solvency rules enforced by the Hub. If the position becomes unsafe, liquidation logic is triggered according to the rules defined by the Spoke, but settlement still uses the same underlying liquidity. Spokes define when and how liquidation occurs. The Hub ensures liquidation restores system solvency.

Every Spoke has explicit risk exposure limits. These are designed to control the risk each Spoke can pose to the system. Even if all positions in a Spoke fail simultaneously, the maximum loss is capped. Losses cannot exceed the acceptable range set by governance for that Spoke. Other Spokes can continue running normally because their access to liquidity is unaffected.

This is a different failure model than before. In v4, losses are isolated not by segregating liquidity, but by capping risk exposure.

The liquidation process also becomes more predictable. With unified accounting, liquidators interact with a single source of liquidity. There’s no need to move assets between markets or rebalance pools during liquidations. The system doesn’t rely on users transferring funds under stress but on preset caps and consistent accounting.

This reduces the risk of cascading liquidations triggered by a lack of liquidity in a specific pool. In fragmented designs, a pool could go bankrupt not because the system lacks funds but because capital has flowed elsewhere. In v4, liquidity shortfall is a global signal. Unified accounting makes risk visible and manageable. The protocol always knows where losses might occur, how large they could be, and which part of the system is responsible. This clarity enables liquidity sharing without turning stress events into protocol-wide failures.

Long-term Unlock

Aave v4 is not just a cleaner lending system. It also changes the speed and safety at which new forms of risk can be introduced into DeFi.

In earlier versions, supporting something new always meant taking on structural risk. Whether listing a new asset, trying a new collateral type, or admitting a certain group of borrowers, each required launching a new market with its own liquidity. Governance decisions were difficult because they affected capital allocation; each experiment came at the cost of further market fragmentation.

In v4, experimentation becomes easier because liquidity no longer needs to move.

New Spokes can be introduced without users depositing funds into new pools. Governance can define rules, caps, and pricing for specific use cases while maintaining the integrity of the balance sheet. If an experiment succeeds, the cap can be raised. If it fails, the Spoke can be capped or closed without touching other parts of the system.

Instead of debating whether an asset is "worthy" of a full market, new assets and strategies can be treated as limited risk exposures. The question shifts from "should we create a market" to "how much risk are we willing to allocate." This is a more precise decision and can be adjusted incrementally. This is especially important for real-world assets (RWA) and institutional applications.

RWAs often come with limitations that cannot be fully integrated into existing markets, such as permissioning, legal wrappers, slower liquidation, or non-standard collateral behavior. In earlier designs, accommodating these differences meant either sacrificing the core market or fully isolating liquidity. In v4, these limitations can exist within a Spoke, with strict limits and custom rules, while still leveraging shared liquidity.

In earlier versions, changing risk assumptions usually required migrating markets or coordinating liquidity adjustments. In v4, governance operates at the cap and rule level. Adjustments can be made incrementally; risk can be increased or decreased step by step without forcing users to act. This lowers governance costs and reduces the expense of errors.

Over time, this will lead to a different growth pattern for the Aave protocol.

Aave will no longer scale by launching more markets and attracting isolated liquidity, but by increasing the uses of its balance sheet. Since liquidity no longer needs to be pre-allocated to specific markets and left idle when demand shifts elsewhere, capital efficiency is improved.

The end result is a DeFi protocol that is more like a financial system.