Diphunter ¤(@Diphunter18):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.

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.

Diphunter ¤@Diphunter18

2026.08.26 10:28

Aave can only liquidate what it can price. That sounds simple, but the more I looked into @aave, the more I realized how much of the entire risk system depends on the price coming from its oracle infrastructure. Let's go back to the $10,000 of ETH I used as collateral in the previous posts. If ETH is trading at $2,500, my 4 ETH are worth $10,000. If ETH falls to $2,000, that same collateral is suddenly worth $8,000. I haven't changed anything about my position. The market moved, the oracle reflects that new price, and Aave can immediately use it in its risk calculations. That price feeds directly into the things we've already looked at. My collateral value changes. My Health Factor changes. My borrowing capacity changes. And if the position becomes unhealthy enough, it can become eligible for liquidation. So the oracle sits much closer to the core of the lending system than I initially thought. Aave has used @chainlink Data Feeds as its oracle infrastructure since 2020, with the feeds providing the price information that the protocol uses for assets across its markets. But an oracle isn't simply about finding a number and putting it onchain. Different assets require different ways of thinking about their value. For ETH, a market price is relatively straightforward. For an asset such as wstETH, the relationship between the token and its underlying asset also matters. For stablecoins, the protocol has to account for the fact that the asset is designed to stay around a particular value, while still allowing for the possibility that its market price can move away from that target. This is where Aave's Correlated Asset Price Oracle, or CAPO, becomes important. CAPO can place constraints on how quickly the reported exchange rate of certain correlated or yield-bearing assets is allowed to increase. For example, with an asset such as wstETH, an artificially inflated exchange rate could make the collateral appear more valuable than it really is. That could create additional borrowing capacity that isn't actually backed by economic value. CAPO is designed to limit that kind of upward manipulation by applying a time-weighted growth constraint to the exchange rate. Aave's V4 oracle configuration builds on this approach. The current V4 Ethereum configuration uses standard Chainlink feeds, SVR variants where available, CAPO for relevant yield-bearing assets and stablecoins, and specialized pricing adapters for certain assets such as Pendle PTs. That fits directly into the Hub and Spoke architecture we looked at in the last post. The Spoke manages user positions, tracks collateral and integrates with price oracles, while the Liquidity Hub provides the shared liquidity underneath. This means the oracle configuration can sit alongside the specific risk environment of each Spoke rather than every market having to follow exactly the same setup. And this becomes especially relevant when looking at V4's broader approach to risk. A Spoke focused on highly correlated assets can have a different risk configuration from a Spoke dealing with more volatile collateral. The liquidity can still come from the same Hub. The risk and pricing logic can remain specific to the Spoke. That separation is one of the reasons the V4 architecture can support very different lending environments on top of shared liquidity. There is another part of the oracle system that becomes particularly relevant during liquidations. When an oracle update changes the value of collateral, that update can trigger liquidations. Those liquidations can create Oracle Extractable Value, or OEV. In simple terms, the price update can create an opportunity for someone to profit by acting immediately around the liquidation. Aave integrated Chainlink SVR, Smart Value Recapture, to capture part of that value instead of allowing all of the liquidation-related MEV to flow to external searchers, builders or validators. SVR uses an auction mechanism around eligible liquidation-related transactions, allowing part of that value to be redirected back to Aave. The numbers here are already meaningful. Aave reported that during the first nine months of SVR through early February 2026, it handled around $675 million in liquidations across roughly 3,900 events, while recapturing around $16 million in revenue. Aave Labs later reported that SVR had generated approximately $5 million in revenue for Aave during 2026 up to May and that the V4 SVR feed migration had been completed. So the oracle isn't just determining whether my ETH is worth $2,500 or $2,000. It can influence the Health Factor that determines whether my position becomes liquidatable, and the resulting liquidation can create economic value that Aave is now actively trying to recapture. There is also a good example of why this infrastructure has to be treated as part of the risk system itself. In March 2026, an issue with a 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. This triggered roughly 10,938 wstETH in E-Mode liquidations. Aave incurred no bad debt from the incident, and subsequent work recovered part of the liquidation-related value to compensate affected users. The incident also led to further work around CAPO's update logic and safeguards. That example makes the whole architecture much easier to appreciate. The oracle provides the price. The price determines the value of the collateral. The collateral value affects the Health Factor. The Health Factor can determine whether liquidation becomes possible. The liquidation creates an incentive for a liquidator. And with SVR, part of the value created around that liquidation can flow back to the protocol. What started with a simple ETH price therefore connects almost every part of the system we've looked at so far. Oracle price → collateral value → Health Factor → liquidation → OEV. And there is one more layer that becomes important when the market moves far outside normal conditions, what happens when the price feed itself becomes delayed, distorted or unavailable? That is where Aave's oracle safeguards and failure mechanisms become the next piece of the puzzle.

Forward to community