Overview
Chaos Labs supports the deployment of Chainlink Smart Value Recapture Oracles, which we believe will introduce a new revenue stream for Aave while incurring minimal expected losses. Below, we present a technical review of Chainlink Smart Value Recapture, along with an analysis of its potential risks and profitability.
Technical Overview
Problem
Aave implements a liquidation bonus to incentivize third-party liquidators to repay a borrower’s debt when their position becomes eligible for liquidations. However, a fixed liquidation bonus (e.g., 3%) often exceeds what’s actually needed to incentivize liquidators (e.g., 2%), creating surplus profit that leads to this special type of MEV extraction: Oracle Extraction Value (OEV).
Searchers race to detect price oracle updates and submit liquidation transactions immediately after the price oracle update (a process known as back-running). To ensure their backrun order is included, searchers must bid a significant portion of their profit in the auction to incentivize builders to select their transaction. This allows builders, who don’t do the majority of the job, to capture a large share of the surplus profit.
MEV Supply Chain Illustration. Source: Flashbots
MEV-Boost
Understanding MEV-Boost and MEV-Share is essential for grasping how Chainlink Smart Value Recapture (SVR) addresses the above issues. MEV-boost is an implementation of Proposer-Builder Separation (PBS) for Ethereum. It provides a private transaction pool and a sealed bid blockspace auction mechanism.
Within this architecture, searchers and users send transactions or bundles to block builders. Builders run algorithms and simulations to optimize the order of transactions into an execution payload that maximizes profitability. They then bid for the right to propose their block to validators by offering a portion of the MEV rewards. Relays act as intermediaries, receiving execution payload from builders, verifying their validity, and calculating their value. Validators receive execution payload headers (summaries of block proposals) from relays, automatically select the most valuable one using MEV-Boost, sign the payload, and return it to the relay. The relay then releases the full payload to the validator for final propagation to the Ethereum network.
MEV-Share
MEV-Share builds upon MEV-Boost by further unbundling the MEV Supply Chain. It allows users to selectively share data about their transactions with searchers who bid to include the transactions in bundles. Users can choose how the searcher’s bid is redistributed – between themselves, validators, or other parties.
Users send transactions to the MEV-Share Node with configured privacy preferences, preventing direct frontrunning by searchers. Searchers bid to include user transactions with potential MEV opportunities in their bundles, which are then sent to the MEV-Share Node. These bundles include hints, enabling the MEV-Share Node to match them with user transactions while preserving the searcher’s strategy.
The MEV-Share Node inserts private transactions into the bundles (specified by the searchers) and simulates them to identify bundles that successfully extract MEV. Any matched bundles are sent to builders along with a validity condition ensuring users receive payment for the MEV their transaction generates. Builders then create full blocks incorporating the bundles and distribute MEV payments to users as specified. Searchers’ profits remain untouched in this process.
This system benefits users by allowing them to earn additional profits from their transactions. It benefits searchers through several perspectives. First, this eliminates searcher’s needs to compete in the public mempool and engage in gas wars, which also benefits the entire ecosystem. Second, searchers only need to focus on a curated list of transactions. Third, searchers can protect their privacy, as their strategies are no longer exposed in the mempool for others to replicate, but revealed only if their transactions pass through MEV-Share and are submitted to a builder.
Oval
Oval is a protocol designed to help platforms like Aave capture MEV generated from Chainlink price updates. While similar to the Chainlink SVR mechanism discussed in this post, Oval differs in its approach. Oval proposed their solution for capturing OEV but did not passed on Temp Check Snapshot. In this post, we provide a brief discussion of Oval to give readers the necessary context.
On high level, Oval wraps oracle data and provides a venue for searchers to auction off the right to be the first to use it. Built on Flashbots’ MEV-Share, Oval selectively shares price updates and controls when they are released, ensuring the auction winner gets exclusive backrun rights and keeps their profit untouched (Liquidation Bonus Surplus - Bid). In addition, given the design of MEV-share, Oval controls how the searcher’s bid is redistributed among various parties, allocating a portion of it to the protocol (e.g., Aave).
The Oval workflow operates as follows: A price update from Chainlink is pushed onchain and visible to searchers in the mempool, allowing them to start bidding before mainnet inclusion. Searchers submit bids to the Oval node via its RPC endpoint. The Oval node receives the eth_sendBundle payload, prepends an unlockLatestValue transaction to the searcher’s bundle, and forwards the modified bundle [unlockLatestValueTx, searcherBundle] to MEV-Share using the mev_sendBundle method. MEV-Share then forwards these bundles to defined builders via the eth_sendBundle RPC method.
Builders process the bundles, run their standard block-building process, and, after the builder auction concludes, submit the completed block to the proposer. The builder must include refund instructions in the block, ensuring that most of the payment from the winning bundle is refunded to the protocol (e.g., Aave), typically directed to a multi-sig controlled by Aave DAO stakeholders and UMA.
Oval Architecture
Oval introduces potential concerns due to its lockWindow mechanism, which controls when the newest price becomes available. Oval tracks the last time unlockLatestValue was called. If it was called within the last lockWindow seconds, Oval returns the most recent price as of that call. If not, it provides the most recent source value that is at least lockWindow seconds old. This buffer time mitigates scenarios where the proposer for a given slot does not use mev-boost. In such cases, the system waits for one or two subsequent blocks (depending on the lockWindow configuration) for unlockLatestValue to be called, ensuring MEV-Share benefits are preserved—but at the cost of a delay.
Under stressed market conditions, however, the delay caused by the lockWindow mechanism could pose significant risks by preventing timely liquidations, potentially creating bad debt. A detailed analysis of the underlying causes and estimated impact of bad debt will be provided later in the discussion on Chainlink SVR.
Chainlink Smart Value Recapture:
Chainlink Smart Value Recapture is an oracle solution designed to help DeFi applications recapture non-toxic MEV generated from their use of Chainlink Price Feeds. Specifically tailored for backrunning in liquidation scenarios, Chainlink SVR cannot be used for toxic MEV activities such as frontrunning or sandwich attacks. According to Chainlink, SVR is expected to achieve a realistic value recapture rate of approximately 40%.
Chainlink employs the Dual Aggregator Price Feed design, allowing a single Chainlink Data DON to handle both the SVR Price Feed and the standard Price Feed in parallel. The oracle report sent to the SVR Price Feed is transmitted onchain via Flashbots MEV-Share, leveraging existing Chainlink contracts and interfaces to minimize integration burdens. Simultaneously, the same oracle report is transmitted onchain via the public mempool to the standard Price Feed.
If the SVR-enabled Price Feed fails to update via MEV-Share, the protocol relies on a fallback mechanism where the SVR feed retrieves the latest price from the Standard Price Feed after a configurable delay. This delay ensures reliability while preventing liquidators from immediately exploiting the Standard Price Feed data to bypass the value recapture mechanism provided by MEV-Share.
Dual Aggregator Price Feed
The overall flow of SVR works as follows: The Chainlink Data DON produces price reports and transmits them via two separate paths. One path sends the report to the Standard Price Feed through the public mempool. The other path transmits the report to the SVR Price Feed via a Flashbots Protect RPC endpoint.
Through MEV-Share, the SVR Price Feed selectively shares the price update with searchers, who bid for the opportunity to bundle the price update with backrunning liquidation transactions. Builders then include the highest bidder’s bundle in a block, allowing Aave and Chainlink to recapture most of the MEV generated during liquidation events. If no bids are received, the SVR Price Feed still publishes the price update on-chain without backrunning transactions.
In cases where MEV-Share fails, the SVR feed employs a fail-safe mechanism. After a configurable delay, the SVR feed retrieves the latest price from the Standard Price Feed and updates the protocol.
SVR Architecture
Chainlink SVR improves on Oval by eliminating the need for a middleman. While Oval acts as an external wrapper around oracles to facilitate OEV auctions, Chainlink SVR integrates directly into Chainlink’s infrastructure. This reduces centralization risks for Aave, as fewer intermediaries between the price aggregator and the protocol lower the chances of malicious actors exploiting OEV.
Expected Smart Value Recapture Risks
However, Chainlink SVR may still encounter similar issues as Oval, particularly those arising from price oracle delays. SVR feed updates may experience inclusion delays due to a subset of proposers who do not utilize MEV-Boost and, as a result, do not receive transactions submitted to MEV-Share endpoints. While SVR can be configured to fallback to the standard feed after a certain number of blocks, a nonzero delay must exist between updates to the standard feed and the SVR feed to prevent liquidators and searchers from bypassing the OEV auction. However, if this nonzero delay occurs during stressful market conditions, where asset prices experience rapid fluctuations at the block level, it could negatively impact the protocol—either directly by leading to bad debt or indirectly by increasing losses for liquidators.
Oracle Price Delay Probability
The likelihood of oracle price delays (the probability of consecutive non MEV-Boost blocks) directly determines the risk of bad debt. The probability of this delay follows a geometric distribution with a probability mass function described as follows:
Given the formula, as p , the percentage of the next block’s validator being connected to MEV-Boost, increases, the probability of consecutive block failures decreases exponentially. This behavior is depicted in the below chart, where higher values of p result in a rapid decline in failure probability across increasing block counts.
As of this writing, the p value stands at 90.38% for the past 14 days. We focus on the percentage of blocks adopting MEV-Boost, rather than the percentage of MEV-Share blocks, because a validator’s connection to MEV-Boost alone is sufficient to guarantee timely on-chain price updates. Specifically, if a searcher bids on the transaction, it will be included through the MEV-Share process and the price is updated accordingly. If no searcher bids, the price oracle report is still published on-chain, but without any backrunning or liquidation transactions. This occurs because the price is sent to the MEV-Share node and remains visible to any builder running MEV-Boost. Therefore, price oracle delays only occur when the subsequent block proposer is not connected to MEV-Boost. Given that MEV-Boost adoption currently stands at approximately 90.83%, this means that in the vast majority of cases, validators (proposers) can access and include the price update transaction via MEV-Share, ensuring a timely and reliable process.
As illustrated in the figure below, the market share of MEV-Boost has remained stable, consistently exceeding 85% since late 2022 and maintaining an average of approximately 90% throughout 2024. A deeper analysis of the data reveals occasional deviations, with MEV-Boost’s market share falling slightly below 90% in a few instances, reaching a minimum observed value of 86.6%. Based on this observation, we categorize the delay probability into two scenarios for analysis: a normal case, where p is set at 90%, and an extreme case, where p is set at 86%.
MEV-Boost Slot Share
Asset Selection & Price Volatility
To assess the potential emergence of bad debt due to delayed oracle price updates, we examined three representative assets currently listed on Aave Ethereum core market, as detailed below. We collect data on significant short-term price fluctuations for these assets and use this to evaluate whether such price movements, if occurring during the SVR Oracle Price Delay, would result in bad debt for Aave, and if so, estimate the expected magnitude of that bad debt.
| Assets |
Reserve Size on Aave Ethereum Core |
| BTC |
$3.77B |
| ETH |
$5.84B |
| LINK |
$325.17M |
For each selected asset, we collect the most extreme block-level price movements over consecutive six-block windows (~72 seconds), using data from Chainlink price feeds on Ethereum. For example, the chart below illustrates the update history of the Chainlink ETH/USD price feed on Ethereum. The largest observed price drop, recorded at 4.6%, corresponds to the largest price decrease over a 1-block delay, as detailed in the table below.
ETH
| Number of Falling Blocks (n) |
Largest Price Decrease |
Largest Price Increase |
| 1 |
-4.6400% |
4.5678% |
| 2 |
-9.0199% |
6.3128% |
| 3 |
-10.2854% |
7.2635% |
| 4 |
-11.9531% |
7.8299% |
| 5 |
-13.0705% |
9.1885% |
BTC
| Number of Falling Blocks (n) |
Largest Price Decrease |
Largest Price Increase |
| 1 |
-3.3782% |
1.4417% |
| 2 |
-4.6547% |
2.2176% |
| 3 |
-5.9239% |
2.7464% |
| 4 |
-6.5090% |
3.3955% |
| 5 |
-6.7660% |
3.7549% |
LINK
| Number of Falling Blocks (n) |
Largest Price Decrease |
Largest Price Increase |
| 1 |
-4.9655% |
5.0564% |
| 2 |
-7.1015% |
6.8521% |
| 3 |
-9.0214% |
7.9792% |
| 4 |
-11.0086% |
9.0741% |
| 5 |
-12.0514% |
10.1959% |
Expected Bad Debt Estimation
Bad Debt Formulation
A protocol primarily faces bad debt risks under two key scenarios: one where the borrowed asset price continuously increases during the delayed blocks and another where the collateral asset price continuously decreases during the delayed blocks.
Collateral Price Decrease During Oracle Delay:
In this scenario, the price change from block 0 to block 1 is not significant enough to trigger any liquidation, resulting in no searchers (liquidators) submitting bids in MEV-Share at that time. However, due to an oracle price delay, the updated price from block 1 is not released until after n blocks. During this period, the collateral price continues to decline significantly. By the time the delayed price update is finally released at block n+1, the collateral’s value has already fallen below the debt obligation, leaving liquidators without an incentive to act, ultimately causing bad debt for the protocol.
The formula is represented as follows:
Debt Price Increase During Oracle Delay:
In this scenario, the price change from Block 0 to Block 1 is not significant enough to trigger any liquidation, resulting in no searchers (liquidators) submitting bids in MEV-Share at that time. However, due to an oracle price delay, the updated price from Block 1 is not released until after n blocks. During this period, while the collateral price remains relatively stable or declines slightly, the price of the borrowed asset increases significantly. By the time the delayed price update is finally released at Block n+1, the debt obligation has grown substantially relative to the collateral value, leaving liquidators without an incentive to act, ultimately causing bad debt for the protocol.
The formula is represented as follows:
Bad Debt Estimation
To analyze the expected bad debt based on the defined formula, we applied the following methodology. First, all active wallets using the target asset as collateral are extracted at a defined snapshot time, filtering out those without outstanding debt. An oracle delay event is then simulated, assuming price updates are deferred for n blocks, during which the most extreme consecutive price movements are applied based on historical data.
For each wallet, the bad debt formula is used to determine whether the collateral remains sufficient for liquidation. The total uncollateralized debt across affected positions is then aggregated, and the expected bad debt exposure is computed by weighting these losses by the probability of an oracle delay lasting n blocks.
Below, we present the potential bad debt exposure for each collateral asset in the Aave V3 Ethereum Core Market as of March 12, 2025, under the assumption of an extreme price decline over a short period. We evaluate two probabilistic scenarios: (1) p = 90%, where each block has a 10% probability of experiencing an oracle delay, and (2) p = 86%, representing a more extreme assumption with a 14% probability of oracle delay per block.
WETH
| Number of Falling Blocks |
Max Bad Debt at n blocks |
Expected Bad Debt at n blocks (p = 90%) |
Expected Bad Debt at n blocks (p = 86%) |
| 1 |
$530.68 |
$53.07 |
$74.30 |
| 2 |
$191.02K |
$1.91K |
$3.74K |
| 3 |
$296.03K |
$296.03 |
$811.13 |
| 4 |
$443.48K |
$44.34 |
$168.52 |
| 5 |
$560.95K |
$5.61 |
$28.05 |
WBTC
| Number of Falling Blocks |
Max Bad Debt at n blocks |
Expected Bad Debt at n blocks (p = 90%) |
Expected Bad Debt at n blocks (p = 86%) |
| 1 |
$0.61 |
$0.06 |
$0.09 |
| 2 |
$0.66 |
$0.01 |
$0.01 |
| 3 |
$0.71 |
<$0.01 |
<$0.01 |
| 4 |
$0.73 |
<$0.01 |
<$0.01 |
| 5 |
$0.74 |
<$0.01 |
<$0.01 |
From our modeling results, among 9.5K wallets using WETH as collateral, only 218 wallets (2.29% of the total distribution) would be affected by a 1-block oracle price delay. This number increases to 338 wallets if the price delay persists for 5 blocks. For wallets using WBTC as collateral, out of 2.1K wallets, only 2 wallets (0.1% of the total distribution) would be impacted by a 1-block price delay. Similarly, among 1.1K wallets holding LINK as collateral, no wallets would be affected even in the case of a 5-block price delay.
Furthermore, the total expected bad debt for the protocol remains minimal under both normal (p = 90%) and extreme conditions (p = 86%). As of March 12, 2025, even if WETH experiences extreme price fluctuations accompanied by oracle price delays, under normal assumptions, the expected bad debt is less than $3K. In more severe scenarios, the expected bad debt would still be under $5K. WBTC and LINK are essentially unaffected by these conditions, indicating an insignificant financial risk to the protocol.
However, the results presented above provide only a preliminary estimation of potential bad debt exposure. Our modeling framework assumes that oracle price delays impact only a single asset per wallet, such as WETH, while keeping other collateral and debt asset prices constant. In reality, oracle delays are likely to affect multiple asset price feeds simultaneously. For example, multiple collateral assets within a single wallet may experience simultaneous price declines, or the debt asset price may increase while the collateral value drops during an oracle delay. Such conditions would significantly elevate the likelihood of bad debt accumulation. As a result, the actual bad debt incurred may exceed the projections derived from our current simulations.
We did not account for scenarios where the target asset, as a debt asset, undergoes a rapid price increase over a short period. Observations suggest that when WETH, WBTC, and LINK appreciate, most other market assets, including their corresponding collateral, tend to rise as well. As a result, assuming a price increase for debt assets while keeping collateral prices constant would introduce discrepancies between simulation outcomes and actual market conditions. In contrast, sharp declines in collateral asset prices are less affected by this type of modeling error, as a substantial portion of borrowed assets consists of stablecoins, making it a more relevant and independent scenario to analyze.
Further Considerations
LST & LRT
We also highlight a specific risk scenario for LSTs/LRTs, where bad debt may still occur even when the updated LTV ratio remains below 1/(1+LB). This is due to Aave’s pricing mechanism, which values LSTs/LRTs based on their internal exchange rate with the underlying asset rather than real-time market conditions.
For borrowers using LST/LRTs as collateral, their value decreases proportionally to the decline in the underlying asset’s price, following the protocol’s exchange rate model. However, if market liquidity is constrained, liquidators selling the seized collateral may experience a significant discount due to a lack of available buyers, resulting in a temporary depeg between the LST/LRT and its underlying asset. This depeg causes a discrepancy between Aave’s internally derived LST/LRT price and its actual market price, leading to a situation where the protocol prices LST/LRT collateral higher than what liquidators can recover in the market. Consequently, liquidators may face losses despite receiving a liquidation bonus, potentially reducing liquidation participation and increasing the protocol’s exposure to bad debt risks.
For these assets, we recommend conducting a separate risk assessment to evaluate the feasibility of implementing SVR, with peg stability as a key factor. If feasible, more conservative parameters must be established compared to standard assets to mitigate potential risks.
Oracle Extractable Value Calculation
Oracle Extractable Value (OEV) represents the profit a searcher can capture from the liquidation bonus surplus by backrunning liquidation transactions after an oracle price update. Therefore, the maximum OEV for each liquidation event should be determined based on the liquidation bonus of that specific event. Below, we present the formula for maximum OEV for each liquidation event i:
However, due to execution inefficiencies, revenue sharing among builders and searchers, and other factors, the actual OEV (adjusted OEV) is often lower than the maximum OEV. To quantitatively define both the maximum OEV and the adjusted OEV, we analyze Aave’s historical liquidation events. For each liquidation event, we determine the liquidation bonus—the maximum OEV—by calculating the difference between the liquidated collateral amount (normalized to USD) and the debt amount repaid by the liquidator (normalized to USD).
Next, to calculate the actual OEV, we collect the transaction hashes for each liquidation event. Using these transaction hashes, we query the ethereum.traces dataset to track all fund flows associated with the event and identify transactions where funds were sent to an MEV-Share Builder. These funds represent MEV profits captured by builders through searcher payments for order inclusion and execution priority, which would have otherwise been redirected to the protocol if an SVR mechanism had been in place. By summing these amounts across all identified transactions, we estimate the potential actual OEV that Aave could have captured.
Below, we present the cumulative maximum OEV and cumulative actual OEV from January 2024 to the present. The data demonstrates a strong correlation with market trends, as OEV fluctuations align with periods of heightened market volatility. Notably, in August 2024 and February 2025, sharp market movements led to an increase in liquidation events, driving a surge in OEV.
Below, we present the cumulative OEV capture rate over time. Since data collection began in January 2024, the initial cumulative capture rate appears high. However, in reality, the cumulative OEV capture rate has predominantly stabilized around 40%, with a low point of 38% and never exceeding 50%. This consistency provides a reasonable estimate of the actual OEV capture rate.
Additionally, the OEV capture rate is highly dependent on the size of the OEV generated in each liquidation event. As illustrated below, when the actual OEV in a liquidation event exceeds $1K, the average capture rate consistently remains above 50%, and can even reach up to 60%. In contrast, for liquidation events where the OEV is below $1K, the capture rate drops to 21.76%.
Different assets have demonstrated varying average capture rates, with a loose correlation to their Liquidation Bonus. Additionally, this analysis can be repeated in the future, following the launch of SVR in order to determine the optimal liquidation bonus for each asset.
Recommendation
Based on the analysis above, we support the implementation of Chainlink SVR. This integration introduces a new revenue stream for Aave. In 2024 alone, the estimated OEV revenue generated could reach approximately $14M. Additionally, the observed capture rate of around 40% to 50% ensures a sustainable and significant future income potential. Moreover, the financial risk associated with implementing SVR remains minimal. As demonstrated in our analysis, under current market conditions, if we assume scenarios where price delays coincide with extreme price fluctuations, the expected bad debt impact on the Aave Ethereum Core market from wallets using WETH, WBTC, and LINK as collateral is negligible.
Simultaneously, with the upcoming Aave V3.3 deployment, even if bad debt arises due to the implementation of SVR, it can be effectively mitigated by two key mechanisms. Firstly, the Position-Wide Close Factor (CF) which, in Aave V2 was fixed at 50%, limiting liquidations to half of a specific asset’s debt per event. Aave V3 introduced a dynamic CF that could increase to 100% if a user’s health factor dropped below 0.95, although it still applied on a per-asset basis. Aave V3.3 further refines this to a position-wide CF, allowing liquidators to apply the 50% CF across the entire debt position, thus significantly improving liquidation efficiency. Secondly, Deficit Management in Aave V3.3 automates the cleanup of bad debt through Umbrella, a governance-less slashing module. This new feature contrasts with previous versions where bad debt accrued interest and required manual intervention; V3.3 addresses this by immediately burning any remaining bad debt following full liquidation and recording the deficit at the reserve level, effectively preventing the indefinite accumulation of bad debt.
In light of the risks that SVR may present, we recommend the following mitigation measures:
First, a thorough volatility assessment for each asset is recommended before integrating SVR, as our analysis shows that the impact of price oracle delays on bad debt is directly proportional to an asset’s price volatility. For instance, ETH typically exhibits a relatively low expected loss due to its historical price stability. Even under extreme conditions, ETH’s price generally does not decrease by more than 10% within 1-2 blocks. If a delay of 3-5 blocks results in a total price drop of 13%, the expected loss remains manageable because the likelihood of experiencing consecutive invalid blocks is extremely low. Conversely, for assets with higher volatility, historical data may show that rapid price fluctuations exceeding 10% within 1-2 blocks are realistic. In such scenarios, even brief delays can lead to significant reductions in total collateral value, potentially triggering bad debts.
Second, adjusting the deviation threshold is a strategic method to mitigate risks associated with SVR. With a reduced deviation threshold, price updates are triggered more frequently, which allows the protocol to align more closely and continuously with actual market prices. This strategy minimizes the risk of significant discrepancies between the oracle-reported price and the market price at the time of liquidation. By facilitating more gradual and precise adjustments to the LTV, the system can more effectively anticipate and adapt to price changes, thereby reducing the likelihood of incurring SVR-induced bad debt.
Third, increasing the LB mitigates bad debt introduced by SVR but negatively impacts user experience. An alternative is reducing or removing the liquidation protocol fee for SVR-integrated assets, allowing liquidators to retain more profit without raising LB. However, this approach must be assessed on a per-asset basis, considering each asset’s capture rate. If an asset exhibits a high capture rate, increasing LB or removing liquidation protocol fee may be unnecessary, as the protocol can already generate substantial revenue from OEV recapture without imposing additional costs on borrowers.
Lastly, it is important to note that not all oracle price feeds, particularly those used for assets like LSTs, operate through Chainlink DONs. While Chainlink is developing a solution, the current design of the SVR does not support assets that rely on exchange rate feeds to trigger an auction when updated, meaning the potential OEV profit from these assets is currently uncollectible. However, based on our discussions about LSTs/LRTs, even if SVR is implemented for these assets in the future, we recommend conducting separate analyses to assess the feasibility of implementing SVR for these types of assets, with peg stability as a key factor. If feasible, it is also necessary to establish more conservative risk parameters compared to standard assets to accommodate additional risks.
