As the competition in DeFi lending enters a more refined stage, Aave has once again chosen to approach the problem from a fundamental restructuring perspective, rather than simply adjusting parameters. In response to the issues of liquidity dispersion and清算 efficiency that became apparent during the V3 phase, Aave V4 introduces a new architecture called Hub+Spoke, which enables multi-asset liquidity management. Additionally, clearer accounting methods for shares and dynamic清算 mechanisms are implemented, allowing both risk control and capital efficiency to be improved simultaneously. This upgrade marks Aave’s transition from a single lending market to a scalable and composable DeFi lending infrastructure.

From the “market-centered” approach of V3, we are now facing the reality of fragmented liquidity
In Aave V3, the protocol operates on a “market-centric” model. Across different networks, or even within the same network, Aave creates multiple independent markets, such as Core and Prime in the Ethereum mainnet. Each market has its own independent liquidity pool, supported assets, and corresponding risk parameters, resulting in distinct risk profiles.
When users supply assets to Aave V3, they are effectively depositing those assets into a specific market, rather than creating a global shared fund pool. This means that assets supplied to the Ethereum Core market can only be used by borrowers within that market, and cannot be accessed by users from the Prime market or other networks.
This design has clear advantages in terms of risk isolation. Risks between different markets are not transmitted to each other. However, the cost is also evident: liquidity is fragmented into multiple markets, making it difficult to manage resources effectively. This affects overall capital utilization efficiency, market depth, and the ability to introduce new features.
Hub and Spoke: Aave V4’s approach to liquidity management
Aave V4 addresses this issue by fundamentally rethinking the underlying architecture. A new architecture called “Hub and Spoke” is introduced. The purpose of this design is to solve the problems of liquidity fragmentation and limited scalability that existed in V3.
In V4, liquidity is no longer confined to a single market. Instead, a unified liquidity hub is created on each network, serving as the central source of all funds. Assets provided by users are not allocated to a specific market but are deposited directly into the corresponding hub. The hub is responsible for managing liquidity globally and enforcing core accounting rules, such as ensuring that the total amount of assets lent within the system does not exceed the available supply, and recording how each module utilizes liquidity.
But the hub is not an object that users interact with directly. All user-facing interfaces are located within highly modular functional units, which are referred to as “Spokes” in V4.
Spoke: A modular interface for localizing risks
Spokes constitute the front-end layer of the protocol that users interact with in Aave V4. Each Spoke is connected to the same liquidity hub, but it can have completely different rules, parameters, and risk assumptions. Spokes manage users’ positions, collateral structures, access to stateful devices, and settlement logic locally, while the hub provides limited liquidity support to them behind the scenes.
The key advantage of this division of responsibilities is that risks are strictly confined within Spokes, preventing them from spreading across the entire system. Different types of assets and lending behaviors no longer require sharing the same risk parameters. Instead, risks can be managed independently, while still benefiting from shared liquidity.
This means that many features that existed in V3 but were relatively complex to implement can now be implemented more naturally in V4. For example, E-Mode can no longer be just a set of parameter configurations—it can exist as an independent Spoke, dedicated to managing highly related asset portfolios. Isolation mode can also be implemented through a dedicated Spoke, with the hub setting clear limits on the liquidity available to it. For RWA or more complex collateral structures, V4 allows for stricter access control and risk regulations to be applied through customized Spokes, without having to spread this complexity throughout the entire protocol.
How does V4 handle the accounting of unified liquidity?
To support unified liquidity at the hub level, V4 abandons the aToken rebase mechanism in its accounting model, switching to an ERC-4626-style share-based system.
在Aave V4中,协议摒弃了以往aToken的重新基准机制,转而采用ERC-4626风格的份额会计制度。这意味着用户不再持有会随着利息累积自动增加数量的aToken,而是持有固定数量的份额(shares),每一份份额对应的底层资产价值会随时间增长。换句话说,利息不再通过代币数量的变化体现,而是通过每份份额可以兑换的资产数量变化呈现,这种方式更接近传统金库(vault)的会计逻辑。
这种份额模型与V4的统一流动性设计紧密相关。在V4架构下,所有供应资产都汇集到链上的流动性Hub,而Hub使用份额系统精确记录全局资产状态。Hub不需要关注每一个Spoke的具体借贷策略或风险模式,只需管理总资产规模、总份额数量以及各Spoke已占用的额度。这种设计使得同一个资产池可以被多个Spoke共享,同时在会计上保持清晰、可控,避免了传统aToken rebase在多模块环境下可能出现的复杂性和风险外溢。
If we continue to use aToken’s rebase mechanism, different Spokes will face difficulties in synchronizing assets, issues related to interest rates and risks, as well as challenges in accurately controlling the limits for sub-modules. The ERC-4626-style share model transforms these potential problems into simple arithmetic relationships, allowing the Hub to support various lending strategies and risk configurations safely and effectively, within the framework of unified liquidity. This not only ensures capital efficiency but also provides a foundation for the modularization of the V4 architecture and future expansion.
Fine-tuning of the settlement mechanism: moving away from fixed-rate settlements
In addition to restructuring the liquidity structure, Aave V4 also made significant adjustments to the settlement mechanism. Unlike the previous settlement logic, which relied on fixed ratios, V4 introduces a settlement engine that is based on risk objectives.
In versions prior to V3, if a user’s position’s health factor dropped below the safety threshold, the protocol allowed settlers to repay a certain percentage of the debt using a preset close factor, while confiscating the collateral accordingly. This approach was effective in protecting the protocol’s security, but in situations of high volatility or near-risk conditions, it often led to excessive settlements, meaning that the amount of collateral required to restore the user’s position was significantly larger than necessary.
The new settlement engine in V4 will focus on “security targets” rather than “settlement ratios”. When positions become eligible for settlement, the system will calculate how much debt needs to be repaid and how much collateral needs to be disposed of in order to restore the health factor to a safe level. Settlement is no longer aimed at maximizing risk mitigation; instead, it seeks to minimize the necessary amount of settlement. This approach aims to minimize the impact on users’ assets while maintaining the security of the agreement.
This change means that the “close factor” becomes a dynamic parameter determined by the risk status of individual positions. The size of settlements will vary depending on asset volatility, collateral structure, and risk parameters. This makes the settlement mechanism more reflective of the risk differences between different positions, thereby reducing settlement impacts and unnecessary asset sales.
The update to Aave’s settlement mechanism reminds us of Fluid’s settlement design. In terms of lending products themselves, Aave V4 has indeed improved the previously rigid settlement methods, making the settlement logic more precise and closer to actual risks.
However, compared to Fluid, which integrates lending with DEX liquidity, Aave still operates under a different design paradigm. Fluid allows lending positions to be directly integrated into trading liquidity, enabling some risks to be automatically absorbed within the pool. This means that in many cases, external mediators are not required for position adjustments. This design offers significant advantages in terms of cost structure and execution efficiency. Even though Aave uses sophisticated settlement logic, it still struggles to match Fluid in this regard.
Conclusion
整体来看,Aave V4并不是对现有模型的推翻,而是一条相对克制但系统性的进化路径:通过Hub and Spoke架构重组流动性,通过模块化Spoke实现风险局部化,再辅以更精细的清算引擎,Aave正在从一个以「市场」为单位扩展的借贷协议,演变为一个可承载更复杂金融结构的模块化借贷基础设施。

Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
AAVE