Smart Value Recapture (SVR) Feeds
Chainlink Smart Value Recapture (SVR) Feeds introduce a novel and secure way to recapture Oracle Extractable Value (OEV)—a subset of non-toxic Maximal Extractable Value (MEV) associated with oracle updates that is most commonly observed during the liquidation process of lending protocols. The value recaptured by SVR provides DeFi protocols with an additional revenue stream while also supporting the economic sustainability of Chainlink oracle. SVR Feeds are read in the same manner as standard Chainlink Data Feeds (see Using Data Feeds), and simply require that users specify an SVR-enabled feed address.
Understanding MEV and OEV
Maximal Extractable Value (MEV)
Maximal Extractable Value (MEV) refers to the value derived from the ability of block proposers (e.g., validators) to include, exclude, or change the order of transactions in the blocks they produce. Specialized searchers typically identify MEV opportunities, such as liquidation or arbitrage, and bid for optimal inclusion in the block via a competitive auction. The value is then captured by the participants of the block building process such as searchers, builders, and validators.
Oracle Extractable Value (OEV)
Oracle Extractable Value (OEV) refers to a subset of MEV created during the transmission of oracle reports onchain and their subsequent consumption by onchain applications. For example, when a price oracle report reveals that a collateralized position is at-risk and eligible for liquidation, searchers compete to place a liquidation transaction immediately after the oracle update transaction (a process known as backrunning). Because oracles supply these price updates, the resulting liquidation MEV is inherently "oracle-related".
Chainlink Smart Value Recapture (SVR)
Chainlink Smart Value Recapture (SVR) extends standard Chainlink Price Feeds with an optional private transmission flow. By sending oracle updates through a dual aggregator architecture, SVR enables an auction for the opportunity to backrun liquidations. This approach enables non-toxic MEV recapture, where the DeFi protocol and the Chainlink Network share in the payment offered by the searcher for the right to backrun the liquidation instead of letting it leak entirely to third parties.
Why Use SVR?
-
Targeted at Liquidations (Non-Toxic MEV Capture)
SVR is purpose-built for recapturing non-toxic liquidation-related OEV via backrunning and cannot be used for harmful forms of MEV such as frontrunning or sandwich attacks. -
Minimal Integration Changes
Chainlink SVR Feeds maintain the same aggregator interface and data structure as standard Chainlink Price Feeds. Most protocols can simply point to the new SVR contracts with minimal changes required. -
Economic Sustainability
By recapturing OEV that would have otherwise been leaked to third parties, SVR helps support the economic sustainability of the DeFi ecosystem. Recaptured OEV revenue is split between integrating DeFi protocols and the Chainlink Network at a standard rate. -
Fallback Security
Chainlink SVR uses standard Price Feeds as a fallback, ensuring pricing data is continually made available to protocols via the public mempool in situations where the private route (e.g., Flashbots) fails. -
Proven Oracle Infrastructure
Chainlink SVR is built on the Chainlink Decentralized Oracle Network (DON) infrastructure that has already helped secure tens of billions in DeFi TVL and underpins existing Chainlink Data Feeds.
How SVR Works

-
Dual Transmission
- (1a) Standard Feed (Public Route): The Chainlink Data DON (triggered by a heartbeat or deviation threshold) sends a price report to the Standard Aggregator via the public mempool—this is the traditional Chainlink flow. If anything goes wrong with the private route, the system can still rely on the standard aggregator's updates.
- (1b) SVR Feed (Private Route): Simultaneously, the Data DON sends the same price report to the SVR Aggregator through a private channel (e.g., Flashbots MEV-Share). This private route creates an auction for liquidations.
-
MEV-Share Auction
- (2) Liquidation Bid: In the private channel, searchers see the incoming oracle report and bid to backrun the price update with a liquidation transaction. Builders select the highest bid, bundling that liquidation in the same block. If no bid is placed, the price update can still be published onchain without any bundled liquidation. If not, the fallback in the dual aggregator is triggered.
-
SVR Update and Liquidation
- (3a) SVR Price Report: The winning bundle is published onchain, and the SVR Feed is updated with the new price.
- (3b) Liquidation Execution: In the same block, the backrunning transaction can use the freshly updated price to liquidate the undercollateralized position. The oracle-related MEV can thereby be partly recaptured by the DeFi protocol and the Chainlink Network.
-
Token Price Consumption
- (4) DeFi Protocol: The updated price from the SVR Feed is now available to the DeFi protocol (e.g., Aave) for accurate liquidation logic or other price-dependent actions.
Fail-Safe Fallback Mechanism
If the private route fails or times out, the SVR feed automatically reverts to the Standard Feed price after a configurable delay. This delay can be set to any amount of seconds. This helps ensures the feed doesn’t stall and that price data is accessible through the public route if the private channel is unavailable.
How Protocols Can Utilize SVR Feeds
1. Identify the SVR Feed Address
To get started, please fill out this form to ensure protocol compatibility and proper recapture of OEV revenue. In many situations, you only need to point your protocol to an SVR version of the Chainlink Price Feed. To find the correct address for the asset pair you wish to secure with SVR, visit the Feed Addresses page and filter the feeds to display only SVR feeds.
2. Read from the SVR Feed
In your smart contract, import and reference the AggregatorV3Interface just as you normally would, but use the SVR aggregator's address.
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";
contract SVRConsumer {
AggregatorV3Interface internal svrFeed;
constructor(address _svrFeedAddress) {
svrFeed = AggregatorV3Interface(_svrFeedAddress);
}
function getLatestPrice() public view returns (int256) {
(
,
/* uint80 roundID */ int256 price /* uint256 startedAt */ /* uint256 timeStamp */ /* uint80 answeredInRound */,
,
,
) = svrFeed.latestRoundData();
return price;
}
}
This code sample is essentially the same as reading from a standard Chainlink Price Feed. For more details, see Using Data Feeds.
Searcher Guide to Chainlink SVR
This guide explains how to identify and bid on Chainlink SVR liquidation opportunities through Flashbots MEV-Share. SVR Feeds support a private transmission channel for oracle price updates, enabling searchers to backrun new prices with liquidation transactions and compete for profit.
Why Chainlink SVR?
Traditional MEV searching depends on spotting oracle price updates in the public mempool. With SVR, new price reports are shared in a private mempool via Flashbots MEV-Share. Searchers place bids to include liquidation transactions directly after the price update in the same block. The highest bidder gets included, capturing the liquidation bonus while sharing part of the winning bid with the DeFi protocol (e.g., Aave) and the Chainlink Network.
Example Application: Aave Liquidations
Aave is a lending protocol where collateralized positions must remain above a threshold called their health factor. When an oracle price update reveals a borrower is undercollateralized, the position becomes eligible for liquidation. The searcher liquidates the position in exchange for a liquidation bonus reward. With Chainlink SVR, a searcher's liquidation transaction can be bundled with the new SVR price update through Flashbots.
For more background on how Aave liquidations work, see Aave Documentation. To understand how Chainlink SVR adds a structured auction for these Aave liquidation opportunities, read the following sections.
1. High-Level Steps for Searchers
-
Monitor SVR Price Updates: Chainlink SVR sends oracle reports through Flashbots Protect (MEV-Share). Your searcher node must watch private transactions, not just the public mempool.
-
Bundle and Bid
- Detect an eligible liquidation (e.g., an undercollateralized Aave position) triggered by the new price update.
- Submit your liquidation transaction in the same bundle as the price update, placing a bid to entice block builders.
-
Execute Liquidation: If your bundle is selected, your liquidation happens immediately after the fresh price arrives onchain, capturing the liquidation bonus. Based on the results of the auction, a portion of the MEV is recaptured and split between Aave and the Chainlink Network, while the rest goes to you.
2. Detecting SVR Transactions
Chainlink SVR uses forwarder contracts to route feed updates. You typically see one transaction per event, which calls the function forward(address to, bytes callData)
with the function selector 6fadcf72
. This method, in turn, calls the SVR aggregato's transmitSecondary()
function with the new price data.
-
Forwarder Contracts: Each Node Operator Proxy has a unique forwarder contract. That means that feed update transactions may come from different forwarder addresses depending on which proxy sends the transaction.
-
Function Selector: In the transaction's
txs
array, look for the selector6fadcf72
(forward(...)
). -
callData: The
callData
includes the parameters fortransmitSecondary()
on the aggregator contract. You can decode this if you need to extract the updated price when the onchain event is not emitted (details in the section below).
3. Decoding the Price Update
3.1. Decoding From Event Logs
In most cases, when the SVR aggregator's price update arrives, an AnswerUpdated(int256 indexed current, uint256 indexed roundId, uint256 updatedAt)
event is emitted in the aggregator contract logs.
You can parse:
address
of the aggregator contract (feed)topics[1]
for the updated price (encoded as abig.Int
orint256
)
Example:
{
"address": "0xb123c2e3a71b57f9678cf6212576f30d642ed89a",
"topics": [
"0x0559884fd3a460db3073b7fc896cc77986f16e378210ded43186175bf646fc5f",
"0x00000000000000000000000000000000000000000000000000000888c6950a3b",
"0x000000000000000000000000000000000000000000000000000000000000021e"
],
"data": "0x00000000000000000000000000000000000000000000000000000000677fbf43"
}
Where topics[1] = 0x00000000000000000000000000000000000000000000000000000888c6950a3b
decodes to 9383540230715
, or $93,835.40230715, depending on feed decimals.
When you see this AnswerUpdated
event in the logs, you can directly read the updated price.
3.2. Decoding From CallData (If Event Is Missing)
If AnswerUpdated()
Is Missing
Sometimes, the transaction may arrive via the “primary path” before the aggregator emits the event, so the logs won't contain AnswerUpdated()
. In that case, you can still decode the new price from the callData
that calls:
transmitSecondary(
bytes32[3] calldata reportContext,
bytes calldata report,
bytes32[] calldata rs,
bytes32[] calldata ss,
bytes32 rawVs
)
Inside the report
, you'll find the updated median price in the field:
report.observations[report.observations.length / 2]
The structure of report is:
struct Report {
int192 juelsPerFeeCoin;
uint32 observationsTimestamp;
bytes observers;
int192[] observations;
}
4. Bidding With Flashbots MEV-Share
- Private Mempool: Your bid and transaction remain private until included onchain.
- Bundles: You group the price update and your liquidation transaction so that they execute atomically.
- Bidding: Builders typically select the highest bidder; you must propose a profitable split to stand out.
- Backruns Only: MEV-Share currently only allows backruns, so your liquidation must come after the price update.
For gas management, simulations, and other advanced usage, see the official Flashbots documentation.
5. Considerations
- Competition: Multiple searchers might detect the same liquidation. The best bid typically wins.
- Profit-Sharing: A portion of liquidation MEV is recaptured and redirected to the integrating DeFi protocol and the Chainlink Network.
- Gas Efficiency: Bundles that are too costly might erode the profitability of the proposed transaction. Optimize carefully.
6. Next Steps for Searchers
-
Set Up Your Searcher Node
- Integrate with Flashbots MEV-Share to read private transactions.
- Filter for calls matching function selector
6fadcf72
directed at the correct contract address.
-
Test Your Bundles
- Construct atomic bundles combining the price update and your liquidation transaction.
- Try local simulations or testnet deployments where available.
-
Stay Updated
- Keep track of any updates to the SVR aggregator address, function signatures, or Flashbots MEV-Share changes.
- Monitor for changes in Aave liquidation parameters (e.g., new assets, different collateral thresholds).
Economics and Revenue Split
When a protocol integrates Chainlink SVR Feeds, the recaptured oracle-related MEV is split following a 60/40 rate:
- 60% for the integrating DeFi protocol
- 40% for the Chainlink Network
This split provides DeFi protocols with an additional revenue stream while also supporting the economic sustainability of Chainlink oracles. Note that these values may be subject to change, with the goal of generating sustainable economics between DeFi protocols and the oracles that power them.
Risk and Disclaimers
- Delay Risks: SVR introduces a small, configurable delay to allow for the MEV-Share auction. In the unlikely event of a private-route failure, the dual aggregator reverts to the standard feed price update after a delay. To learn more about delay risks, and how you can parameterize your protocol to account for them, refer to this research blog.
- Liquidation Competition: Multiple liquidations triggered by the same price update compete for blockspace. SVR is agnostic to which liquidator wins. SVR maximizes for the highest payment, and thus the highest recapture rate, on the auction.
- MEV Does Not Disappear: SVR recaptures only the oracle-related portion of MEV. Protocol builders should remain MEV-aware when designing their applications.
- Dynamic Recapture Rates: SVR aims to recapture as high a portion of oracle-update-related MEV as possible. Actual results depend on market conditions, competition among searchers, and factors such as protocol design.