Aave V4: From Fragmented Markets to Modular Liquidity

CN
6 hours ago

Written by: Tia, Techub News

In the DeFi lending space, Aave has always been a beacon of innovation and industry standards. As the user base and asset types have grown, Aave V3 has gradually revealed issues such as liquidity fragmentation, relatively crude risk management, and liquidation mechanisms. To address these challenges, Aave V4 has undergone a systematic upgrade: the liquidity organization method has been redesigned into a unified Hub and modular Spoke architecture, achieving multi-asset and multi-strategy shared liquidity while maintaining risk isolation; the accounting system has been upgraded to an ERC-4626 style share model, making the global liquidity status clear and controllable; the liquidation mechanism has shifted from a fixed ratio model to a dynamic, minimally necessary liquidation logic centered around health factors. Overall, V4 is not merely an optimization of parameters but a collaborative evolution of architecture and mechanisms, upgrading Aave from a fragmented lending protocol across multiple markets to a more scalable, capital-efficient, and risk-controllable modular infrastructure.

From Market-Centric V3 to the Reality of Liquidity Fragmentation

In Aave V3, the protocol adopted a market-centric deployment approach. Across different networks, and even within the same network, Aave delineates multiple independent markets, such as Core and Prime on the Ethereum mainnet. Each market has completely independent liquidity pools, supported asset combinations, and corresponding risk parameters, thus forming distinct risk profiles.

When users supply assets to Aave V3, they are effectively depositing assets into a specific market rather than entering a globally 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 risk isolation, as risks do not transmit between different markets, but the cost is equally evident: liquidity is fragmented. Even the same asset can be dispersed across multiple markets, making unified scheduling difficult, which in turn affects overall capital utilization efficiency, market depth, and the ability to expand new functionalities.

Hub and Spoke: The Liquidity Restructuring Logic of Aave V4

Aave V4's response to this issue is a fundamental restructuring of the underlying architecture, introducing a new architecture known as Hub and Spoke. The starting point of this design is to address the long-standing issues of liquidity fragmentation and limited scalability in V3.

In V4, the protocol no longer binds liquidity to a single market but introduces a unified liquidity Hub on each network as the central source of all funds. The assets supplied by users no longer enter a specific market but are uniformly deposited into the corresponding Hub of that network, which is responsible for global liquidity management and core accounting constraints, such as ensuring that the total amount of assets borrowed within the system does not exceed the supplied scale and recording the liquidity usage of different modules.

However, the Hub is not the object of direct interaction for users. All user-perceptible operational entry points are placed in a highly modular functional unit, referred to as Spoke in V4.

Spoke: A Modular Entry Point with Localized Risk

Spokes constitute the front-end layer of the Aave V4 protocol that users actually interact with. Each Spoke connects to the same liquidity Hub but can have completely different rules, parameters, and risk assumptions. Spokes locally manage user positions, collateral structures, oracle access, and liquidation logic, while the Hub only provides liquidity support within restricted limits in the background.

The core significance of this division of labor is that risk is strictly confined within the Spoke and does not spread at the system level. Different types of assets and borrowing demands with varying behavior patterns are no longer forced to share the same set of risk parameters but can achieve risk logic separation while sharing liquidity.

Because of this, many functions that existed in V3 but were relatively cumbersome to implement can be realized in a more natural form in V4. For example, E-Mode is no longer just a set of parameter configurations but can exist as an independent Spoke, specifically serving highly correlated asset combinations; isolation modes can also be implemented through dedicated Spokes, with the Hub setting clear limits on their available liquidity. For RWA or more complex collateral structures, V4 also allows for the introduction of stricter access controls and risk rules through customized Spokes without spreading this complexity throughout the entire protocol.

How Does V4 Account for Unified Liquidity?

To support the unified liquidity at the Hub level, V4 has abandoned the aToken rebase in its accounting model, shifting to an ERC-4626 style share system.

