OEV RFP Process Update (July 2025)

Background

The original RFP took place between May 21 - June 4.

A total of 3 submissions were posted:

The OpenZeppelin review posts are listed below—each vendor has replied briefly to their respective OZ feedback to incorporate holistic commentary:

We ask delegates to carefully consider all three of the OEV solutions carefully, from both an implementation/security perspective, as well as with a financial viewpoint. Each RFP response comprehensively lays out all of these variables. Please feel free to reach out if you have questions.

Prior to the RFP taking place, the WOOF team also submitted a review of the above solutions. If delegates would like more information, this analysis may also prove helpful. Note that the most up-to-date analyses are the OpenZeppelin reviews and the direct responses submitted by the vendors themselves.

Upcoming Operations

Step 1: Delegate Review Period & OEV Edits

Dates: June 4 - July 4 @ 11:59pm UTC

Since the RFP submission phase concluded, delegates have been urged to spend some time reviewing the OEV solutions presented by the three vendors. Since last week, they’ve also had access to recommendations by OZ, and vendors have had time to respond to the given feedback. Delegates—please reference the links at the top of this document to conduct your final analysis of the various OEV options.

Step 2: Snapshot Votes

Dates: July 5 - July 11 @ 11:59pm UTC

Approximately a week will be allotted to the Snapshot phase.

The RFP indicated that vendors would be able to apply for incorporation on any of the following chains: Ethereum mainnet, Base, Arbitrum, Unichain, Optimism, Polygon, Mantle, Scroll, Ronin, and Linea. Each of these 10 chains warrants its own Snapshot vote, therefore, 10 concurrent votes will be posted to Snapshot for delegates to review.

A particular Snapshot vote will be considered valid as long as quorum (the total number of votes submitted, excluding the AGAINST votes, denoted as “Do NOT adopt OEV”) reaches the on-chain threshold of 400k COMP. If quorum is reached, then the winner will be determined by a simple majority. In the event that quorum is not reached for a Snapshot vote, the respective chain will not adopt any of the OEV options, defaulting to the existing status quo.

“Weighted Voting” will be utilized, where each delegate has the ability to spread their voting power across any number of choices. This voting system allows delegates to select between multiple options—or simply allocate their entire voting power to a single vendor.

Below are the chains that each vendor applied to:

  • RedStone: Unichain, Polygon, Base, Arbitrum, Optimism
  • Api3: ALL listed chains
  • Chainlink: ALL listed chains

For the sake of simplicity and efficiency, each chain will only adopt ONE—or none—of the OEV solutions. A per market adoption will not be considered since such a level of granularity is difficult to monitor and organize, causing unwarranted overhead. A-B testing between different OEV solutions, and across various markets on separate chains, is also not an easy task. Market dynamics and technical variances across different chains and markets are not easily generalizable—and therefore make one-to-one comparisons difficult.

Each of the vendors also indicated that they would be able to support every market on each of their selected chains, therefore, from a technical integration standpoint, there shouldn’t be an issue around full chain support by a single vendor.

——————————————————————

Below is the setup for the Snapshot vote related to Ethereum Mainnet:

//

Title: Adopt an OEV Solution on Ethereum Mainnet

Voting Options:

  • Adopt Api3
  • Adopt Chainlink SVR
  • Do NOT adopt OEV

//

**RedStone did NOT apply for the Ethereum markets. The Api3 and Chainlink SVR solutions are ready to be adopted on mainnet if opted in by the DAO.
**Chainlink feeds are currently utilized by Compound on Ethereum Mainnet.

——————————————————————

Below is the setup for the Snapshot votes related to Unichain, Polygon, Base, Arbitrum, Optimism:

//

Title: Adopt an OEV Solution on [see above chains]

Voting Options:

  • Adopt RedStone
  • Adopt Api3
  • Adopt Chainlink SVR (phased rollout, chain by chain)
  • Do NOT adopt OEV

//

**All vendors have applied to the above 5 chains. Note that Chainlink SVR is NOT yet live on L2s—they are proposing a phase rollout plan for the DAO to consider. In the coming weeks, SVR will be available on Base, and shortly after, on Arbitrum, too. Other L2s will have SVR rollout over time. We are enabling the DAO to wait for Chainlink to roll out their OEV solution on alternative chains as a potential voting option. Once Chainlink launches on these L2s, they will update the DAO accordingly, and their solution will undergo an additional review, just like the above OZ analyses. Incorporation of Chainlink on L2s will require another Snapshot vote.

**Note that RedStone “can support any EVM chain in a maximum of a 2 week timeframe” but their OEV solution is also NOT live on any L2s yet.

**Api3 is able to offer a near immediate integration, as was evidenced by their existing incorporation onto Mantle.

**As mentioned in the original 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.” Accordingly, the DAO is allowed to vote on specific vendors now—and wait until Q1 2026 to reevaluate the existing options.

**Chainlink feeds are currently utilized by Compound on Base, Arbitrum, Optimism, Polygon.

**RedStone feeds are currently utilized by Compound on Unichain.

——————————————————————

Below is the setup for the Snapshot vote related to Mantle

//

Title: Adopt an OEV Solution on Mantle

Voting Options:

  • Keep Api3 OEV (current setup)
  • Adopt Chainlink SVR (phased rollout)

//

**Compound on Mantle currently utilizes Api3’s OEV solution—so the status quo vote for the Mantle Snapshot will be “Keep Api3 OEV” as opposed to “Do NOT adopt OEV.”

——————————————————————

Below is the setup for the Snapshot vote related to Scroll, Ronin, and Linea

//

Title: Adopt an OEV Solution on [see above chains]

Voting Options:

  • Adopt Api3
  • Adopt Chainlink SVR (phased rollout, chain by chain)
  • Do NOT adopt OEV

//

**Again, Chainlink SVR will follow a phased approach as opposed to immediate integration, and Api3 is able to accommodate near immediate integration.

**Chainlink feeds are currently utilized by Compound on Scroll, Ronin, and Linea.

Step 3: On-chain Votes Coordination & Implementation

Dates: To be finalized.

Once the results are finalized through the Snapshot votes, the WOOF team will coordinate with the selected OEV vendor(s) to push on-chain votes, tentatively over the course of one month. If delegates choose to wait for Chainlink SVR to go live on L2s, WOOF will wait for such solutions to go live before proposing the necessary on-chain votes. The precise cadence and structure of these votes is in part dependent on the coordination between WOOF and the vendors—as well as OpenZeppelin for reviewing any on-chain votes before they are live.

In order to reduce friction when submitting on-chain proposals, we request that the DAO whitelists the following addresses controlled by the WOOF team, allowing them to submit multiple concurrent proposals if needed.

  • 0x89f299103D8627557906Edf5bf197fe131Bce8DB
  • 0x4D57f3c47C4abaF24371bF11e2C994B32d96093E
  • 0x871fAC073D4BF00d364167f766AdaA9649e5e26c
  • 0xBFe2FF554d56527F679b746C777d73157724788d
  • 0x39D3dCBD0467eD167e9a7DBE77B58b8B1Ea75aaD

The community multisig (0xbbf3f1421D886E9b2c5D716B5192aC998af2012c) will be responsible for authorizing the above addresses to post the required OEV proposals. All of the mentioned addresses will remain whitelisted until EOD August 31 (1756684799 epoch timestamp), leaving enough leeway for unforeseen delays in pushing votes.

We will update this forum thread with links to each of the Snapshot votes as they go live, subsequently posting the voting results and future on-chain vote progression.

5 Likes

Snapshot Voting Phase

All 10 of the OEV RFP votes are now live on Snapshot, concluding at 11:59pm UTC on July 11, 2025.

Please see the following list of chains to vote:

1 Like

Hey everyone,

After reviewing the current OEV proposals and the OpenZeppelin assessments, I’m recommending a risk-minimized rollout that gives the DAO a chance to test each provider in a controlled way—without rushing into broad adoption just yet. This approach also gives the newly formed Compound Foundation time to step in with more oversight and analysis heading into 2026.

Here’s how I’m voting across the different networks:


Ethereum Mainnet – Adopt Chainlink SVR

Chainlink SVR is already live and working well in production with Aave. Since Compound already uses Chainlink feeds on mainnet, this adds very little new risk—and mainnet is where the largest share of liquidation value lives. It’s the safest place to start.


Polygon, Base, Arbitrum, Optimism – Do NOT adopt OEV (yet)

I’d prefer to wait until Chainlink SVR is fully live across these L2s. Rather than pre-approving a phased rollout now and juggling separate votes later, it makes more sense to monitor how SVR performs on mainnet and revisit a broader rollout with better data in Q1 2026.


Unichain – Adopt RedStone OEV

RedStone is already providing oracles on Unichain, and this chain offers a lower-stakes opportunity to evaluate how their OEV system performs in practice. I see this as a good live trial that can help inform future decisions.


Mantle – Keep Api3 OEV (no change)

Api3 is already live on Mantle and has been returning OEV to the DAO. Since it’s already integrated and working, there’s no need to change anything here—this can serve as their performance showcase.


Scroll, Ronin, Linea – Do NOT adopt OEV

These are small markets (each under $1M in TVL), so there’s not much to gain from rolling out OEV solutions here right now. The operational cost and complexity of integration here would likely outweigh potential gains.


Summary

This setup gives each vendor a chance to show what they can do over the next six months in real environments. Then in Q1 2026 (or earlier), with more performance data and the Foundation more fully up and running, the DAO can make a more confident decision about long-term OEV strategy.

Appreciate everyone’s work on this—looking forward to seeing how things play out.

6 Likes

[Gauntlet] - Risks and Considerations Pertaining to OEV

Gauntlet appreciates the ongoing discussion and the recent RFP regarding OEV provider selection. To support the decision-making process and provide additional context for the current snapshot vote, we are sharing our analysis, relevant benchmarks, and potential friction points for successfully implementing OEV.

Disclaimer: The community should conduct its own independent review and analysis before making a decision. The considerations below are provided given that Gauntlet is a community delegate. OEV selection is not directly part of Gauntlet’s risk management mandate with the Compound DAO.

High Latency of Liquidations

