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.

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.

"The ceiling was too low." @superstateinc CEO @rleshner on why he left Compound to grow DeFi's addressable market by 10,000x. When trillions in assets flood in, protocols like $FRAX, $AAVE, $SKY, $COMP and $AERO all re-rate.

What happens when your Health Factor finally drops below 1? We have already looked at how collateral, borrowing capacity, interest and the Health Factor interact. Now we get to the point where the position becomes stressed enough for the protocol to take action. Let's go back to the example from the previous posts. I have $10,000 worth of ETH supplied as collateral and $6,000 of USDC debt. My position starts with a Health Factor of around 1.33. Then ETH falls. At the same time, interest continues accruing on my debt. Eventually, the Health Factor can fall below 1. At that point, my position becomes eligible for liquidation. A liquidation is essentially a mechanism that allows another participant in the market to repay part of my debt in exchange for some of my collateral. Imagine I owe $6,000 USDC and my ETH position has become too risky. A liquidator can repay part of that USDC debt. In return, the liquidator receives ETH worth more than the amount of debt they repaid. That additional amount is the liquidation bonus. This incentive is important because the liquidator is providing a service to the protocol. The debt is reduced, collateral is removed from the risky position and Aave gets closer to having a fully collateralized system again. So the liquidator isn't simply taking someone's collateral. They are effectively acquiring collateral from a stressed position while repaying the debt attached to it. That creates an economic incentive to keep liquidations happening even when markets are moving quickly. In Aave V3, the amount that can be repaid during a liquidation is controlled by the close factor. In the standard case, a liquidator can repay up to a defined portion of the outstanding debt rather than necessarily closing the entire position. Imagine I have $10,000 of debt and the applicable close factor allows a 50% liquidation. A liquidator could repay up to $5,000 of that debt. But what if the position only needs $2,000 of repayment to move back into a much healthier state? The fixed close-factor approach doesn't specifically calculate the amount needed to restore the position. This is one of the areas where Aave V4 changes the design. Instead of relying on a fixed repayment percentage, V4 introduces a Target Health Factor. The liquidation engine can calculate how much debt needs to be repaid to move the position back toward that target. Imagine my Health Factor has fallen to 0.90 and the relevant Target Health Factor is 1.24. The system can determine the amount of debt that needs to be repaid to bring the position back toward that target rather than simply applying the same fixed percentage to every liquidation. V4 also changes the liquidation incentive itself. In V3, the liquidation bonus is configured as a relatively fixed parameter for the relevant asset and market. V4 introduces a dynamic liquidation bonus that changes depending on how far the position has deteriorated. A position that has only slightly crossed the liquidation threshold can therefore have a different incentive from a position that has become much more distressed. As the Health Factor deteriorates, the potential liquidation incentive increases. This creates a simple economic relationship: more risk → stronger liquidation incentive. V4 also introduces parameters such as the Target Health Factor, the Health Factor for Max Bonus and the Liquidation Bonus Factor to shape how this mechanism behaves for each risk configuration. And there is another small detail that matters more than it first appears, leftover debt. A liquidation can sometimes leave a very small amount of debt or collateral behind. V4 includes specific dust-liquidation logic so that these tiny residual positions can be handled instead of leaving economically insignificant pieces of debt sitting in the system. Putting everything together, the process becomes much clearer. My collateral provides the security. The debt represents what I owe. Interest can increase that debt over time. The Health Factor tracks how much room the position has. If the Health Factor falls below 1, the position becomes eligible for liquidation. A liquidator repays debt and receives collateral plus an incentive. And in V4, the liquidation is designed around restoring the position toward a target rather than simply applying a fixed repayment percentage. Liquidation therefore isn't just the final step of borrowing. It is part of the mechanism that allows Aave to keep lending safely while markets move, collateral prices change and debt accumulates. And once you look at it this way, one thing becomes especially important, someone has to decide what the collateral is actually worth. That brings us to one of the most critical pieces underneath the entire system, Aave's oracles.