In Aave V4, the protocol has discarded the previous aToken re-basing mechanism in favor of an ERC-4626 style share accounting system. This means that users no longer hold aTokens that automatically increase in quantity with interest accumulation but hold a fixed number of shares, with the underlying asset value corresponding to each share increasing over time. In other words, interest is no longer reflected through changes in token quantity but through changes in the amount of assets that can be redeemed for each share, which is closer to the accounting logic of traditional vaults.

This share model is closely related to V4's unified liquidity design. Under the V4 architecture, all supplied assets converge into the on-chain liquidity Hub, which uses the share system to accurately record the global asset status. The Hub does not need to focus on the specific lending strategies or risk patterns of each Spoke but only needs to manage the total asset scale, total number of shares, and the limits already occupied by each Spoke. This design allows the same asset pool to be shared by multiple Spokes while maintaining clarity and control in accounting, avoiding the complexity and risk spillover that may arise from traditional aToken rebase in a multi-module environment.

If the aToken rebase mechanism were to continue, different Spokes sharing the same asset would face issues such as exponential synchronization difficulties, interest and risk spillover, and challenges in precisely controlling sub-module limits. The ERC-4626 style share model transforms these potential issues into simple arithmetic relationships, allowing the Hub to safely and controllably support various lending strategies and risk configurations under the premise of unified liquidity. This not only ensures capital efficiency but also provides a foundation for the modularity and future expansion of the V4 architecture.

Refinement of the Liquidation Mechanism: Breaking Free from Fixed Ratio Liquidation

In addition to the restructuring of the liquidity framework, Aave V4 has also made significant adjustments to the liquidation mechanism. Unlike the previous fixed ratio-centric liquidation logic, V4 introduces a risk-targeted liquidation engine.

In V3 and earlier versions, once a user's position's health factor falls below a safe threshold, the protocol allows liquidators to repay a certain proportion of the debt according to a preset close factor and correspondingly seize collateral. This method is effective in protecting the protocol's safety, but in cases of high volatility or at the risk edge, it often leads to excessive liquidation, where the scale of liquidation significantly exceeds what is necessary to restore the position's safety.

The new liquidation engine in V4 shifts the focus from "liquidation ratio" to "safety target." When a position enters a liquidatable state, the system calculates how much debt needs to be repaid and how much collateral needs to be disposed of to restore the health factor to a safe range. Liquidation no longer aims to maximize risk removal but seeks to minimize necessary liquidation, aiming to reduce the erosion of user assets as much as possible without sacrificing the protocol's safety.

This change means that the close factor evolves from a static parameter to a result dynamically determined by the position's risk status. The scale of liquidation will vary with asset volatility, collateral structure, and risk parameters, making the liquidation mechanism more accurately reflect the risk differences between different positions and helping to reduce liquidation shocks and unnecessary asset sell-offs.

The update to Aave's liquidation mechanism easily brings to mind Fluid's liquidation design. From the perspective of the lending product itself, Aave V4 has indeed significantly improved the previously "one-size-fits-all" liquidation approach, making the liquidation logic more refined and closer to actual risk.

However, compared to Fluid, which deeply integrates lending with DEX liquidity, Aave still operates within a different design paradigm. Fluid allows for some risks to be automatically absorbed within the pool by directly embedding lending positions into trading liquidity, thus often completing position adjustments without the need for external liquidators. This design has clear advantages in cost structure and execution efficiency, while Aave, which relies on external third-party liquidators, may find it challenging to fully align in this dimension, even with refined liquidation logic.

Conclusion

Overall, Aave V4 is not a complete overthrow of the existing model but a relatively restrained yet systematic evolutionary path: by restructuring liquidity through the Hub and Spoke architecture, achieving localized risk through modular Spokes, and complemented by a more refined liquidation engine, Aave is evolving from a lending protocol expanding on a "market" basis to a modular lending infrastructure capable of supporting more complex financial structures.

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink