Summary
Type: RFP Response Assessment
Timeline: From 2025-06-09 To 2025-06-16
Scope
The submission for assessment was received in the context of the Request for Proposal (RFP): Oracle Extractable Value (OEV) Solution for Compound Protocol issued on the Compound Forum. The assessment focused on the information submitted by the Chainlink team, as of June 4, 2025, at 9:39 PM, regarding the proposed OEV solution, commercially named Smart Value Recapture (SVR), and its potential integration into the Compound Protocol.
The assessment did not include a code review of the Chainlink SVR and other third-party infrastructural components that Chainlink relies on.
Introduction
The RFP clearly outlines the motivation behind seeking an OEV vendor for the Compound Protocol. The assessment investigated the information provided by the Chainlink team within their submission and evaluated the proposed solution for any security concerns within the context of intended integrations with Comet Markets.
Vendor Overview
Vendor Information
Vendor Name: Chainlink
Auction Mechanism: Off-chain Order Flow Auction (OFA)
Compound Compatibility: FULL
Architecture
The architectural components involved in the Chainlink SVR infrastructure are described below.
Off-Chain
- Decentralized Oracle Network (DON): A distributed collection of independent Chainlink oracle node operators responsible for fetching and aggregating data, coming to consensus, producing cryptographically signed oracle reports, and delivering oracle reports to an intended destination (on-chain or off-chain).
- Private OFA: SVR is modular and future-proof, designed to support multiple OFA providers, beginning with Flashbots’ MEV-Share. MEV-Share is a protocol that redistributes the value extracted from MEV back to the users who generate it. It enables Chainlink to share data related to price oracle update transactions with searchers, who then bid to include these transactions in bundles alongside profitable back-running transactions. This allows Chainlink to ensure that searchers include a distribution of the extracted MEV back to the protocol, specifically from the profits obtained from liquidations that can be triggered after the price update.
On-Chain Components
DualAggregator: An on-chain aggregator contract that stores both SVR Price Feed updates and standard feed updates. This contract provides users with the right price depending on whether they come through the normal FeedProxy or theOEVFeedProxy, and acts as a multiplexer for the SVR Price Feed or classical Chainlink Data Feeds.OEVFeedProxy: A proxy contract that points to the SVRDualAggregator, which has the same interface that Compound already uses.
Architecture Overview
The following high-level schematic representation of the core components and interactions of the SVR system is presented by the Chainlink team.
Trust Assumptions
In their submission, the Chainlink team states that since Compound already uses Chainlink Data Feeds to secure its total TVL, and because SVR is presented as an extension of these feeds with an on-chain fallback mechanism (implemented in the DualAggregator immutable contract), there are no additional trust assumptions beyond the current reliability and security of the existing Chainlink Data Feeds. Trust in the SVR infrastructure is considered minimal due to an automatic fallback mechanism used as a safety net. In the event of an SVR failure (threshold detection for this is configurable through an on-chain parameter in terms of blocks delay), the liquidation process would revert back to how existing liquidations occur in non-SVR-activated Compound markets. Additionally, the team states that they provide an option for Compound to revert back to standard Data Feeds manually (e.g., via a DAO vote or admin action) at any time.
Both SVR and classical price Data Feeds originate from the Chainlink DON. Consequently, there are no new trust assumptions regarding data origin.
Auctions
SVR relies on existing off-chain OFA providers. The Chainlink team states that initial support includes Flashbots’ MEV-Share. It is important to note that MEV-Share is an OFA mechanism that is specifically tied to MEV-Boost and the architecture of the Ethereum core protocol. While the Chainlink team mentions that multichain capabilities are planned for short/mid-term deployment, they have not specified which OFA solutions will be used on each supported chain. In any case, MEV-Share can only be used as SVR’s OFA exclusively on Ethereum mainnet, and any other OFA solutions used in other chains will introduce different trust assumptions.
Governance Model
The Chainlink team states that the upgradability processes for SVR Feeds follow the same standard practices as those for the existing Data Feeds used by the Compound protocol. Therefore, there should be no additional trust assumptions in this matter.
Historical Performance
SVR is currently being used in production on Aave V3 Core and Prime markets on Ethereum, with market data starting from the beginning of April 2025. More data can be found on the SVR data visualization dashboard. So far, its production usage has resulted in zero bad debt accrual. While the Chainlink team states that SVR covered a price range of $74K–$100K in BTC/USD, including periods of heightened market volatility, we believe there is lack of performance data from scenarios of extreme volatility due to limited production history.
Audits
Chainlink team states that the NCC Group conducted an audit of Chainlink SVR in November 2024, focusing on the changes introduced between the original OCR2Aggregator.sol and the updated DualAggregator.sol at commit ee7f7ad. However, the report of this audit has not been provided to OpenZeppelin team.
Key Differentiators
A key consideration of the Chainlink OEV proposal is that its application adds minimal trust assumptions on top of those of the current Compound market price oracles. The existing mechanisms will be configured as a security fallback for the SVR. The Chainlink team has described an OEV solution that is currently only applicable to Compound mainnet markets.
In addition, SVR relies on a fully off-chain OFA, with no on-chain auction components. This model necessitates trusting the integrity of multiple parties within the OFA supply chain. Nonetheless, since the majority of the computation is relayed off-chain, the gas costs associated with liquidations are generally reduced.
Requested Security and Risk Assessment Responses Checklist
The following table evaluates each of the specific responses given by the OEV vendor to the questions related to security/risk assessment requested by the Compound Governance Working Group.
| Data Required (Question) | Supplied | Comment |
|---|---|---|
| a) Trust Assumptions | ||
| i) List new trust assumptions Compound would take on | Yes | No additional trust assumptions on top of currently used Data Feeds. |
| ii) Identify actors Compound needs to trust | Yes | Data Feeds and the decentralized oracle networks that power those feeds, Trust in the OFA infrastructure is minimized through the automatic fallback mechanism. |
| iii) Outline potential issues and consequences | Yes | Situations where the OFA fails to operate as expected, SVR’s recapture efficiency would decrease or Compound would fall back to using standard Data Feeds. |
| iv) Clarify who operates oracle nodes (team/third parties/decentralized) | Yes | Decentralized DON nodes operators. |
| v) Describe consequences and mitigations for component misbehavior | Yes | The same security that applies to the existing Data Feeds used by Compound also applies to SVR Feeds. |
| b) Audits | ||
| i) Provide links/summaries of completed audits | Yes | Code audits and summaries of findings have been highlighted, but reports have not been provided. |
| ii) Indicate if any parts are closed-source/proprietary | Yes | The Chainlink node software, the DualAggregator contract, and the Flashbots’ MEV-share code are open-source, nonetheless, the latter two apply only to the mainnet instance of SVR. |
| iii) Explain assurance methods for security | Yes | Battle tested Chainlink data feed code as an emergency fallback. |
| c) Production Testing and Simulations | ||
| i) Detail how product testing has occurred | Yes | Currently being used in production on Aave V3 Core and Prime markets on Ethereum mainnet, covering ~30% of Aave’s TVL on Ethereum. |
| ii) Specify if tested in major market volatility or only simulations | Yes | Tested in real markets since April 2025. |
| iii) Provide post-mortem analyses and transparency examples | Yes | A SVR data visualization dashboard is provided. |
| iv) Describe issues encountered (if any) and resolution processes | Yes | Zero bad debt accrual in Aave markets during the usage period. |
| d) Oracle Accuracy and Manipulation Resistance | ||
| i) Explain mechanisms ensuring oracle price accuracy | Yes | SVR Feeds use the same Chainlink DON infrastructure that secures the existing Data Feeds. |
| ii) Detail protection against malicious price manipulation | Yes | Data Feeds, including SVR Feeds, leverage multiple layers of decentralized data aggregation at the data provider, node operator, and network levels to mitigate central points of failure and manipulation. |
| iii) Confirm no backdoor for price spoofing exists | Yes | Oracle reports are cryptographically signed by a quorum of independent node operators and validated on-chain before any price oracle reports can be made available to consuming protocols. |
| e) Failure Modes | ||
| i) Thoroughly describe worst-case scenarios | Yes | Not thoroughly described. |
| ii) Explain auction failure handling | Yes | In the event of an auction or transmission failure of the DualAggregator contract will fall back to providing data from standard Data Feeds. |
| iii) Clarify if liquidations revert automatically to Compound default | Yes | The fallback price source is the standard Data Feeds, which are currently the default in Compound. |
| iv) Specify risk periods without liquidation capability | Yes | The maximum block delay before falling back to default Data Fees is configurable via an on-chain parameter. |
| v) Walk through hypothetical “nightmare scenario” and mitigation | No | |
| f) Insurance and Recourse | ||
| i) Confirm availability of insurance or recourse | Yes | Insurance fund not proposed. |
| ii) Specify willingness to establish insurance fund | Yes | Open to discussion. |
| iii) Explain compensation process for incorrect liquidations/bad debt | No | |
| iv) Indicate if revenue allocation for insurance is proposed | No | |
| g) Upgrade and Maintenance Security | ||
| i) Explain governance for upgrades | Yes | Not detailed, same standard practices used for existing Data Feeds. |
| ii) Describe controls around contract/system updates | Yes | Not detailed, same standard practices used for existing Data Feeds. |
| iii) Provide details on communication protocols for changes | No | |
| h) Responsible Disclosure | ||
| i) Confirm existence of responsible disclosure program | Yes | Immunefi and Hacker One with a maximum bounty reward of $3M. |
| ii) Provide links or descriptions for bug bounties/guidelines | Yes | Immunefi and Hacker One. |
| iii) Describe internal disclosure process if no formal links available | N/A | |
| i) Security Incident Monitoring and Management | ||
| i) Provide security incident management protocol | Yes | Real-time monitoring and alerting for all the DONs, OFA streams, and on-chain activity. |
| ii) Explain incident communication with clients | No | |
| iii) Describe continuous monitoring practices | Yes | SVR Feeds are supported by 23/7/365 on-call rotations with subject matter experts. |
| j) Developer Support | ||
| i) Provide developer documentation and best practices links | Yes | Smart Value Recapture (SVR) Feeds Chainlink Documentation. |
| ii) Confirm developer support availability | Yes | A dedicated team at Chainlink Labs on call is in contact with the relevant parties in the Compound community. |
| iii) Specify support format provided | Yes | Chainlink documentation webpage. |
| iv) Provide contact details for proposal inquiries | Yes | On Telegram at @CL_Raoul and @ash_cll. |
| k) Real-time Metrics | ||
| i) Confirm provision of real-time metrics on liquidations/OEV | Yes | Values proposed: Recapture Chance (%), Recapture Rate (%), Total collateral liquidated, Total liquidation bonus, Total value recaptured and Number of liquidations. |
| ii) Explain data sourcing methodology and metric calculation | Yes | Metrics derived from on-chain data via transaction logs. |
| iii) Detail verification processes for DAO members | Yes | Validity can be verified by independently calculating the same metrics using on-chain data. |
| iv) Clarify DAO metrics sharing approach | Yes | Plans to create a near real-time dashboard. |
Conclusion
In summary, Chainlink’s Smart Value Recapture (SVR) is a compelling extension of its existing Data Feeds. Its architecture, though technically detailed only for mainnet markets at the moment, leverages a DualAggregator contract to ensure a reliable fallback to standard Data Feeds in case of failure, minimizing new trust assumptions. While the system has performed well on Aave V3 since April 2025, it lacks exposure to extreme market scenarios. The formal code audit report from NCC Group was not supplied for this assessment.
Overall, Chainlink thoroughly addressed the security and risk checklist. The primary considerations for Compound remain SVR’s limited production history, the missing audit report, and the fact that multichain implementation details are not yet fully specified.
We would like to thank the Chainlink team for their submission and their responses to our questions.
