Futures
Access hundreds of perpetual contracts
TradFi
Gold
One platform for global traditional assets
Options
Hot
Trade European-style vanilla options
Unified Account
Maximize your capital efficiency
Demo Trading
Introduction to Futures Trading
Learn the basics of futures trading
Futures Events
Join events to earn rewards
Demo Trading
Use virtual funds to practice risk-free trading
Launch
CandyDrop
Collect candies to earn airdrops
Launchpool
Quick staking, earn potential new tokens
HODLer Airdrop
Hold GT and get massive airdrops for free
Launchpad
Be early to the next big token project
Alpha Points
Trade on-chain assets and earn airdrops
Futures Points
Earn futures points and claim airdrop rewards
Aave V4 Mainnet Launching Soon: How the Hub-Spoke Architecture Addresses Liquidity Fragmentation Challenges
In the current Aave V3 system, the protocol adopts a multi-instance deployment model centered around “markets.” The core market on the Ethereum mainnet holds approximately $60 billion in liquidity, while the Prime market, targeted at low-risk preferences, holds about $2 billion, with both operating independently. This means that even if the same asset—such as USDC—has billions in the core market, users in the Prime market cannot access that liquidity. The essence of this design is to tightly bind the risk allocation of the market to its liquidity depth, leading to the startup challenge of “accumulating liquidity from scratch” for each new market.
The emergence of Aave V4 is a fundamental response to this structural constraint: by introducing a Hub-Spoke architecture, it completely separates liquidity storage from market logic, allowing new markets to access existing liquidity pools from their first day online.
The separation mechanism of Hub and Spoke: How to achieve liquidity unity and risk isolation
The core of the Hub-Spoke architecture lies in restructured division of labor. The Liquidity Hub acts as a unified liquidity center, managing the total supply of all assets, lending authorizations, and accounting constraints, ensuring that the overall borrowing scale of the system does not exceed the supply limit. Spoke, on the other hand, is a dedicated interaction module for users, where each Spoke can independently define its supported asset types, risk parameters, liquidation rules, and oracle configurations, while obtaining liquidity support from the Hub within predefined limits. The key breakthrough of this design is that liquidity is no longer locked within the boundaries of a specific market but exists in the Hub layer as a “shared pool,” allowing multiple Spokes to call upon liquidity in parallel according to credit limits set by governance. At the same time, risk is strictly contained within the Spoke—if a particular Spoke incurs bad debts due to asset volatility or liquidation failures, it will not spill over to the Hub or other Spokes.
The unified cost: Efficiency trade-offs and governance complexity in a modular architecture
Any architectural restructuring comes with trade-offs. The Hub-Spoke model, while addressing liquidity fragmentation, introduces new structural costs. Firstly, the Hub layer must bear more complex global accounting responsibilities—the V4 abandons the rebase mechanism of aTokens in V3 and shifts to an ERC-4626-style market share model, where the underlying asset value corresponding to each share increases with accumulated interest, thus accurately recording each Spoke’s quota usage in the unified pool. Secondly, the governance process faces higher complexity: the risk parameters of Spokes are set by the DAO, but the distribution of credit limits, interest rate linkage mechanisms, and cross-Spoke liquidation coordination require a more refined governance framework. Thirdly, the controversy over migration paths has already surfaced within the community—previously, Aave Labs proposed pausing V3 optimizations to promote user migration to V4, which met opposition from some core contributors, leading to the withdrawal of that proposal and a commitment not to enforce migration. This indicates that architectural upgrades, beyond the technical aspects, also need to address the smooth transition of the existing ecosystem.
From protocol to infrastructure: What does the landscape mean for the DeFi lending sector?
The evolution direction of V4 essentially upgrades Aave from a “multi-market parallel lending protocol” to a “modular infrastructure that can accommodate diverse financial logic.” This change in positioning will have multiple industry impacts. First, the increase in capital efficiency will change the competitive benchmark for the lending sector—new markets no longer need to compete for deposits with existing markets, allowing developers to focus on customized lending logic for new asset types such as Pendle PT, Uniswap LP positions, and Ethena sUSDe, without having to build liquidity from scratch. Second, the risk pricing mechanism shifts from “one-size-fits-all” to “refined”: the liquidity premium mechanism introduced in V4 allows borrowing rates to adjust dynamically based on the liquidity conditions of collateral assets, with benchmark assets like ETH maintaining zero premiums, while more volatile assets bear corresponding premiums. Third, the deep integration of the GHO stablecoin further strengthens the internal closed loop of the protocol—the soft liquidation mechanism (LLAMM) allows the system to gradually convert assets to GHO when collateral prices fall and repurchase collateral when prices rise, enhancing liquidation efficiency and stability.
Looking forward from V4: Possible evolution paths for liquidity layers, cross-chain lending, and ecosystem expansion
The architecture of V4 not only addresses current issues but also reserves interfaces for future functional expansions. First, the design of a unified liquidity layer naturally supports cross-chain lending—users can deposit assets on one chain and borrow funds on another, with the liquidity layer serving as an abstract cross-chain liquidity hub that undertakes liquidation and accounting functions. Second, the composability of Spokes makes complex financial primitives such as secondary markets for debt positions, fixed-term credit markets, and dynamic credit limits for AMM positions possible, allowing developers to focus solely on the business logic of the Spoke layer, while the underlying liquidation system and risk management framework can directly inherit from Aave’s validated modules. Additionally, the Aave ecosystem is exploring the direction of an “independent network layer,” planning to launch a dedicated network as the core infrastructure for GHO and lending business; although this direction is still in the conceptual stage, it reflects the strategic intent of leading DeFi protocols to evolve towards a more complete tech stack.
Risks and boundaries: Potential hidden dangers not yet resolved by the new architecture
Although V4 has achieved significant optimization at the architectural level, there remain risk dimensions that have not been fully resolved. Firstly, the liquidation mechanism has shifted from “fixed ratio” to “minimum necessary liquidation,” but it still relies on external third-party liquidators for execution; this presents a cost structure and execution efficiency gap compared to designs like Fluid, which deeply integrate lending and DEX liquidity. Secondly, in a multi-Spoke parallel operating environment, a mature paradigm for global risk monitoring across Spokes has yet to be formed—when multiple Spokes simultaneously call Hub liquidity and adopt different risk models, the identification and early warning mechanisms for systemic risk still need validation. Thirdly, while the soft liquidation mechanism of GHO draws from the LLAMM model of crvUSD, its actual performance under extreme market conditions lacks large-scale stress test data support. Moreover, the disputes at the DAO governance level—including issues regarding core contributor renewals and conflicts in resource allocation between V3 and V4—reflect the risks of divergence the community may face during significant upgrades.
Conclusion
The mainnet deployment of Aave V4 marks a migration of DeFi lending protocols from “multi-market parallel” to “unified liquidity layer + modular risk units” architectural paradigm. The Hub-Spoke design addresses the long-standing pain point of liquidity fragmentation while providing a foundational framework for new asset access, cross-chain lending, and refined risk pricing. However, the governance complexity introduced by architectural upgrades, gaps in global risk monitoring, and community coordination issues during migration paths remain challenges that V4 needs to continuously address in the process of technical implementation and ecological maturity. For the DeFi lending sector, V4 is not just an iteration of the protocol version, but also a structural experiment on “how protocols evolve into infrastructure.”
FAQ
Q1: What is the core difference in liquidity management between Aave V4 and V3?
V3 adopts an independent market model where each market has its own independent liquidity pool and cannot share assets; V4 introduces the Hub-Spoke architecture, where all liquidity is centrally stored in the Liquidity Hub, and multiple Spokes share the same liquidity pool while independently managing their risk parameters.
Q2: How does the Hub-Spoke architecture prevent risks from spreading within the system?
Risks are confined within the Spoke. Each Spoke has an independent list of assets, liquidation rules, and limits, so even if a Spoke incurs bad debts, it will not spill over to the Hub or other Spokes. The Hub is only responsible for global accounting and quota management, not directly bearing the credit risks of Spokes.
Q3: What key upgrades has V4 made to the GHO stablecoin?
Key upgrades include: introducing the soft liquidation mechanism (LLAMM), allowing gradual liquidation during collateral price fluctuations instead of forced liquidation; supporting interest payments in GHO; and adding an emergency redemption mechanism to address extreme situations where GHO remains unpegged.
Q4: After V4 goes live, do V3 users need to migrate?
Aave Labs has retracted the proposal for mandatory migration, committing that V3 and V4 will run in parallel, and users are not required to migrate. The initial deployment of V4 will adopt conservative parameters and streamlined asset configurations, prioritizing safety.
Q5: How does the liquidation mechanism of V4 differ from V3?
V3 uses a fixed ratio close factor liquidation model, which can lead to over-liquidation; V4 shifts to a dynamic liquidation logic centered around health factors, calculating the minimum necessary liquidation amount to only repay enough debt to restore the position to a safe range.