Compound’s liquidation mechanism exposes the protocol to duration risk of holding the collateral assets while repaying the borrower in base asset. The price trajectory of the collateral asset before and post calling the absorb() is pivotal to succesfully liquidating the collateral without bad debt to the protocol.

The Ask Price is determined by the price feed and is a function of storeFrontPriceFactor and the asset’s LiquidationFactor. Gauntlet has observed elevated latency in liquidation execution during periods of high volatility, especially on L2s. These delays increase the risk of negative reserve generation or even bank-run scenarios.

  • The market downturn of 8/12/24 revealed low liquidity participation on L2 chains, correlating to greater processing time for collateral purchases - this was more pronounced on Base and Optimism comets.
  • The market downturn of 2/3/25 showcased that this trend still persists where WETH and wstETH liquidations continued to show elevated latency.

OEV integrations should prioritize bootstrapping a robust searcher ecosystem, and pilot deployments should focus on L2s, especially Arbitrum, Base, and Optimism, where historical liquidator participation has been low and latency high.

Maximum per block price deviation vs Liquidation Profitability

The value of absorbed collateral can shift from block to block. If the collateral’s price falls by more than a certain threshold (y%) between the time it is absorbed and sold, the protocol can incur losses.

The protocol is protected from loss if:

Refactoring the equation to solve for y, we get:

This defines the maximum permissible price drop between absorption and sale before the liquidation becomes unprofitable.

Historical Price Drawdown Analysis

The below visualizations show the distribution of Oracle price drawdowns against Number of Blocks.





The table summarizes the maximum negative oracle price updates between consecutive blocks and over rolling windows of 3 and 5 blocks, measured across the most volatile periods from 2022 to 2024:

Token Maximum Oracle Price Drawdown Between Consecutive Blocks Maximum Oracle Price Drawdown Between 3 Consecutive Blocks Maximum Oracle Price Drawdown Between 5 Consecutive Blocks y
WBTC -2.84% -3.09% -4.47% -4.25%
WETH -4.77% -4.77% -5.02% -2.06%
LINK -3.91% -4.45% -7.69% -7.57%
COMP -12.32% -12.32% -12.32% -11.76%
UNI -5.76% -5.76% -9.1% -7.57%

This data demonstrates that larger drawdowns are more likely over multi-block windows. The y is the price drop between absorption and sale of collateral below which bad debt can materialize. While the block-to-block drawdown is still below the thresholds compared to y , except for WETH (Pending increase in Liquidation Penalty) and COMP, the price drop over rolling 5 block window is already lower than y for all assets. We therefore recommend that OEV enabled liquidations should take no longer than 3 blocks (~36s on Mainnet) given the historical price drawdowns and relative price thresholds to materialize bad debt.

Recommendations

While maximizing OEV revenue is important, liquidation efficiency and risk mitigation should be prioritized to protect the protocol and its brand. To that end, we recommend:

  • Prioritizing OEV providers with a proven, responsive searcher network.
  • Emphasizing piloting integrations on L2s first, especially Arbitrum, Base, and Optimism.
  • Ensuring liquidation latency remains under three blocks.

These guidelines will help ensure OEV integrations add value without increasing systemic risk.

3 Likes

Quick note on timing and Gauntlet’s post

GM. Appreciate the benchmarks Gauntlet put together. Some delegates have asked us to share a public response specifically on timeliness, since this has been the main critique Chainlink and Redstone have “flooded their DMs with” in regard to our solution. Not a fan of the background politics right now, but happy to get this on record.

We already cover this in Section 1G of our proposal, but here’s a quick summary.

Our solution has been live in production for nearly three quarters, operating across multiple chains and real environments. It has executed a large volume of liquidations, processing over $5,000,00 in debt and capturing over $330,000 in the process. The average time from bid to on-chain update is about 18 seconds.

This includes February 2025, which saw over $10 billion in liquidations, marking the largest event in crypto history. The system continued operating smoothly throughout, with no incidents and no bad debt generated.

The timing setup introduces a short, bounded delay and is fully configurable. As OpenZeppelin noted in their review, it can be tightened further if needed. But based on real usage, we’re already well within the 36-second window Gauntlet identified. All of this data is public, and the system is running live today across multiple chains with a proven, uniform track record. There’s very little guesswork left when performance is backed by nearly three quarters of production-grade data.


Now, onto the part that’s not so technical.

This is supposed to be an open application process. Yet over the last 96 hours, I’ve had dozens of 1-on-1 calls with delegates, and have more lined up this week, just to make sure our submission is actually being evaluated on the merits.

Nearly every single conversation has started with some variation of:
“I’ve already been approached by a dozen Chainlink people in DMs.” or “Redstone has said this about you, what’s your answer?”

I get that this is probably the status quo for DAO governance, but I’d be remiss not to point out that this kind of environment is likely a major deterrent for independent service providers even considering getting involved with Compound in the first place.

So, while most of the conversation is happening behind closed doors, I figured I’d shake things up a bit by asking a few questions publicly, which are ones I’d hope delegates would have asked some of the other applicants.

  • Why did Chainlink offer Compound a materially worse revenue share (10% lower) than what they offer Aave, especially given that the additional revenue is negligible relative to Chainlink Labs’ size?
  • If Aave is getting a better deal, can Compound delegates realistically expect to be prioritized for SVR rollout on L2s or should they expect to be integrated only after the favorite child has been served?
  • Redstone claims a very successful pilot program with Venus on their two biggest markets (BNB & BTC on BNB Chain) from November 2024 as part of their Compound application. Yet there is no mention of this pilot in their official Venus forum post from just two weeks ago. Why?
  • Why is there no Venus governance post announcing or referencing the very impactful change to liquidation dynamics on the two biggest markets that Venus has (over 1.2B in TVL)? Especially considering how big this change is for lending protocols, and how the consideration triggered a multi-month (even year) long discussion on Compound.

  • Why has Venus never acknowledged this pilot publicly, via tweet or any official communication? Especially because they did tweet about API3’s proposal in August 2024 publicly?

  • Given that ChaosLabs officially reviewed our solution in accordance with our governance post, why is there no review, analysis or mention of the Redstone pilot program by ChaosLabs?

  • Why did a Venus team member recently suggest that any pilot should be limited to Unichain or Ethereum to avoid exposing BNB Core markets to risk, if Redstone already completed a successful pilot on BNB Core markets 8 months ago?

  • And the most obvious one: if the pilot was as successful as claimed, why isn’t Redstone’s OEV solution live on Venus today, 8 months later?

These are fair questions and i’m quite surprised that they have not come up during this RFP process. If timeliness is being used as the primary critique, then live performance, transparency, and follow-through should matter just as much if not more than private outreach or name recognition.

3 Likes

Oracle Extractable Value in Compound: A Risk Perspective

I want to start by thanking everyone who contributed to getting OEV up and running on Compound. Thanks to @Kyle from AlphaGrowth and @ugurmersin from API3 for their original proposal back in Feb and also to @mattgurbiel, @mikemassari, @Thogard, @jacob_fastlane and the RedStone and FastLane teams along with @AshNathan and @Chainlink_Labs for their proposals as well.

I also want to thank @PGov and @AranaDigital and the Compound Governance Working Group for streamlining the vendor selection process and @woof, @jbass-oz and the OpenZeppelin team and @Gauntlet for their detailed analyses on the topic. This is an important step forward for Compound.

As Compound considers adopting an OEV solution, Platonia shares Gauntlet’s view that the focus should extend beyond potential revenue to include protocol safety, risk management, and architectural soundness.

We’ve reviewed the proposals and conducted a quantitative analysis on OEV. This post outlines our perspective from a neutral, risk-first lens to help the DAO make an informed decision.

Why OEV matters, but should be kept in context

OEV is a symptom of an architectural inefficiency in how lending protocol conduct liquidations.

In their current form, liquidations are a highly inefficient form of risk reduction

  1. They overpay for protection when the benefit is marginal (e.g. small or low urgency liquidations etc)
  2. They firesale large amounts of capital in a public and highly exploitable manner, often at the worst possible times during peak market turmoil and incur maximum execution costs

The first issue calls for a calibrated design for dynamic liquidation penalties. The second requires better mechanism design for executing risk reduction in the market.

OEV solutions auction off the right to recapture this inefficiency and return a portion of it to the protocol. These probably do reasonably well on (1) by forcing searchers into competitive bidding but perform poorly on (2) and make the problem worse (analysis below).

It’s encouraging to see community excitement around OEV (we’re excited too). It likely represents a revenue improvement over the current state.

However, OEV recapture is not a structural fix. The long term goal should be to design liquidation systems that minimizes this value leakage in the first place.

The DAO should treat OEV as an interim optimization, not an essential feature. Decisions should be made with caution, avoiding unnecessary risk introduction while the community works towards more robust and efficient liquidation design.

Key risk considerations

OEV solutions introduce more insolvency risk

In their existing form, OEV auctions add costs for liquidators without reducing underlying protocol risk. This strictly decreases the likelihood of timely liquidations under current conditions. Additionally, the time required to run an OEV auction can introduce delays which Gauntlet has shown to be costly in their risk analysis.

Empirical liquidation delays from OEV

The largest real world instance of OEV on Compound III occurred during the Mantle liquidation on February 3.

Roughly 20% of the liquidation incentive was lost to slippage costs in the cmETH/USDe and cmETH/mETH pools on Agni. Another 40% went to Compound via the storeFrontPriceFactor (SFPF). The remaining 40% (about 76k MNT valued at ~$65k at the time according to API3’s MNT/USD oracle) was captured by API3’s OEV oracle.

A closer look at market conditions during the liquidation highlights several worrisome details.

First, both the Chainlink and RedStone oracles updated to a ETH price below the eventual API3 liquidation price 27 blocks earlier, resulted in a 40s liquidation delay relative to alternate feeds. By the time the liquidation occurred, the stale API3 oracle liquidation price was more than 7% above the market and marked to what was reported by the other oracles, the 1.5M account was already 10k insolvent. In the 40s leading up to the liquidation ETH had dropped >10%, which would have resulted in an insolvency loss of 160k had the same drop persisted.

Another point of serious concern is that Compound was very fortunate that the Agni pool implied ETH price was trading above the oracle price during this time period. Had arbitrageurs traded the Agni pools in line with the broader market, it’s possible that the liquidation incentive may have been insufficient to cover the slippage given that the ETH pool price went from 2600 to 2050 during the liquidation, which would have introduced substantial insolvency risk.

While the outcome was ultimately favorable, it underscores how fragile and path dependent the current system can be.

This isn’t meant to single out API3 and @ugurmersin has already given context on the delay here. However, it’s difficult to view this as a positive data point for API3’s OEV record on Mantle. This could have easily resulted in a sizable insolvency and it’s unlikely that such favorable arbitrage conditions would have existed had this occurred on more liquid ecosystems such as Ethereum mainnet, Arbitrum or Base.

Increased liquidator costs leads to liquidation delays

Deviation between DEX and oracle

The Mantle example highlights a key issue in liquidator costs that arises from deviations between the oracle price and the DEX price of the collateral relative to the borrow asset.

Oracles aggregate prices from both centralized and decentralized exchanges. While DEX prices are usually well-arbitraged onchain, CEX-DEX arbitrage is slower and more complex. During sharp market moves, this can result in meaningful spreads between the two.

As a simplification, suppose the oracle reflects a weighted median of DEX and CEX prices. In the case where \text{CEX price} < \text{oracle price} < \text{DEX price} the protocol ends up quoting the collateral too cheaply relative to what is available on DEXs. This gives the liquidator an opportunity to arbitrage both legs of the liquidation and extract additional profit. In such cases, the liquidation incentive is overly generous since the liquidator would likely participate even without it.

More commonly, the reverse situation occurs where
\text{CEX price} > \text{oracle price} > \text{DEX price}. Here, the deviation works against the liquidator by directly reducing their expected profit. This can make the incentive insufficient to cover slippage, reducing OEV recapture and increasing the risk of liquidation delays.

Empirical data

This dynamic was clearly visible on Feb 3 as highlighted in Gauntlet’s analysis.

Plotting protocol WETH reserves [1] and market conditions following the large absorptions gives

A significant amount of absorbed WETH remained unliquidated across multiple time periods. A key reason is that the Uniswap V3 price was 4-8% below the oracle price at times, making it too costly for liquidators to offload collateral into the primary DEX liquidity venue when the WETH liquidator incentive (post SFPF) was only 3%.

In contrast the WBTC absorbed [2] was liquidated instantly

as the Uniswap V3 price was roughly in line with the oracle at the time of liquidation.

Race conditions for large liquidations

Large liquidations tend to be highly correlated across lending protocols. Since liquidators draw from the same onchain pools, this creates a race condition where protocols compete through incentives to have their positions be liquidated first. Being second (or later) means worse execution and higher insolvency risk.

On February 3, Aave and Compound III experienced large volumes of liquidations. A likely reason WBTC was liquidated quickly on Compound is that the liquidator incentive was 6% compared to 4.5% on Aave. The subsequent drop in Uniswap V3 price relative to the oracle was likely driven by additional WBTC liquidations on other protocols. The large Compound liquidation had already removed a significant amount of liquidity, setting off a broader dislocation.

In contrast, the ETH liquidation incentive was 4.5% on Aave and only 3% on Compound. This made Compound’s ETH liquidations less attractive, especially when multiple protocols are competing for the same liquidity, which contributed to delays.

Transaction inclusion and ordering are critical during fast-moving market events. OEV auctions reduce the amount liquidators can pay in builder tips, making their transactions less competitive and increasing the risk of failed or delayed liquidations.

OEV revenue is overestimated

Platonia traced the 10 largest absorptions in Compound III’s history and the corresponding ~50 large liquidations that followed, totaling 170M which is approximately 43% of all lifetime absorption volume. Our findings indicate that only a small fraction of liquidation incentives can be safely recaptured by the protocol (<5% for large liquidations).

Slippage costs dominate large liquidations

A more detailed breakdown of liquidation costs can be found here but empirically liquidators have spent the majority of the incentive themselves paying astronomical slippage costs to dump the exposure on DEXes within the same block. This can be seen below

where 68% of the total incentive collected by liquidators was eaten by slippage costs.

A particularly egregious example was the largest liquidation (buyCollateral event) in Compound III. This was nearly $20M in size with a total incentive of $591k.

Of this, ~$589k went to slippage leaving just $1.4k for the builder tip and $0.3k to the liquidator, with only 5 bps of the incentive pocketed by the liquidator.

Large absorptions are often not repurchased immediately

As Gauntlet has previously alluded to, absorbed collateral often experiences delays before being fully liquidated. As shown below

41% of the total absorption volume remained unliquidated after 2 blocks.

While the core issue is insolvency risk, the longer it takes to recapture OEV, the noisier the outcome becomes e.g. collateral prices may recover causing the liquidation opportunity to vanish.

Everyone takes a cut

It’s worth noting that Compound III already captures a significant share of the liquidation incentive through the SFPF. This is set to 60% for the mainnet USDC and USDT comets where the dominant majority of liquidation volume has occurred, making the protocol’s current cut ~40%.

From there, the aforementioned slippage costs are effectively deterministic from the atomic liquidator’s execution strategy so recaptured in the auction and comprise a hefty chunk.

What’s left is split between builder tips and liquidator profits, of which the proposed OEV provider fees range from 20 to 45%.

This accounts for just 0.68% of large absorption volume as shown.

Builder tips also present a tricky counterfactual. They are difficult to fully recapture, as reducing them could affect the transaction inclusion in the first place and cause liquidation delays and heightened insolvency risk.

In effect, the benefit of OEV in this context is likely comparable to reducing the SFPF from 0.6 to 0.5 on the mainnet USDC and USDT comets, but without the integration overhead or added security risk.

Atomic liquidator profits are small

Atomic liquidators are myopic, profit seeking bots who will perform liquidations for miniscule amounts of profit. Thus, cutting into their profits through auction bids is a safe way to redirect OEV to the protocol without leading to much additional protocol risk.

Unfortunately, only 4.7% of the total incentive collected was liquidator profit.

As an example, looking at the largest absorption in Compound III history

This was a $35M absorption with $790k of slippage costs, a $158k tip to the builder, $7.5k to Aave for a flash loan and the liquidator pockets basically nothing (maybe like $5).

OEV reflects an underlying design flaw. Better alternatives exist

OEV is only relevant because current liquidation mechanisms are highly wasteful in execution. Initiatives like partial liquidations improve the efficiency of risk reduction, making Compound more competitive by enabling lower liquidation incentives and higher collateral factors. Implementing such improvements would naturally drive OEV extraction toward zero. By contrast, OEV solutions that heighten insolvency risk make Compound less competitive, trading long term growth in exchange for some short term revenue.

Empirical data

A clear example of inefficiency can be seen examining WBTC reserves and the market conditions around the largest absorption on Optimism.

Despite an exceptionally generous 10% liquidation penalty for an asset that is essentially BTC, the $2.4M liquidation took ~20 blocks and was executed gradually. The liquidator dumped the entire position into Uniswap V3, depleting liquidity and pushing the pool price nearly 7% below the oracle.

An OTC desk could likely have quoted and executed this risk for a few basis points. Instead, the full incentive was consumed in DEX slippage. This liquidation should have been both immediate and cost-efficient, but without a redesign of the liquidation system, it remains difficult to incorporate even basic trading intelligence. That gap continues to hold back the protocol’s competitiveness.

Liquidation inefficiency

One of the most important tenets of U.S. electronic equities is Regulation NMS, which enforces order protection to prevent trades from being executed at inferior prices. By contrast, the current liquidation process in DeFi resembles a standalone exchange posting large, unprotected orders several percent through the market book, waiting to get ripped off.

This design, which results in large, binary liquidation events, is structurally flawed. It creates steep incentive cliffs and exposes protocols to large execution costs and insolvency risk during periods of market stress. More sophisticated liquidation mechanisms, such those previously mentioned here would reduce the need for oversized incentives and shrink the window for OEV extraction. These approaches also enable smoother and more continuous risk reduction.

Even with large incentives in place, liquidations often get delayed. Perfect oracle updates are not enough as liquidations can still be delayed by slow CEX-DEX or cross chain arbitrage and limited onchain liquidity. The core challenge isn’t just disseminating the right price, it’s ensuring liquidations happen promptly and efficiently under stress.

Deeper integration with OEV infrastructure risks entrenching the current inefficiencies rather than addressing them. The DAO should be clear-eyed: OEV recapture is an optimization built on top of a flawed process, not a structural fix. Making liquidation timing overly sensitive to specific oracle updates adds fragility rather than resilience.

I’ve previously made the case here, here and here that fixing Compound’s liquidation mechanism is likely the highest leverage upgrade available to the protocol. The potential upside from such improvements should be worth several percentage points of Compound’s market cap. In contrast, OEV recapture, while helpful, is a more modest optimization that captures only a small sliver of the inefficiency while bringing its own risks and complexity.

Recommendations for the DAO

Share @cylon’s thoughts on a risk minimized rollout

+1. This is a good point to keep to mind. The protocol can always enable OEV later when the markets are more mature.

Share @Gauntlet’s views on the importance of risk mitigation

+1. This is essential. Extended liquidation delays could cost the protocol more than the additional revenue.

Platonia recommends the following approach:

  1. Treat OEV as a secondary optimization, not a primary feature
    • Focus on longer-term design improvements to liquidation mechanisms
    • Avoid vendor lock-in that could slow progress toward better architecture
  2. Demand rigorous empirical validation
    • Vendors should provide periodic updates with accurate statistics that account for slippage, builder tips, and latency impact
    • Existing OEV estimates often overstate value capture and understate or entirely omit execution costs and insolvency risk
  3. Prioritize protocol safety and resilience
    • Fallback behaviors must be well-tested and reliable
    • The DAO should carefully weigh latency tradeoffs that could introduce outsized insolvency risk
    • Exclusive feed rights and auction delays require close scrutiny
  4. Adopt a phased and cautious rollout
    • Start small across a few assets and chains, and evaluate performance before broader adoption
    • Exercise extra caution on Ethereum mainnet, which accounts for the vast majority of liquidations
  5. Recognize that OEV is not a substitute for better long-term liquidation design
    • OEV recapture should be viewed as comparable in benefit to a small reduction in SFPF
    • The community should prioritize work toward more robust, capital-efficient, and user-aligned liquidation systems

