Request for Proposal (RFP): Oracle Extractable Value (OEV) Solution for Compound Protocol
Authors: Compound Governance Working Group (CGWG)
Motivation
Compound is seeking qualified vendors to submit proposals for Oracle Extractable Value (OEV) solutions that enable the protocol to recapture value lost during oracle-based liquidation events. The selected solution(s) will help Compound DAO reduce value leakage from the protocol to external parties such as block builders and liquidation bots, thereby recapturing revenue currently lost through MEV during oracle-triggered events across various environments (including Ethereum mainnet, Base, Arbitrum, Unichain, Optimism, Polygon, Mantle, Scroll, Ronin, and Linea).
Background
Compoundâs design relies on reliable price oracles to assess borrower health and trigger liquidations when loans fall below required collateralization thresholds. When such events occur, the protocol offers a liquidation incentive as a percentage of the repaid loan as compensation to third-party liquidators for retiring the bad debt.
While necessary to ensure solvency, this mechanism introduces an economic inefficiency: the value represented by liquidation bonuses is almost entirely extracted by off-chain actors such as arbitrage bots and block builders, who engage in mempool bidding wars or leverage order flow control to front-run profitable opportunities. This dynamic leads to what is known as OEV, the economic value created immediately after an oracle price update but captured externally, rather than accruing to the protocol or its stakeholders.
Over the past two years, Compound has paid out more than $13M in liquidation incentives across its v3 markets. A large portion of that value has ultimately gone to validators and searchers, representing a persistent leakage of value from the Compound system to external infrastructure providers. The DAO recognizes this as an addressable inefficiency, particularly given that this value is derived from Compoundâs design and risk framework but does not flow back to its treasury, lenders/borrows, or COMP holders.
Capturing OEV by introducing coordinated auction mechanisms presents an opportunity to restructure how value is extracted during liquidations. Doing so would reduce systemic leakage, improve protocol-level capital efficiency, and create a new revenue channel that can strengthen reserves or fund future growth initiatives. Several vendor teams (including API3, Chainlink, and RedStone) have begun developing solutions tailored to lending protocols, offering different tradeoffs in terms of latency, decentralization, cross-chain readiness, and revenue share. Dispersed OEV discussions have transpired during community calls and across the Compound forums, but this post is purposed to cohesively aggregate the intent of all of those conversations to establish a single source of information.
The Compound DAO is correspondingly initiating a formal evaluation process to select one or more OEV partners. This Request for Proposal (RFP) aims to solicit responses from qualified providers and guide the DAO in selecting a solutionâor set of solutionsâthat minimizes integration complexity, maximizes recaptured value, and maintains the protocolâs safety, responsiveness, and cross-chain reach across multiple markets.
Timeline & Order of Operations
The duration of this agreement with OEV vendors will last until the end of Q1 2026. The DAO will conduct a retrospective analysis of the program at the start of 2026, inspecting how well the solutions functioned in 2025. A subsequent selection of OEV providers will be put into effect after the evaluation period, or if the DAO decides that the status quo has been sufficient, the structure introduced via this RFP may sustain. The format of this second installment of providers may differ from the one proposed in the current RFP. This program will be revisited in Q1 2026 both to accommodate for innovations on vendorsâ OEV solutions as well as to assess the efficacy of the solutions selected for the current year.
The retrospective analysis will assess vendors based on, but not limited to, the following dimensions:
- Value recaptured by the protocol, net of vendor share.
- OEV solutionâs ability to respond during critical periodsâi.e. timeliness and completeness of liquidation execution, particularly during high-volatility or stressed conditions.
- System uptime, including the percentage of oracle updates and liquidation opportunities that were successfully auctioned and executed without fallback.
- Frequency and nature of fallback events, such as failed auctions or missed liquidations; vendors must disclose how often their system defaulted to a non-OEV mechanism and why.
- Transparency of incident reporting and mitigation, with a strong preference for vendors who maintain clear disclosures, postmortems, and support open-source observability tools.
We will coordinate with the selected vendors after conclusion of the on-chain votes to publish a running forum thread, containing periodic uptime and value capture metrics, along with timely incidence reports. A later portion of this RFP asks vendors to detail their reporting capabilities.
RFP Duration May 21 - June 4 (end of day, UTC):
- All vendors are meant to complete the âRequired Responsesâ section of this RFP in the current forum post.
- Failure to answer all of the above questions will automatically disqualify your proposal.
- After a proposal has been submitted by a team, the CGWG will check that all of the required questions have been thoughtfully answered, allowing the proposal to proceed to the OpenZeppelin review.
OpenZeppelin Review:
- After the 2-week submission period, the OpenZeppelin team will conduct a review of the qualified applicants, providing them and the DAO with an analysis of their assessed risks regarding the adoption of the given solutions.
Snapshot for OEV Solution Selection per Chain:
OEV provider coverage of each networkâs markets will be determined by multiple Snapshot votes. Delegates will have the opportunity to vote on which vendors they prefer to utilize on a per-chain basis. As the RFP and subsequent OpenZeppelin review conclude, we will publicize the optimal structure for how the Snapshot votes will be coordinated.
On-chain Vote & Implementation Coordination:
- The WOOF! team will work hand-in-hand with the favored vendors from the Snapshot vote to operationalize the actual implementation of the OEV solution(s) and the administration of the on-chain votes.
Scope of Proposals
Proposal should cover:
- Technical design and architecture of the OEV mechanism
- Integration plan with Compound V3 deployments
- Economic model and value sharing terms
- Cross-chain deployment support
- Security assumptions, audits, and risk mitigations
- Operational responsibilities and maintenance commitments
Please follow the order of questions provided in the below section under the three overarching categories: technical questions, economic considerations, and security/risk assessment.
For the sake of standardization, please reply to this forum post using the âRequired Responsesâ template:
- General Overview
- Background Questions
- Section 1: Technical Questions
- 1a)
- 1b)
- etc.
- Section 2: Economic Considerations
- 2a)
- etc.
- Section 3: Security and Risk Assessment
- 3a)
- etc.
Required Responses
General Overview
-
Company/Protocol Name and Brief Background:
-
List Existing Associations with Compound Protocol/DAO:
-
Explicitly list ALL of the chains that you are intending on applying for integration on (options include Ethereum mainnet, Base, Arbitrum, Unichain, Optimism, Polygon, Mantle, Scroll, Ronin, and Linea):
Section 1: Technical Questions
1a) Technical Overview:
Please provide a technical overview of the solution specifically as it relates to Compound. This description should cover the entire liquidation process. Please ensure that all components (on- and off-chain) are identified and all value accruals to actors within the system are explained.
1b) Integration & Compatibility:
What exactly is required to integrate your solution into Compound? For instance, do we simply change price feed addresses, or must we deploy new contracts or off-chain services? Please outline the deployment steps on each chain and whether any Compound contract upgrades are needed (maintaining no code changes is preferred).
1c) Fallback and Resilience:
In the event your auction process fails (no bids, infrastructure outage, etc.), what exactly happens? Weâd like to know the fallback logic in detail (e.g., âafter X seconds, we post the price normallyâ or âliquidation proceeds with standard bonusâ).
1d) Existing Price Feed Compatibility:
Does your OEV mechanism require replacing existing Chainlink price feeds entirely, or can it wrap/interleave with them? In the case of partial integration, how do you ensure seamless fallback to canonical price feeds in the event of malfunction?
1e) Auction Details:
Can you explain how the auction is run and how it is protected from manipulation? What safeguards are in place to ensure fairness, prevent bid manipulation or censorship, and mitigate risks such as coordinator bias, network latency, or timing-based exploitation like last-minute bid sniping? If your system involves a central relay, sequencer, or coordinator, whether on-chain or off-chain, how is it governed? Ultimately, why do you believe your auction design will reliably extract competitive value while minimizing operational and trust-related risks?
1f) Auction Timing & Block Coordination:
- How does your system determine when to initiate an auction? Is it based on deterministic thresholds, time intervals, or continuous monitoring of off-chain prices?
- How do you ensure that an oracle update and its corresponding liquidation are confirmed in the same block or atomically? If they land in separate blocks, how is consistency ensured and frontrunning avoided?
1g) Timeliness of Liquidations:
How does your auction mechanism ensure liquidations remain prompt? Specifically, what is the delay between a price crossing a threshold and the liquidation execution in your system? If there is a delay, why is that safe and how do you prevent that from causing any bad debt if prices continue to move?
1h) Latency Optimization Techniques
What techniques do you use to minimize the time between price deviation detection and auction completion? For off-chain systems, how do you mitigate API latency, relay delays, or bottlenecks in solver responsiveness? On chains with faster block times (like Arbitrum, Base), have you benchmarked auction speed and success rate? Please share any performance tuning insights.
1i) Auction Participation & Incentive Design:
How is the auction designed to encourage wide participation by liquidation bots or searchers? What measures have you taken to prevent bidder concentration or cartel behavior? Are there any incentives, like rebates or fee reductions, to onboard new participants and maintain auction competitiveness over time?
1j) Cross-Chain Operations:
How does your solution handle cross-chain deployments? Do you natively support all ten of Compoundâs target networks (Ethereum, Arbitrum, Base, Polygon, etc.) right now, or will some require development work? If not live on a chain yet, whatâs the tentative timeline? And will performance, like auction speed, differ on different chains (for instance, due to varying block times or absence of Flashbots on some networks)?
1k) Market Support & Asset Readiness:
For the chains that you are opting in for, please specify if your solution is not capable of supporting any of its constituent markets (defined as a borrowable asset and its supported collateral assets) on that given chain. Are there any assets for which you do not yet have reliable price feeds deployed? If so, please provide your expected deployment timeline or inability to accommodate a particular market.
1l) Emergency Controls:
Does your system allow the Compound DAO to disable or pause OEV auctions in the event of unexpected behavior, market stress, or a governance decision? Who has control over those mechanisms today, and how are they governed (via multisig, DAO vote, timelock)?
Section 2: Economic Considerations
2a) Revenue Split and Fees:
What is the proposed revenue share model between your platform and Compound DAO? Please specify:
- The base revenue split (e.g., 80/20, 90/10)
- Whether the split is fixed or dynamic across different markets
- Any creative or performance-based pricing models you can offer to make the proposal more attractive to Compound (e.g., tiered splits based on liquidation volume like 90/10 for <$1M/year, 80/20 for $1Mâ$5M/year, etc.)
2b) Additional Costs:
Apart from the value share, will Compound need to pay any subscription or service fees to use your oracles? If, for example, Compound adds new markets, will there be any cost to initiate new feeds?
2c) Expected Value Capture:
Based on your observations or deployments so far, what percentage of liquidation bonus do you expect to consistently capture for Compound?
- For example, Chainlink might cite ~40% from Aaveâs data, API3 might cite ~90%+ in smaller markets, etc. Provide any data or simulations to back this up. If possible, give projections for Compoundâs case, perhaps using past Compound liquidation data as a benchmark.
2d) Revenue Distribution & DAO Accounting:
How will the captured OEV be paid to Compound DAO? Is it automatically sent to a designated treasury address, or does it require manual claiming? What asset is the revenue in (ETH, stablecoins, native tokens)? How frequently can the DAO expect distributions, and can they be programmatically tracked for treasury accounting?
Section 3: Security and Risk Assessment
3a) Trust Assumptions:
Outline any new trust assumptions that Compound would be taking on by using your solution. For example, who are the actors we need to trust, and what could go wrong? Who operates the oracle nodes that your solution relies on for pricing data? Please specify whether these nodes are operated by your team, third parties, or a decentralized network. If one of your components misbehaved (oracle posting wrong data, coordinator censoring bids, etc.), what are the consequences and mitigations?
3b) Audits:
What audits have been completed on your OEV mechanism (and associated contracts/infrastructure)? Please provide links or summaries of findings. If certain parts are closed-source or proprietary (like some off-chain logic), how can we be assured of their security?
3c) Production Testing and Simulations:
How has your product undergone testing? Has your system been tested in production through major volatility or simply through simulations? Are there any post mortem analyses that you can link to your services being used elsewhere? Transparency is valued, even if minor issues occurred (perhaps a stalled auction that fell back to normal, etc.), describing them and how they were resolved will build trust.
3d) Oracle Accuracy and Manipulation Resistance:
Since these solutions involve the oracle layer, how do you ensure the price being used for liquidations is accurate and not manipulable? For example, could a malicious actor attempt to feed a wrong price to trigger liquidations in your system? Essentially, confirm that the OEV mechanism does not open up a backdoor for price spoofing attacks.
3e) Failure Modes:
Describe worst-case scenarios. For instance, what happens if your auction system completely fails during a period of extreme market volatility? Do liquidations revert to the normal Compound mechanism automatically? Will there be any period where liquidations cannot happen, which could cause bad debt? Each provider should walk through a hypothetical ânightmare scenarioâ and explain how their design copes with it.
- For example: âIf our coordinator node goes down, the next price update just comes on chain normally within N seconds, so at most N seconds delay.â
We want to be sure that no single failure can adversely affect Compound.
3f) Insurance and Recourse:
Do you offer any insurance or recourse if your system causes a loss to Compound? Are you willing to instate an insurance fund to cover events like an incorrect liquidation? For example, if a bug in your auction allowed an underpayment or prevented a necessary liquidation and Compound incurred bad debt, would your team compensate the DAO? Do you propose setting aside a portion of the overall revenue for insurance? While we hope such situations never occur, knowing your method of potential recourse upfront is important.
3g) Upgrade and Maintenance Security:
If your solution requires upgrading contracts or off-chain systems over time, how are those upgrades governed or managed? We want to avoid a scenario where a silent update on your side introduces a bug that affects Compound. So clarity on how changes are controlled and communicated is key.
3h) Responsible Disclosure:
Do you have a responsible disclosure program in place? Please provide links to any current bug bounties or responsible disclosure guidelines. If no official links are available, please describe how the responsible disclosure process is handled.
3i) Security Incident Monitoring and Management:
What is your current protocol for security incidents? Please provide links to, or describe, the way in which security incidents are handled and communicated to clients. How do you continuously monitor for security incidents?
3j) Developer Support:
Please provide links to your developer documentation and best practices. Do you provide developer support and, if so, what form does this take? Who is the contact person who can answer questions in relation to this proposal?
3k) Real-time Metrics:
Can you provide real-time metrics on liquidations and OEV extracted for the protocolâs benefit? If so, please explain how the data is sourced and the metrics calculated (i.e., how could this be independently verified by DAO members?). How would this be shared with the DAO?
Final Considerations
Is there anything about your approach that you believe weâve missed asking about? This can include anything that represents a competitive edge, unique design principle, or deeper alignment with Compoundâs architecture or mission?
Feel free to post a link to any relevant articles or videos describing your solutionâbut do answer all of the above questions in the provided setup and sequence on this forum page. Failure to answer all of the above questions will automatically disqualify your proposal. Please keep the final considerations section brief and to the point, if applicable.
) for taking ownership of the OEV discussion and creating a clear path forward for Compound to start recapturing this value. We know it takes real effort to coordinate all the moving parts here and itâs great to actually see that work paying off.
