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

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.

Diphunter ¤@Diphunter18

2026.08.22 14:19

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.