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 Api3 team regarding the proposed OEV solution and its potential integration into the Compound Protocol.
The assessment did not include a code review of the Api3 infrastructure.
Introduction
The RFP clearly outlines the motivation behind seeking an OEV vendor for the Compound Protocol. The assessment investigated the information provided by the Api3 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: Api3
Auction Mechanism: Hybrid on- and off-chain components
Compound Compatibility: FULL
Architecture
First-party oracles provide data via API. The price data from these providers is collected into what is referred to as a Beacon Set which aggregates the prices reported. The auction mechanism allows searchers to bid for the opportunity to update the dApp’s price feed on the target dApp’s chain with these real-time prices. The off-chain Auctioneer facilitates this via the on-chain OevAuctionHouse smart contract (currently deployed on the OEV network on Caldera).
The auction winner is provided with a cryptographic signature which is then used to update the oracle on the dApp’s target network within 30s of the signature being issued. Crucially, the auction winner is granted the ability to update the price feed to the real-time value multiple times within the 30 second window. Conversely, the update window is the longest a winning bidder can withhold an update. The searcher that bids must have 10% of the bid amount deposited as ETH on the OEV network (this gets slashed if update does not happen). If there are no bids, the oracle provider itself is expected to update the price feed according to the delay, heartbeat, and deviation configurations.
Trust Assumptions
The following trust assumptions were highlighted in the Api3 submission:
OEV Auctioneer: Off-chain component operated by Api3. It coordinates auctions and its conduct is verifiable through the OeVAuctionHouse contract.
Caldera: The OEV Network is hosted on Caldera at the time of this review. The auction mechanism, and by extension Compound Protocol, would implicitly rely on the network’s security characteristics.
Searchers: Searchers are incentivized to act upon updated price information, but there is a trust assumption that they will operate to their own benefit.
Auctions
The auction operates as a hybrid model with an on-chain component (OEVAuctionHouse) which is deployed to the OEV Network on Caldera. The off-chain Auctioneer service is operated by Api3. Auctions run on a 30-second cadence. Searchers place bids on-chain on the OEV Network and bids require 10% collateral to be posted in ETH. If a searcher wins the right to update the price feed, they need to act upon it within 30 seconds to avoid their collateral being slashed. The off-chain auctioneer selects the highest eligible bid and supplies the winner with the required cryptographic signature.
Governance Model
The on-chain OEV component that a Comet Market will integrate with is upgradeable. This upgrade is governed by a 4-of-8 multisig held by the Api3 team. The Api3 team maintains control of the multisig as an organization. Should an upgrade become necessary due to a security incident or planned maintenance, the Api3 team has committed to communicate this in advance to the DAO via the forum or direct communication with working groups where appropriate.
Historical Performance
Api3’s OEV mechanism has been in live production since November 2024 and is actively supporting over $270M in TVL for protocols like Yei Finance as of May 2025. The system has proven to be stable and reliable under extreme market volatility in early 2025, operating without causing any bad debt on integrated protocols. To date, the system has successfully captured over $325,000 in OEV, with more than $260,000 of that already distributed back to the protocols.
Audits
The on-chain components of the system have been audited and are available in the supplied audit repository at commit a550541.
Key Differentiators
A key consideration in this architecture is that price feeds are configured with a delay (currently 60s). However, should the price deviate sufficiently for an opportunity to arise, then the incentive is for the searcher to bid immediately and, should they be successful, update the asset used in the Comet Market’s price feed with the real-time price in order to capitalize on the opportunity. This searcher also has the ability to update the price multiple times within the 30 second window, further incentivizing timely updates during market volatility. Oracle providers are still expected to update the price feed based on its heartbeat and deviation configurations, albeit with the configured delay.
Consequently, during volatile market periods, the price feed may be updated as often as the specific network’s block speed allows, as the winning searcher can opt to do so for every opportunity arising within that update period (though they are not obligated to do so). The team has indicated that auction times (currently every 30s) and price feed delay (currently 60s) are configurable, and that special consideration should be given to the appropriate configurations for each price feed, taking into account the block speed of the target Comet’s network.
Further consideration should be given to the L2 (OEV Network) on which the auctions take place. The DAO may wish to negotiate a deployment to a chain with stronger security characteristics - the Api3 team has indicated that the auction mechanism is not locked into the OEV Network and is deployable on any other high-throughput chain. However, the trade-off would be that searchers would need to compete for blockspace with other non-OEV-related transactions.
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 | |
| ii) Identify actors Compound needs to trust | Yes | |
| iii) Outline potential issues and consequences | Yes | None noted |
| iv) Clarify who operates oracle nodes (team/third parties/decentralized) | Yes | First-party data provider partners |
| v) Describe consequences and mitigations for component misbehavior | Yes | |
| b) Audits | ||
| i) Provide links/summaries of completed audits | Yes | Repo provided |
| ii) Indicate if any parts are closed-source/proprietary | Yes | OEV Auctioneer is a closed-source, off-chain service |
| iii) Explain assurance methods for security | Yes | |
| c) Production Testing and Simulations | ||
| i) Detail how product testing has occurred | Yes | Working in production |
| ii) Specify if tested in major market volatility or only simulations | Yes | |
| iii) Provide post-mortem analyses and transparency examples | Yes | |
| iv) Describe issues encountered (if any) and resolution processes | Yes | |
| d) Oracle Accuracy and Manipulation Resistance | ||
| i) Explain mechanisms ensuring oracle price accuracy | Yes | |
| ii) Detail protection against malicious price manipulation | Yes | |
| e) Failure Modes | ||
| i) Thoroughly describe worst-case scenarios | Yes | |
| ii) Explain auction failure handling | Yes | |
| iii) Clarify if liquidations revert automatically to Compound by default | Yes | |
| iv) Specify risk periods without liquidation capability | Yes | |
| v) Walk through hypothetical “nightmare scenario” and mitigation | Yes | |
| f) Insurance and Recourse | ||
| i) Confirm availability of insurance or recourse | Yes | Willing to contribute revenue to insurance instrument |
| ii) Demonstrate willingness to establish an insurance fund | Yes | |
| iii) Explain the compensation process for incorrect liquidations/bad debt | Partial | No product available, but willing to engage with DAO |
| iv) Indicate if revenue allocation for insurance is proposed | Yes | |
| g) Upgrade and Maintenance Security | ||
| i) Explain governance for upgrades | Yes | |
| ii) Describe controls around contract/system updates | Yes | Integration documentation |
| iii) Provide details on communication protocols for changes | Yes | Provided in follow-up with the team |
| h) Responsible Disclosure | ||
| i) Confirm the existence of a responsible disclosure program | No | No responsible disclosure program |
| ii) Provide links or descriptions for bug bounties/guidelines | Partial | ToS |
| iii) Describe the internal disclosure process if no formal links are available | Yes | |
| i) Security Incident Monitoring and Management | ||
| i) Provide security incident management protocol | Yes | |
| ii) Explain incident communication with clients | Yes | |
| iii) Describe continuous monitoring practices | Yes | |
| j) Developer Support | ||
| i) Provide developer documentation and best practices links | Yes | |
| ii) Confirm developer support availability | Yes | |
| iii) Specify the support format provided | Yes | |
| iv) Provide contact details for proposal inquiries | Yes | |
| k) Real-time Metrics | ||
| i) Confirm provision of real-time metrics on liquidations/OEV | Yes | |
| ii) Explain data-sourcing methodology and metric calculation | Yes | |
| iii) Detail verification processes for DAO members | Yes | |
| iv) Clarify DAO metric-sharing approach | Yes | OEV dashboard and Monthly reports |
Conclusion
The reviewed submission supplied the information required as per the RFP issued on the Compound Forum. The Api3 OEV solution can be implemented within the Compound V3 Comet Markets with no changes to protocol contracts. Additional trust assumptions have been highlighted within the supplied document.
The review highlighted key areas of consideration, in particular the delayed nature of the base price feed. However, the mechanism design incentivizes price updates when liquidation opportunities arise and should support timely liquidations. In addition, there are configuration options relating to auction cadence and base price feed delay which should be carefully evaluated to ensure an optimal result for a given Comet Market.
No technical barriers were identified that could preclude integrating the Api3 OEV solution into a Comet Market on any supporting chain.
We would like to thank the Api3 team for their submission and their responses to our questions.