Diphunter ¤(@Diphunter18):One question came up for me when looking at how Aave V4 is structured, If Aave wants to support more assets, more risk profiles and more specialized markets, how do you do that without splitting liquidity into smaller and smaller pools? Aave V3 handles different risk profiles largely through separate markets. Each market has its own liquidity, asset listings and risk parameters. That works, but it also means liquidity can become fragmented. If one market has plenty of USDC available while another market has high borrowing demand for the same USDC, that liquidity cannot simply flow between them. V4 approaches this differently. Instead of making every market its own isolated pool of liquidity, V4 introduces Liquidity Hubs and Spokes. The Hub is where the liquidity sits. The Spokes are the markets users actually interact with. Each Spoke can have its own collateral, borrowable assets, risk parameters, liquidation rules and other restrictions, while still drawing liquidity from the Hub behind the scenes. This also connects directly to the oracle side we looked at in the last post. Because each Spoke can support a different set of assets and risk profiles, the pricing infrastructure needs to fit those assets as well. Aave doesn't necessarily value every asset through the same type of price feed. Depending on the asset, a Spoke can use different oracle configurations and safeguards, such as standard @chainlink feeds, SVR feeds or mechanisms like CAPO for assets where a simple spot price isn't enough. That matters because the oracle price is what ultimately feeds into the risk engine. It affects how much collateral a borrower has, how much they can borrow and when a position becomes liquidatable. So the Spoke isn't just defining which assets can be used and what their risk parameters are. It can also define how those assets are priced and which protections apply to those prices. The liquidity can therefore be shared underneath, while the way assets are valued and risk is managed can remain specific to each Spoke. Instead of thinking about every market as its own pool, I think of it more like a shared liquidity layer with different risk environments built on top. Imagine a Hub holding $100M of USDC. One Spoke could be designed for more conservative collateral, another could focus on correlated assets, and another could support a more specialized or higher-risk market. They don't all need to bootstrap their own $100M pool. They can access the liquidity sitting in the Hub, while the Spokes determine how that liquidity can actually be used. And this is where the risk side becomes important. A Spoke doesn't get unlimited access to the Hub. The Hub can set limits on how much liquidity a particular Spoke is allowed to draw, creating a boundary around the amount of risk that can flow through it. So if a Spoke supports a more experimental asset and something goes wrong, the potential impact can be constrained instead of automatically exposing the entire liquidity base. That gives V4 a different balance between liquidity and risk. You can have specialized markets without forcing every new market to build its own liquidity from scratch, while still giving each market its own risk configuration. The architecture also makes things like E-Mode and Isolation Mode more flexible. A stablecoin-focused Spoke could have parameters designed around highly correlated assets. Another Spoke could be built around staked ETH assets. An RWA Spoke could have completely different requirements around collateral, access and risk. All of them can connect to the same underlying liquidity infrastructure, while their risk and oracle configurations can remain tailored to the assets they support. The important part is that V4 doesn't treat risk isolation and liquidity as completely separate problems. The Hub provides the shared liquidity layer, while the Spokes define where that liquidity can go, which assets can be used and under which conditions. Because those rules live at the Spoke level, Aave can create new market structures without having to redesign the entire liquidity layer each time. There is also an important difference for suppliers. In V3, supplying to a specific market means your liquidity is tied to that market. In V4, the underlying liquidity sits in the Hub and can potentially serve multiple connected Spokes, subject to the credit lines and limits defined for them. That creates a different liquidity dynamic. More liquidity in the Hub can support more Spokes, while more useful Spokes can create more demand for that shared liquidity. At the same time, the risk boundaries remain configurable instead of treating the whole network as one giant lending pool. That combination is what makes the architecture so relevant for where @aave is heading. More markets can be built around different assets and risk profiles, while the liquidity underneath can remain connected.

2026.08.30 16:00

One question came up for me when looking at how Aave V4 is structured, If Aave wants to support more assets, more risk profiles and more specialized markets, how do you do that without splitting liquidity into smaller and smaller pools? Aave V3 handles different risk profiles largely through separate markets. Each market has its own liquidity, asset listings and risk parameters. That works, but it also means liquidity can become fragmented. If one market has plenty of USDC available while another market has high borrowing demand for the same USDC, that liquidity cannot simply flow between them. V4 approaches this differently. Instead of making every market its own isolated pool of liquidity, V4 introduces Liquidity Hubs and Spokes. The Hub is where the liquidity sits. The Spokes are the markets users actually interact with. Each Spoke can have its own collateral, borrowable assets, risk parameters, liquidation rules and other restrictions, while still drawing liquidity from the Hub behind the scenes. This also connects directly to the oracle side we looked at in the last post. Because each Spoke can support a different set of assets and risk profiles, the pricing infrastructure needs to fit those assets as well. Aave doesn't necessarily value every asset through the same type of price feed. Depending on the asset, a Spoke can use different oracle configurations and safeguards, such as standard @chainlink feeds, SVR feeds or mechanisms like CAPO for assets where a simple spot price isn't enough. That matters because the oracle price is what ultimately feeds into the risk engine. It affects how much collateral a borrower has, how much they can borrow and when a position becomes liquidatable. So the Spoke isn't just defining which assets can be used and what their risk parameters are. It can also define how those assets are priced and which protections apply to those prices. The liquidity can therefore be shared underneath, while the way assets are valued and risk is managed can remain specific to each Spoke. Instead of thinking about every market as its own pool, I think of it more like a shared liquidity layer with different risk environments built on top. Imagine a Hub holding $100M of USDC. One Spoke could be designed for more conservative collateral, another could focus on correlated assets, and another could support a more specialized or higher-risk market. They don't all need to bootstrap their own $100M pool. They can access the liquidity sitting in the Hub, while the Spokes determine how that liquidity can actually be used. And this is where the risk side becomes important. A Spoke doesn't get unlimited access to the Hub. The Hub can set limits on how much liquidity a particular Spoke is allowed to draw, creating a boundary around the amount of risk that can flow through it. So if a Spoke supports a more experimental asset and something goes wrong, the potential impact can be constrained instead of automatically exposing the entire liquidity base. That gives V4 a different balance between liquidity and risk. You can have specialized markets without forcing every new market to build its own liquidity from scratch, while still giving each market its own risk configuration. The architecture also makes things like E-Mode and Isolation Mode more flexible. A stablecoin-focused Spoke could have parameters designed around highly correlated assets. Another Spoke could be built around staked ETH assets. An RWA Spoke could have completely different requirements around collateral, access and risk. All of them can connect to the same underlying liquidity infrastructure, while their risk and oracle configurations can remain tailored to the assets they support. The important part is that V4 doesn't treat risk isolation and liquidity as completely separate problems. The Hub provides the shared liquidity layer, while the Spokes define where that liquidity can go, which assets can be used and under which conditions. Because those rules live at the Spoke level, Aave can create new market structures without having to redesign the entire liquidity layer each time. There is also an important difference for suppliers. In V3, supplying to a specific market means your liquidity is tied to that market. In V4, the underlying liquidity sits in the Hub and can potentially serve multiple connected Spokes, subject to the credit lines and limits defined for them. That creates a different liquidity dynamic. More liquidity in the Hub can support more Spokes, while more useful Spokes can create more demand for that shared liquidity. At the same time, the risk boundaries remain configurable instead of treating the whole network as one giant lending pool. That combination is what makes the architecture so relevant for where @aave is heading. More markets can be built around different assets and risk profiles, while the liquidity underneath can remain connected.

Diphunter ¤@Diphunter18

2026.08.28 13:23

That last part made me look a little deeper into what happens when an oracle price doesn't behave the way the protocol expects. Because in a lending market, a wrong price can change a lot more than just a number on a screen. Take the wstETH/stETH exchange rate. wstETH represents stETH, so its exchange rate should generally increase over time as staking rewards accrue. Aave needs to account for that when valuing wstETH as collateral. At the same time, there is a very specific risk here. If that exchange rate could suddenly jump upwards, the protocol could see more collateral value than actually exists economically. A borrower could potentially use that artificially inflated collateral to create additional borrowing power. That is one of the problems CAPO is designed to address. CAPO, the Correlated Asset Price Oracle, puts a time-weighted upper bound on the exchange rate of certain correlated and yield-bearing assets. The idea is pretty straightforward: a legitimate exchange rate can grow over time, while a sudden artificial jump gets constrained. That gives Aave another layer between the raw oracle data and the value the risk engine actually uses. And this is where I started appreciating how much thought goes into something that, from the outside, can look like a simple price feed. There is a real trade-off. If the protection is too loose, an attacker may be able to manipulate the exchange rate and inflate collateral. If it is too restrictive, the protocol can end up using a price below the actual market value. Aave actually experienced the second situation in March 2026. A technical issue in the CAPO configuration caused the effective wstETH/stETH exchange rate used by Aave's Ethereum Core and Prime instances to fall below the valid market exchange rate. The effective rate dropped by around 2.85%, which triggered roughly 10,938 wstETH in E-Mode liquidations. Aave did not incur bad debt from the incident, but liquidators captured around 512 ETH in liquidation bonuses and value related to the exchange-rate deviation. Aave later recovered 141 ETH through BuilderNet refunds, plus roughly 13 ETH in liquidation fees, with those recovered funds intended to compensate affected users. What caught my attention here is that the protection itself wasn't the problem. The problem came from how the snapshot ratio and snapshot timestamp were updated. The timestamp represented a seven-day-old reference point, while the ratio had not actually been updated to match that reference. CAPO then calculated a maximum allowed exchange rate that was below the rate already being used by the market. A safeguard designed to protect the protocol from one type of oracle manipulation ended up creating a different kind of pricing problem. And that is a really good example of why risk infrastructure has to be designed around edge cases as well as normal market conditions. It also shows why Aave treats oracle configuration as part of the risk framework itself. The parameters matter, the update frequency matters, the relationship between different price sources matters, and the way those values interact with collateral and liquidation parameters matters even more. V4 takes this idea further by making oracle configuration part of the Spoke-level risk environment. For example, the Ethereum V4 configuration uses different pricing mechanisms depending on the asset. CAPO is used for relevant yield-bearing assets and stablecoins, while other assets can use standard Chainlink feeds, SVR feeds or specialized adapters. That gives each market more room to use the pricing and risk controls that actually fit the assets inside it. And V4 adds another important layer: automated safeguards are becoming a much bigger part of the design. The goal is to make the protocol capable of reacting to abnormal conditions through predefined, onchain controls instead of relying entirely on someone noticing a problem and reacting manually. Supply caps, oracle deviation protections and other risk controls can limit how far a problem can propagate through a market. Aave's V4 risk discussions specifically highlight automated safeguards and oracle deviation triggers as part of the direction of the new risk framework. Looking at this from the outside, I used to think of an oracle as simply the thing that tells Aave what an asset is worth. Now I see it more as one of the layers that decides how much trust the entire lending system can place in that value. The price feeds the collateral valuation. The collateral valuation feeds the Health Factor. The Health Factor feeds liquidation. And the safeguards around the oracle can determine whether an abnormal price movement becomes a protocol-wide problem or stays contained. That makes oracle design one of the most important parts of Aave's risk architecture. And after going through the pricing side, the next part of V4 I want to look at how Aave separates different risks while still allowing them to share liquidity.

커뮤니티로 전달