Conclusion

OEV solutions present a modest opportunity to improve Compound’s revenue, but the associated risks and tradeoffs should be evaluated carefully. The DAO should proceed incrementally, demand transparent data, and avoid decisions that lock in an inefficient architecture.

Platonia looks forward to supporting the community in this discussion and helping build a stronger, safer Compound protocol!


  1. The mainnet ETH/USD API3 oracle is omitted as it doesn’t seem to return any data for the time period. ↩︎

  2. The mainnet BTC/USD API3 oracle is omitted as it doesn’t seem to return any data for the time period. ↩︎

8 Likes

After reading up on the technical differences, security implications (thanks for the summaries, @jbass-oz !) and revenue share terms across the proposals, I find myself mostly aligned with the recommendations and corresponding rationales offered by @cylon with two small exceptions:

  • For its own benefit, the DAO should commit to affording Chainlink an opportunity to demonstrate SVR’s performance on an L2. This will provide the DAO with the necessary data for a more apples-to-apples comparison for future decision-making around OEV solutions on chains for which OEV may not be adopted through the current process. Chainlink’s solution should be live on Base by the time this process completes, so I will vote to adopt SVR there.

  • For similar reasons, there may be value in gathering data on API3’s solution on a chain with a USDC market; however, I have stronger reservations about the risk of bad debt accrual with its OEV solution relative to the others. Frankly, I see Ethena USDe itself as a riskier asset relative to the stablecoins for which Comets are deployed, so having API3 provide OEV on Compound’s one USDe market is actually quite fitting, and I am comfortable keeping it that way.

I appreciate the robust discussion and give kudos to the CGWG for organizing and to the vendors for explaining their solutions to the DAO.

1 Like

Hi all, Mike from RedStone here. Thank you, AranaDigital, for preparing a diligent process, to victator for his analysis, and to Gauntlet, ugurmersin, cylon, and allthecolors for their insightful comments and questions. As RedStone has been brought to the conversation, I am happy to provide supplementary information.

  1. Gauntlet recommends that liquidation latency remains under 3 blocks on L2s.

    • Among the considered providers, RedStone is the only one meeting the Gauntlet recommendation. Fastlane’s auction latency is max 300ms, only slightly above 1 block on the fastest L2s considered.
    • RedStone is best positioned to serve Arbitrum’s 250 ms blocktime, meaning that 1 block latency is the highest. Additionally, from the available oracle options, RedStone was the one chosen by Arbitrum to provide an oracle for Arbitrum Stylus.
    • Similarly, with a 2-second block time on Base, the 300ms is an advantage.
    • API3’s OEV auctions average 18 seconds, which corresponds to 72 blocks on average for the fastest L2s, with a maximum latency of 120 blocks.
    • Chainlink has not provided further information regarding an OEV solution on L2s to evaluate the delays in block time. On Ethereum, it is between 1 and 6 blocks, so roughly between 12 seconds and 72 seconds.
  2. Referring to Gauntlet’s recommendation of prioritizing OEV providers with a proven, responsive searcher network.

    • Among the considered providers, Fastlane has the longest experience running searchers networks on multiple L2s.
    • Fastlane MEV auctions on Polygon have a searcher network of 46 unique solver contracts not operated by the Fastlane team, and regularly receive bids from 4 unique searchers per high-value opportunity. As searchers are incentivized by profitable opportunities to solve liquidations, we expect the vast majority of this network to integrate RedStone OEV.
    • Fastlane has the longest experience running and developing searcher bots, and will open-source a liquidator bot that is distributed to our existing network of searchers.
    • RedStone OEV offers a very low-friction way for searchers to integrate that does not require the searchers to stake capital in order to place bids.

Addressing questions about the Venus pilot, the proposal to launch RedStone OEV on Venus has passed, indicating that the pilot was indeed a success. If there are concerns over the alpha trial, anyone may audit its performance using the on-chain data available from that time period.

We believe choosing an OEV solution should also be a decision of picking an oracle partner that holistically innovates and keeps sustained traction on the market, as it’s going to be a partner for Compound’s further growth (following Victator’s comment that OEV is just a part of the puzzle). RedStone has got a track record of constant innovation, is the fastest growing oracle on the market, making it the perfect candidate for the role.

We look forward to holistically supporting the expansion of Compound, the lending market that has been on the DeFi map the longest.

We appreciate the comments from @Gauntlet and @victator in providing helpful information and largely substantiating thoughts shared by @cylon, which we felt made a lot of sense given the state of available OEV solutions. In all honesty, it seems tough to commit to a long-term partner on OEV when solutions aren’t really ready nor have been properly tested. Hence, we are more comfortable with this approach of splitting the testing across the providers and vote to adopt OEV on the remaining chains once we have some data to base the decision on.

2 Likes

Thanks to everyone who’s voted and contributed to the discussion so far.

After reviewing all recent comments—including those from @victator and @Gauntlet—and speaking directly with each of the vendors, my position remains largely the same: the DAO should adopt a measured, risk-aware rollout of OEV providers, with clear guardrails and sufficient time to observe real-world performance before expanding further. That being said, I’ve changed my position in a few respects.

