The Problem With Shared Liquidity in DeFi Lending

In November 2022, Aave almost faced an insolvency event. A whale opened a large short position on CRV token using Aave as the venue. When the position couldn't be liquidated because no one was willing to step in, it left approximately $1.6 million in bad debt on the protocol with every depositor in same shared pool at risk.

In traditional DeFi, protocols shared liquidity freely. The shared liquidity model brought huge capital inflows. However, the issue was that failure in one market could lead to a snowball effect that put the rest of the protocol’s liquidity at risk. Aave V3 changed this by introducing “Isolation Mode” to mitigate risk when a new asset market is created. This was a selective compartmentalization of risk.

Now, Aave V4 has introduced a new architecture that expands on Aave V3’s approach to institutional DeFi risk management, called the “Hub and Spoke” architecture. The hub-and-spoke design aims to pool liquidity in a central hub while isolating risk at the spoke level to compartmentalize collateral and liquidation behavior.

Aave V3 vs Aave V4 Architecture

A market in Aave V3 has its own assets, its own risk settings, and its own users. Examples of these are the Ethereum Core Market and Ethereum Prime Market. In V3, Aave deploys each market separately on each network. This means Aave on Arbitrum is different from Aave on Ethereum. The liquidity does not automatically merge together.

In V3, users supply assets to specific markets, where only those assets can be borrowed within the market. Assets supplied to Ethereum Core can only be borrowed by Ethereum Core users. This design in V3 was implemented to contain risk damage to only the specific markets. The isolation improved safety, but with the tradeoff of liquidity fragmentation. Launching new markets had friction because they often had low liquidity, which meant fewer borrowers as well.

Aave V4 introduced a liquidity hub in its new architecture. Instead of having separate liquidity pools everywhere, like in V3, V4 has one central liquidity engine per blockchain network. Now, when users supply assets to V4, those assets are stored in the liquidity hub, but users do not interact with the hub directly. Instead, the liquidity hub works behind the scenes, while users interact with spokes as an entry point to the protocol.

Each spoke that users interact with is connected to the liquidity hub. Spokes have their own rules and risk settings and can be optimized for stablecoins, staked ETH derivatives, or higher-risk assets. Certain spokes may also focus on specific borrowing strategies or support special collateral types like LP shares. They also manage user positions, track collateral, integrate with price oracles, and include safety controls that allow operations to be paused if needed.

There are different types of spokes. One of them is the Isolation Spoke, which already exists in V3. It is a safety mechanism for newer, riskier, and less-tested assets. Suppose Aave lists a brand-new token that carries risks such as low liquidity, price manipulation, oracle attacks, or smart contract exploits. Aave does not want one risky token threatening the whole system, so Isolation Mode restricts it.

The major difference is that V3 Isolation Mode limited risky assets from interacting with the main pool, but this caused liquidity fragmentation. Instead of isolating individual risky assets inside one large pool, Aave V4 creates separate modular markets with their own risk rules, liquidation logic, and borrowing parameters, while still sharing the same underlying liquidity.

Why Institutional DeFi Needs Compartmentalized Risk

This starts with protocol design patterns: modular vs. monolithic. Monolithic protocols concentrate risk, so an attack or bug can affect all users. Modular designs allow components to be isolated. Aave allows Isolation Mode. If institutions are to engage in DeFi and run strategies, the products they use should have modular layers in their design to isolate risk.

The CRV incident is exactly the kind of event institutional fund managers think about when evaluating a DeFi lending protocol. In a shared pool, one risky asset going wrong can cause losses for every depositor, even those who had nothing to do with that asset. In a spoke based design, the risky asset sits in its own separate market. If something goes wrong there, it stays there.

Institutions care about liquidity shocks, unknown collateral assets, and the spread of systemic risk. They want controlled collateral behavior and predictable risk boundaries. By having isolated components, protocols not only protect the entire pool infrastructure but also allow institutions to experiment with markets curated to their needs. Aave Arc allowed permissioned lending pools accessible only to KYC-approved institutions. This compartmentalization allows institutions to avoid mixing risky collateral with blue-chip collateral.

Managing DeFi Allocations at the Fund Level

Understanding which protocols are safe to allocate to is only half the problem for institutional fund managers. The other half is tracking what those positions are actually doing across onchain markets, CEX venues, and DeFi protocols, and reporting it accurately to LPs. That's what Renesis is built for. A unified platform for crypto funds that gives you real-time NAV, institutional-grade execution, and the operational infrastructure to run DeFi allocations without duct-taping five tools together.