In the DeFi lending space, Aave has long been a benchmark for innovation and industry standards. As user numbers and asset types grow, Aave V3 has gradually revealed issues such as liquidity fragmentation, risk management, and rough liquidation mechanisms. To address these challenges, Aave V4 has undergone a systematic upgrade: liquidity organization has been redesigned into a unified Hub and modular Spoke architecture, enabling multi-asset and multi-strategy sharing of liquidity while maintaining risk isolation; the accounting system has been upgraded to an ERC-4626-style share model, making the overall liquidity state clear and controllable; the liquidation mechanism has shifted from a fixed ratio model to a dynamic, health factor-centric logic that performs minimal necessary liquidations. Overall, V4 is not just a parameter optimization but a co-evolution of architecture and mechanisms, transforming Aave from a fragmented multi-market lending protocol into a more scalable, capital-efficient, and risk-controlled modular infrastructure.
From “Market”-Centered V3 to the Reality of Liquidity Fragmentation
In Aave V3, the protocol employs a deployment method centered around “markets.” In different networks, or even within the same network, Aave divides into multiple independent markets, such as Core and Prime on the Ethereum mainnet. Each market has its own independent liquidity pools, supported asset combinations, and corresponding risk parameters, forming distinct risk profiles.
When users supply assets to Aave V3, they are explicitly depositing into a specific market, rather than into a global shared pool. This means assets supplied to the Ethereum Core market can only be used by borrowers within that market, and cannot be accessed by Prime market users or users on other networks.
This design offers clear advantages in risk isolation—risks do not propagate between markets. However, the cost is also evident: liquidity is cut into pieces. Even the same asset is split across multiple markets, making it difficult to manage centrally, which impacts overall capital utilization, market depth, and the ability to implement new features.
Hub and Spoke: Liquidity Restructuring Logic in Aave V4
Aave V4’s response to this problem is a fundamental restructuring of the underlying architecture, introducing a new Hub and Spoke framework. The goal of this design is to solve the long-standing issues of liquidity fragmentation and limited scalability seen in V3.
In V4, liquidity is no longer bound within a single market. Instead, each network introduces a unified Liquidity Hub, which acts as the central source of all funds. Users’ supplied assets no longer go into a specific market but are pooled into the network’s Hub, which manages global liquidity and core accounting constraints—such as ensuring the total assets lent out do not exceed the supplied amount, and tracking the utilization of liquidity across different modules.
However, the Hub itself is not directly interacted with by users. Instead, all user-facing operations are handled through a highly modular functional layer called Spoke in V4.
Spoke: Modular Entry Point with Localized Risk
Spokes form the front-end layer that users directly interact with in Aave V4. Each Spoke connects to the same Liquidity Hub but can have entirely different rules, parameters, and risk assumptions. Spokes locally manage user positions, collateral structures, oracle integrations, and liquidation logic, while the Hub operates in the background to provide limited liquidity support within set bounds.
The core significance of this division is: Risks are strictly contained within each Spoke and do not propagate across the system. Borrowing demands for different asset types or behaviors no longer need to share the same risk parameters but can operate independently while sharing liquidity.
This design also allows many functions, previously cumbersome in V3, to be implemented more naturally in V4. For example, E-Mode is no longer just a parameter set but can exist as a dedicated Spoke serving highly correlated asset groups; isolation modes can be implemented via dedicated Spokes, with the Hub setting clear limits on their available liquidity. For RWA or more complex collateral structures, V4 permits custom Spokes with stricter access controls and risk rules, avoiding complexity proliferation across the entire protocol.
How does V4’s unified liquidity accounting work?
To support the unified liquidity at the Hub level, V4 abandons the rebase mechanism of aTokens and adopts an ERC-4626-style share system.
In Aave V4, the protocol discards the previous aToken rebase approach, instead using an ERC-4626-like share accounting system. This means users no longer hold aTokens that automatically increase in quantity as interest accrues; instead, they hold a fixed number of shares, with the underlying asset value per share increasing over time. In other words, interest is no longer reflected by token quantity changes but through the changing value of each share, akin to traditional vault accounting.
This share model is closely related to V4’s unified liquidity design. All supplied assets are pooled into the on-chain Liquidity Hub, which uses the share system to precisely record the total asset state. The Hub does not need to track each Spoke’s specific borrowing strategies or risk modes; it only manages total assets, total shares, and the quota utilized by each Spoke. This allows multiple Spokes to share the same asset pool while maintaining clarity and controllability in accounting, avoiding the complexity and risk spillover that could arise with traditional aToken rebases in multi-module environments.
Continuing to use the aToken rebase mechanism would face difficulties in synchronizing exponential growth across Spokes, risk and interest spillover, and precise control of sub-module quotas. The ERC-4626 share model simplifies these issues into straightforward arithmetic, enabling the Hub to support diverse lending strategies and risk configurations safely and controllably under a unified liquidity framework. This not only enhances capital efficiency but also lays the foundation for modularity and future expansion of the V4 architecture.
Fine-tuning the Liquidation Mechanism: Moving Beyond Fixed Ratios
Beyond liquidity restructuring, V4 also introduces important adjustments to the liquidation mechanism. Unlike the previous fixed-ratio logic, V4 features a risk-targeted liquidation engine.
In V3 and earlier versions, when a position’s health factor drops below a safety threshold, the protocol allows liquidators to repay a preset close factor proportion of the debt and seize collateral accordingly. While effective in protecting protocol safety, such a method can lead to over-liquidation during volatile or marginal situations—liquidation amounts exceeding what’s necessary to restore safety.
V4’s new liquidation engine shifts focus from a “liquidation ratio” to “safety objectives.” When a position becomes liquidatable, the system calculates the minimum debt repayment and collateral disposal needed to restore the health factor to a safe zone. Liquidation no longer aims to maximize risk removal but to perform the minimal necessary action, reducing asset erosion and maintaining protocol safety.
This means the close factor becomes a dynamic result influenced by position risk, market volatility, collateral structure, and risk parameters. The size of liquidations adjusts accordingly, better reflecting actual risk differences between positions and helping to reduce liquidation shocks and unnecessary asset sales.
Aave’s updated liquidation mechanism is reminiscent of Fluid’s design. From a lending product perspective, V4 significantly improves upon the previous “one-size-fits-all” liquidation approach, making the logic more precise and aligned with actual risk.
However, compared to Fluid, which integrates lending positions directly into trading liquidity pools to absorb some risks within the pool and often eliminate the need for external liquidators, Aave remains in a different paradigm. Fluid’s design offers cost and execution efficiency advantages by embedding risk absorption into the trading flow, whereas Aave still relies on external liquidators, making its refined liquidation logic more complex but also more flexible in traditional DeFi terms.
Summary
Overall, Aave V4 is not a complete overhaul but a relatively restrained yet systematic evolution: restructuring liquidity via the Hub and Spoke architecture, localizing risk through modular Spokes, and enhancing the liquidation engine for more precise risk handling. This evolution transforms Aave from a multi-market, unit-based lending protocol into a modular lending infrastructure capable of supporting more complex financial structures.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Aave V4: From Fragmented Markets to Modular Liquidity
Article by: Tia, Techub News
In the DeFi lending space, Aave has long been a benchmark for innovation and industry standards. As user numbers and asset types grow, Aave V3 has gradually revealed issues such as liquidity fragmentation, risk management, and rough liquidation mechanisms. To address these challenges, Aave V4 has undergone a systematic upgrade: liquidity organization has been redesigned into a unified Hub and modular Spoke architecture, enabling multi-asset and multi-strategy sharing of liquidity while maintaining risk isolation; the accounting system has been upgraded to an ERC-4626-style share model, making the overall liquidity state clear and controllable; the liquidation mechanism has shifted from a fixed ratio model to a dynamic, health factor-centric logic that performs minimal necessary liquidations. Overall, V4 is not just a parameter optimization but a co-evolution of architecture and mechanisms, transforming Aave from a fragmented multi-market lending protocol into a more scalable, capital-efficient, and risk-controlled modular infrastructure.
From “Market”-Centered V3 to the Reality of Liquidity Fragmentation
In Aave V3, the protocol employs a deployment method centered around “markets.” In different networks, or even within the same network, Aave divides into multiple independent markets, such as Core and Prime on the Ethereum mainnet. Each market has its own independent liquidity pools, supported asset combinations, and corresponding risk parameters, forming distinct risk profiles.
When users supply assets to Aave V3, they are explicitly depositing into a specific market, rather than into a global shared pool. This means assets supplied to the Ethereum Core market can only be used by borrowers within that market, and cannot be accessed by Prime market users or users on other networks.
This design offers clear advantages in risk isolation—risks do not propagate between markets. However, the cost is also evident: liquidity is cut into pieces. Even the same asset is split across multiple markets, making it difficult to manage centrally, which impacts overall capital utilization, market depth, and the ability to implement new features.
Hub and Spoke: Liquidity Restructuring Logic in Aave V4
Aave V4’s response to this problem is a fundamental restructuring of the underlying architecture, introducing a new Hub and Spoke framework. The goal of this design is to solve the long-standing issues of liquidity fragmentation and limited scalability seen in V3.
In V4, liquidity is no longer bound within a single market. Instead, each network introduces a unified Liquidity Hub, which acts as the central source of all funds. Users’ supplied assets no longer go into a specific market but are pooled into the network’s Hub, which manages global liquidity and core accounting constraints—such as ensuring the total assets lent out do not exceed the supplied amount, and tracking the utilization of liquidity across different modules.
However, the Hub itself is not directly interacted with by users. Instead, all user-facing operations are handled through a highly modular functional layer called Spoke in V4.
Spoke: Modular Entry Point with Localized Risk
Spokes form the front-end layer that users directly interact with in Aave V4. Each Spoke connects to the same Liquidity Hub but can have entirely different rules, parameters, and risk assumptions. Spokes locally manage user positions, collateral structures, oracle integrations, and liquidation logic, while the Hub operates in the background to provide limited liquidity support within set bounds.
The core significance of this division is: Risks are strictly contained within each Spoke and do not propagate across the system. Borrowing demands for different asset types or behaviors no longer need to share the same risk parameters but can operate independently while sharing liquidity.
This design also allows many functions, previously cumbersome in V3, to be implemented more naturally in V4. For example, E-Mode is no longer just a parameter set but can exist as a dedicated Spoke serving highly correlated asset groups; isolation modes can be implemented via dedicated Spokes, with the Hub setting clear limits on their available liquidity. For RWA or more complex collateral structures, V4 permits custom Spokes with stricter access controls and risk rules, avoiding complexity proliferation across the entire protocol.
How does V4’s unified liquidity accounting work?
To support the unified liquidity at the Hub level, V4 abandons the rebase mechanism of aTokens and adopts an ERC-4626-style share system.
In Aave V4, the protocol discards the previous aToken rebase approach, instead using an ERC-4626-like share accounting system. This means users no longer hold aTokens that automatically increase in quantity as interest accrues; instead, they hold a fixed number of shares, with the underlying asset value per share increasing over time. In other words, interest is no longer reflected by token quantity changes but through the changing value of each share, akin to traditional vault accounting.
This share model is closely related to V4’s unified liquidity design. All supplied assets are pooled into the on-chain Liquidity Hub, which uses the share system to precisely record the total asset state. The Hub does not need to track each Spoke’s specific borrowing strategies or risk modes; it only manages total assets, total shares, and the quota utilized by each Spoke. This allows multiple Spokes to share the same asset pool while maintaining clarity and controllability in accounting, avoiding the complexity and risk spillover that could arise with traditional aToken rebases in multi-module environments.
Continuing to use the aToken rebase mechanism would face difficulties in synchronizing exponential growth across Spokes, risk and interest spillover, and precise control of sub-module quotas. The ERC-4626 share model simplifies these issues into straightforward arithmetic, enabling the Hub to support diverse lending strategies and risk configurations safely and controllably under a unified liquidity framework. This not only enhances capital efficiency but also lays the foundation for modularity and future expansion of the V4 architecture.
Fine-tuning the Liquidation Mechanism: Moving Beyond Fixed Ratios
Beyond liquidity restructuring, V4 also introduces important adjustments to the liquidation mechanism. Unlike the previous fixed-ratio logic, V4 features a risk-targeted liquidation engine.
In V3 and earlier versions, when a position’s health factor drops below a safety threshold, the protocol allows liquidators to repay a preset close factor proportion of the debt and seize collateral accordingly. While effective in protecting protocol safety, such a method can lead to over-liquidation during volatile or marginal situations—liquidation amounts exceeding what’s necessary to restore safety.
V4’s new liquidation engine shifts focus from a “liquidation ratio” to “safety objectives.” When a position becomes liquidatable, the system calculates the minimum debt repayment and collateral disposal needed to restore the health factor to a safe zone. Liquidation no longer aims to maximize risk removal but to perform the minimal necessary action, reducing asset erosion and maintaining protocol safety.
This means the close factor becomes a dynamic result influenced by position risk, market volatility, collateral structure, and risk parameters. The size of liquidations adjusts accordingly, better reflecting actual risk differences between positions and helping to reduce liquidation shocks and unnecessary asset sales.
Aave’s updated liquidation mechanism is reminiscent of Fluid’s design. From a lending product perspective, V4 significantly improves upon the previous “one-size-fits-all” liquidation approach, making the logic more precise and aligned with actual risk.
However, compared to Fluid, which integrates lending positions directly into trading liquidity pools to absorb some risks within the pool and often eliminate the need for external liquidators, Aave remains in a different paradigm. Fluid’s design offers cost and execution efficiency advantages by embedding risk absorption into the trading flow, whereas Aave still relies on external liquidators, making its refined liquidation logic more complex but also more flexible in traditional DeFi terms.
Summary
Overall, Aave V4 is not a complete overhaul but a relatively restrained yet systematic evolution: restructuring liquidity via the Hub and Spoke architecture, localizing risk through modular Spokes, and enhancing the liquidation engine for more precise risk handling. This evolution transforms Aave from a multi-market, unit-based lending protocol into a modular lending infrastructure capable of supporting more complex financial structures.