My Updated Position:

  • Chainlink on Ethereum Mainnet: I continue to support deploying Chainlink SVR on mainnet—but only for a single market initially. This creates a lower-risk testing environment. All OEV solutions should be evaluated for 1–2 months, ideally through a market stress event, before expanding to other markets. The same standard should apply to RedStone, Api3, and any future OEV deployments.
  • Chainlink on Base: I’ve updated my vote to support deploying Chainlink SVR on Base as well. While I was previously more cautious, I now see Base as a logical next step—contingent on SVR being fully live before year-end. If mainnet performance is solid, Base presents strong growth potential and minimal additional complexity.
  • RedStone on Unichain: No change. I continue to support deploying RedStone on Unichain. If Chainlink is delayed on certain L2s and RedStone demonstrates strong performance, I’d be open to expanding their role—but only after a proper evaluation period that includes volatile conditions.
  • Api3 on Mantle: No change. It’s live and generating revenue for the DAO, and I’m comfortable continuing to monitor its performance within that scope—but any future expansion should be subject to the same evaluation standards as the others.
  • Arbitrum, Optimism: No change. Hold off while OEV solutions are evaluated on other chains. The best fit can be adopted on these chains in the near future by Q1 2026 or even sooner.
  • Scroll, Ronin, Linea: No change. These markets remain too small to justify the integration cost at this time. I recommend holding off on any OEV deployment here.

As @victator and @Gauntlet noted, these systems introduce meaningful complexity into the liquidation path. A controlled, data-driven rollout will give the DAO better visibility into safety, incentives, and long-term fit.

Also worth mentioning: partial liquidations (being built by WOOF) are expected to go live next quarter. This change may further influence how OEV is captured across the protocol and reinforces the need for deliberate deployment strategies.

While I understand the desire among some delegates to resolve OEV selection after over a year of discussion, that alone isn’t a good reason to rush. Instead, let’s empower the newly established Compound Foundation to lead the next phase of evaluation, vendor coordination, and long-term integration—aiming for alignment with a preferred provider over time.

Thanks again to everyone contributing to this process.

2 Likes

After careful consideration of the facts and data, we’re mostly in agreement with @cylon’s stance of a measured rollout of OEV providers. Where our opinion deviates is that we’re sufficiently satisfied with API3’s performance under extreme market volatility, based on the OZ report and publicly available data, to roll them out on Arbitrum in addition to their existing deployment on Mantle.

Chainlink: Ethereum, Base
RedStone: Unichain
API3: Arbitrum, Mantle
No Deployment: Polygon, Optimism, Scroll, Ronin, Linea

Appreciate the detailed analyses from @victator, @jbass-oz, and @Gauntlet. It would have been difficult to make an informed decision without their input. Also thank you to all three of the vendors for taking the time to go through the laborious process of talking with delegates, fielding questions, and advocating for their solutions.

Update: We’ve changed our position after reviewing additional evidence on risk factors we had not previously considered. As such, we believe that API3 should remain on Mantle for the time being; we have updated our vote on Arbitrum to “Do NOT adopt OEV.”

1 Like

Thank you to those who’ve spent the past couple of days assessing the active RFP snapshot votes.

After taking input from a handful of parties, one important condition to note is that markets on each chain are intended to roll out gradually, allowing the DAO to observe how the elected OEV solution functions in the event of market volatility. These current snapshots are meant to directionally assess which vendor the DAO wants to elect for a given chain. If a vendor performs well on the initial market(s), that same vendor will likely expand to other markets on the given chain. Market expansions will not require a snapshot vote—only an onchain vote for implementation. However, for the adoption of a new vendor on a chain, a snapshot will first be run to gauge community sentiment.

Additionally, to ensure that snapshot votes aren’t altered last-minute, we are implementing a quorum cut-off period for the votes between 12pm - 3pm et on the 11th. The snapshots technically end at 7:59pm ET, however, to mimic the nature of onchain votes, the final vote will be counted at 3pm et for each snapshot—unless a vote flips in the 12pm-3pm period, at which point, the snapshot will be extended from 3pm - 7:59pm, ending at the originally stated time.

2 Likes

As per the above, the Snapshot votes concluded at 3pm ET, with the exception of the Polygon OEV vote. During the quorum cut-off period, this vote flipped from “Adopt Api3” to “Do NOT adopt OEV.” Therefore, due to the quorum alteration, the extended period is now in effect. This vote will conclude at 7:59pm ET.

Below are the final results of the other concluded votes (votes received, % of total votes):

  • Ethereum Mainnet: Adopt Chainlink SVR (713.9k votes, 65.23%)
  • Unichain: Adopt RedStone (624.5k, 95.12%)
  • Base: Adopt Chainlink (phased rollout) (863k, 96.3%)
  • Arbitrum: Do NOT adopt OEV (623.4k, 63.65%)
  • Optimism: Do NOT adopt OEV (408.8k, 90.79%)
  • Scroll: Do NOT adopt OEV (407.3k, 90.47%)
  • Mantle: Keep Api3 OEV (545.1k, 92.56%)
  • Ronin: Do NOT adopt OEV (456.1k, 91.18%)
  • Linea: Do NOT adopt OEV (458.5k, 91.66%)
1 Like