Formalizing Oracle Extractable Value (OEV) Solutions for Compound

[PGov]

Formalizing Oracle Extractable Value (OEV) Solutions for Compound

Authors: Compound Governance Working Group (CGWG)

As the Compound protocol matures, exploring opportunities for sustainable value generation remains a key priority. One such opportunity lies in the capture of Oracle Extractable Value (OEV)—the arbitrage opportunities that arise when oracles update asset prices on-chain, triggering liquidations or other economic activity. Similar to recent efforts by other DeFi communities such as Moonwell, this post seeks to formally consolidate the discussion around OEV and initiate a structured community process for evaluating solutions. The goal is to determine how Compound can responsibly capture a portion of this value in a way that aligns with the protocol’s ethos of decentralization, security, and capital efficiency.

As more teams in the space look to provide this for Compound, we are looking to consolidate conversations surrounding this topic, present technical feedback for each, and then decide on which proposal(s) to implement.

Each proposal should at a baseline include information about:

• Technical Design: Proposal should explain mechanism & oracle integration, describing the exact mechanism for detecting and capturing Oracle Extractable Value (OEV): for example, whether the solution uses on-chain auctions, off-chain relayers, priority transaction bundles, or validator-level integrations. It should also specify whether the solution relies on private transaction ordering infrastructure like Flashbots or SUAVE, or if it introduces its own custom coordination mechanism. Proposals must be clear about whether the system is modular and adaptable to future changes in oracle structure or network upgrades, and how it handles timing-sensitive execution, such as during volatile market conditions or oracle price updates.
• Security & Trust Assumptions: Proposals must spell out any new trust assumptions introduced. This includes whether the solution is reliant on centralized actors (such as relayers, searchers, or validators), and what attack vectors might exist (e.g., oracle manipulation, front-running, griefing). Projects should outline their threat model and risk mitigation strategies, and indicate whether the system has been audited or used in production elsewhere.
• Value Flow & Protocol Impact: This section should break down exactly where the captured OEV goes and how much the protocol stands to benefit. It should explain whether value is directed to the treasury, to a staking system, to an insurance module, or even to borrowers/lenders as rebates. The proposer should include any models or assumptions behind their revenue projections and clearly state how their incentives align with Compound.
• Implementation & Readiness: This part should describe the technical maturity of the proposal and how it could be rolled out. Does the system exist already, or is it still under development? Has it been deployed on other protocols or testnets? What upgrades or new permissions would the Compound DAO need to grant, and how configurable is the solution over time? Ideally, proposals should also include a rough timeline on integration speed.

Technical Review: We will be working with the @Woof team who will produce a technical review for each OEV team proposed to the DAO. These reviews will be linked below for visibility.

Currently, the teams that have proposed OEV solutions for Compound are:

1. API3: Approve API3 Data Feeds for use within Compound Finance

• Technical Review: Here

2. Redstone: RedStone OEV: A No-Tradeoff Solution for Compound’s Capital Efficiency and Revenue Goals

• Technical Review: Here

3. Chainlink: Chainlink SVR

• Technical Review: Here

We will continue to update this list as more teams submit proposals.

Prospective Timeline:

Note this is subject to change pending finalization of each proposal and community discussion:

• Discussions (April/May 2025): We’ll look to host discussion this month and next to revisit old proposals and allow time for new ones. This should give ample time for robust submissions addressing technical, economic, and governance needs.
• Temperature Check: After discussion have matured to a good point, we will host a snapshot vote to decide which team to implement first. Delegates and community members are encouraged to review @Woof’s technical reviews and recommendations, but are of course free to vote however they choose.
• Onchain Implementation: After the first team is chosen, Woof will coordinate with the teams to upgrade respective markets and oracles for the DAO. This will commence the first trial period of OEV at Compound.
• Future Integrations: In the future, the community might discuss having multiple solutions, which might allow the DAO to remain more competitive and robust. The CGWG will continue to structure discussion around this topic as time progresses and conversation evolves.

[woof]

Comparing OEV Solutions: Chainlink SVR vs RedStone vs API3

Oracle Extractable Value (OEV) has emerged as a key opportunity for DeFi lending protocols like Compound to reclaim value that previously leaked to third-party arbitrageurs. Simply put, OEV is a subset of MEV (Maximal Extractable Value) that occurs when an oracle update triggers actions like liquidations. For example, when a price feed update makes a loan undercollateralized, bots currently race to execute the liquidation and capture the bonus. OEV solutions aim to recapture that value for the protocol and its users, instead of letting it go to miners, validators, or MEV bots.

Every time Compound pays out liquidation bonuses, a large portion of that profit is effectively “leaked” to whoever wins the gas auction to liquidate first. For Compound, this has been a significant loss – by USDC market on Mainnet estimate, over $5M leaked in 2025. By adopting an OEV recapture mechanism, Compound can redirect these funds back into the protocol, strengthening its reserves and benefiting its community, rather than enriching external actors. Potentially, capturing OEV could significantly increase the protocol’s earnings.

This post compares three leading OEV solutions – Chainlink Smart Value Recapture (SVR), RedStone OEV, and API3 OEV-enabled feeds. We’ll cover how each solution implements OEV, technical integration details, trust and security considerations, how the value flows (who gets the profits), current implementation status, and the pros and cons. A final section provides a side-by-side comparison table and an assessment of which solution (or combination) might best fit Compound V3.

What is Oracle Extractable Value (OEV)?

Oracle Extractable Value (OEV) is the profit that can be extracted by controlling the order and timing of oracle price updates and related transactions (e.g., liquidations). OEV is MEV specifically tied to oracle actions. The key idea is that oracles themselves (or DeFi protocols) can capture this value by organizing an auction around the oracle update, instead of leaving it to the block space auction (gas wars). By capturing OEV, Compound can reclaim a portion of the liquidation bonuses that would otherwise go to the fastest liquidator, creating a new revenue stream for the DAO or reserves. All OEV solutions involve an auction for the right to act on fresh oracle data. Instead of a free-for-all race in the public mempool, the oracle provider or protocol orchestrates a controlled auction. The participant (liquidator) who bids the highest wins the right to execute the liquidation using the new price. Their bid becomes revenue that is distributed between the oracle provider and the DeFi protocol.

Now, let’s examine how each of the three solutions implements OEV.

1. Chainlink SVR (Smart Value Recapture)

Overview and OEV Approach

Chainlink SVR helps DeFi applications “recapture” MEV generated by their own price feeds. SVR focuses on lending protocol liquidations and works by delivering price updates in a way that forces liquidators to bid for the right to use those updates. Essentially, Chainlink adds an auction mechanism to its price feeds: before publishing a price update that could trigger liquidations, SVR runs an auction via Flashbots infrastructure. The auction winner (highest bidder) gets to include their liquidation transaction alongside the oracle update.

How it Works

SVR uses dual feeds (Dual Aggregator) for each asset: a standard Chainlink feed updating via the public mempool, and a parallel SVR feed with the same data but delivered through a private channel (Flashbots) with an auction. The auction runs via Flashbots MEV-Share: the Chainlink oracle privately shares the pending price update with “searchers,” who bid for the right to include their liquidation transaction in a “bundle” with the price update. Using Flashbots ensures the price update and the winner’s transaction are included in a block atomically and privately, bypassing the public mempool. A crucial feature is the fallback mechanism: if the auction fails (no bids) or Flashbots delivery fails, the price update is still published via the standard feed after a short delay, ensuring the protocol receives the price. For Compound, integration involves replacing standard Chainlink feed addresses with SVR feed addresses, with no changes to Compound’s core code.

Security & Trust

SVR uses Chainlink’s decentralized oracle network (DON) but adds a dependency on the Flashbots infrastructure. The main risk involves auction or Flashbots failure, but this is significantly mitigated by the fallback mechanism. The price data itself is not manipulated. SVR contracts were developed with input from Chainlink Labs and BGD Labs (known for their work with Aave), and Aave’s integration implies thorough security review, although specific SVR audit reports may not be public. SVR was tested with Aave, and initial usage (reportedly capturing ~40% of liquidation MEV) builds confidence.

Value Flow

The standard revenue split from the auction is 60% to the protocol (Compound) and 40% to the Chainlink ecosystem. Chainlink’s share covers costs and supports network sustainability. Initial partners (like Aave) received better terms (65/35), and Compound could potentially negotiate similar terms. Compound can direct its share to reserves or the DAO treasury.

Implementation Status & Readiness

SVR is live on Ethereum mainnet since early 2025, used by Aave V3. It can be integrated relatively quickly on Compound’s Ethereum mainnet deployment. However, the current version depends on Flashbots and is only available on Ethereum mainnet. It does not work on L2s/sidechains (Base, Polygon, Arbitrum, etc.) where Compound V3 is deployed, until Chainlink releases a cross-chain SVR version or Flashbots expands support.

Pros and Cons of Chainlink SVR

Pros:

• Minimal Change: Easy to integrate, building on existing Chainlink feeds.
• Proven Oracle Quality: Leverages reliable Chainlink data.
• Safety Net: Fallback mechanism reduces failure risks.
• Captures “Non-Toxic” MEV: Focuses on liquidations without harming users.
• Tested in Production: Used by Aave on Ethereum.

Cons:

• Ethereum Only: Major drawback – not yet available on L2s and other chains used by Compound V3.
• Revenue Split (60/40): Compound receives a smaller share compared to API3 (80%).
• Dependency on Flashbots: External reliance on third-party infrastructure.
• Product Immaturity: Less time “battle-hardened” compared to Chainlink’s core feeds.

2. RedStone OEV Solution

Overview and OEV Approach

RedStone is an oracle with a modular architecture known for fast feeds. Their OEV solution emphasizes speed and minimal latency. RedStone runs an auction before publishing the price on-chain. Using its off-chain Data Distribution Layer (DDL), RedStone shows signed prices to liquidators almost instantly. Upon detecting a price that triggers liquidations, a very fast (hundreds of milliseconds) off-chain auction is conducted. The winner (most efficient liquidator willing to give up the largest profit share) gets the right to deliver the price on-chain and execute the liquidation.

How it Works

RedStone separates data collection, signing (off-chain), and distribution via DDL. Liquidators see signed prices before they hit the chain and participate in a fast off-chain auction coordinated by RedStone. The winner (or a RedStone relayer) delivers the price and liquidation transaction on-chain, possibly via specialized relays (e.g., Fastlane on Base) or Flashbots alternatives, avoiding the public mempool. RedStone claims their auction is so fast it adds no perceptible delay to price updates. Importantly, RedStone follows the Chainlink interface, allowing feed replacement without protocol code changes. RedStone’s architecture enables easy deployment on any EVM chain (infrastructure is already on Base). If the auction fails, the price is still updated via RedStone’s standard method.

Security & Trust

RedStone’s data signing model is somewhat more centralized. For OEV, trust is placed in RedStone’s off-chain auction coordinator. The main risk stems from the solution’s novelty. However, RedStone’s core oracle systems have been audited by several leading firms (e.g., ABDK, Peckshield, SigmaPrime), and the OEV solution using UMA OVAL (for the Morpho integration) was audited by Halborn. The “no code change” approach reduces risks for Compound. Failure of the off-chain coordinator could temporarily disable OEV capture, but not the oracle itself.

Value Flow

The proposed split is 50% to the protocol (Compound) and 50% to RedStone. RedStone’s share covers their infrastructure costs (potentially meaning Compound wouldn’t pay separate feed fees). Compound’s share goes to reserves or the treasury. RedStone has also mentioned the possibility of distributing part of the funds to users (at the DAO’s discretion).

Implementation Status & Readiness

The solution is in active development and early deployment. There’s a PoC on Morpho with UMA OVAL (2024), and infrastructure is deployed on Base for a pilot with Moonwell (late 2024). RedStone claims readiness to deploy on all Compound V3 networks without delay. Integration is simple (feed address swap), but the Compound community would need to assess RedStone as a primary oracle provider for the selected markets.

Pros and Cons of RedStone OEV

Pros:

• Cross-Chain Ready: Works on all EVM chains immediately.
• Minimal/No Latency: Very fast auction, potentially speeding up updates.
• No Code Changes: Easy integration via standard interface.
• Potentially More Frequent Updates: OEV incentivizes on-chain price delivery.
• Flexibility & Innovation: New team adapting quickly to the MEV landscape.

Cons:

• Less Battle-Tested: Relatively new solution, less data on performance in major crises.
• Revenue Split (50/50): Lowest share for the protocol among the three options.
• Trust in Newer Oracle: Moving from Chainlink requires evaluating RedStone’s reliability.
• Off-Chain Coordination: Dependency on RedStone’s off-chain system for the auction.

3. API3 OEV-Enabled Data Feeds

Overview and OEV Approach

API3 uses first-party oracles (data directly from providers). Their OEV solution allows an auction at the oracle level before MEV goes to validators. When a price update could trigger liquidations, API3 holds an on-chain auction for the right to publish that update and perform the liquidation. The winner pays their bid, which is split between the protocol and API3. API3 positions this as unlocking “hidden revenue” for dApps.

How it Works

Two types of feeds are used: a global feed (updated by API3 nodes) and an OEV feed (dApp-specific, updated by the auction winner). Compound reads data via a proxy contract that returns the freshest price. When an update is ready, API3 delays the global feed publication by ~30 seconds to allow for an on-chain auction via the OEV AuctionHouse contract. The auction winner must execute the OEV feed price update and their liquidation in one atomic transaction, while simultaneously paying their bid. The mechanism doesn’t require external relays like Flashbots. API3’s solution works on all EVM chains. If there are no bids, the global feed updates automatically after the ~30-second delay. Integration requires pointing to the API3 proxy contract, with no changes to Compound’s code. Compound has already used API3 feeds on Mantle.

Security & Trust

Trust is based on first-party data providers and audited smart contracts for the auction. API3 has undergone over 10 audits of its systems by leading firms, although specific auditors for the OEV contracts weren’t named in the provided sources. The main discussion point is the ~30-second global feed delay, but the system proved reliable during the major market crash in February 2025. The solution has been used in production by multiple protocols (including Compound on Mantle, Mendi, Ionic) for months without incidents. There’s an API3 DAO insurance fund.

Value Flow

The most favorable split for the protocol: ~80% to the protocol (Compound) and ~20% to API3. API3’s share funds data providers and token buybacks/burns. API3 does not charge subscription fees for feeds, using OEV as its revenue model. There are confirmed cases of OEV payouts to protocols (e.g., Yei Finance).

Implementation Status & Readiness

The solution has been live in production since mid-to-late 2024. It’s used by Compound on Mantle (already generated revenue for the DAO), Mendi, Ionic, Yei Finance, and others. It successfully handled the stress test during the market crash. API3 is ready for deployment on all Compound V3 networks immediately. Risk assessors have previously approved API3 data for Compound. API3 actively engages with communities (Compound, Moonwell) and gains approvals.

Pros and Cons of API3 OEV

Pros:

• Highest Revenue Share (80%): Maximum financial return for the Compound DAO.
• Proven in Production: Months of use and successful stress testing.
• Cross-Chain Ready: Unified solution for all Compound V3 networks immediately.
• No Code Changes: Easy integration, confirmed on Mantle.
• First-Party Security: Data directly from sources, reliability proven in practice.
• Forward-Looking: Development of OEV Network (zk-rollup) for greater efficiency.

Cons:

• Switching from Chainlink: May require overcoming inertia and careful evaluation when replacing the main oracle on key markets.
• Global Feed Delay (~30s): A design choice for the auction mechanism. While proven safe in practice, it’s a difference from other approaches.
• Asset Coverage: While broad, API3’s coverage might be smaller than Chainlink’s for very niche assets (though API3 adds new feeds quickly upon request).

Comparison of OEV Solutions and Suitability for Compound V3

All three solutions offer to capture OEV but differ in mechanisms, availability, revenue share, and maturity.

Feature Comparison Table

Feature / Criteria	Chainlink SVR	RedStone OEV	API3 OEV Feeds
Auction Mechanism	Off-chain backrun auction (Flashbots MEV-Share)	Very fast off-chain auction (DDL + solvers)	On-chain auction (OEV AuctionHouse, -> zk-rollup)
Transaction Prioritization	Private Bundle: Price update + liquidation sent together via Flashbots directly to block builders, bypassing the public mempool. Ensures atomicity and privacy until execution.	Private Coordination: RedStone or a relayer sends the winner’s transaction (price+liq+payment) via private channels (e.g., Fastlane) for fast, front-running-resistant block inclusion.	Atomic in Contract, Delivered by Winner: Winner sends a single transaction (price+liq+payment). Winner likely uses Flashbots or other private relays for their own protection against being front-run after winning the auction but before block inclusion.
Integration Effort	Minimal (swap feed address)	Minimal (swap feed address)	Minimal (swap feed address)
Cross-Chain Availability	Ethereum Only (currently)	All EVM Chains	All EVM Chains
Oracle Data Quality	Chainlink (High, Proven)	RedStone (Good, Used by many)	API3 First-Party (High, Battle-tested)
Impact on Latency	None (or minimal on SVR failure)	None (or even faster)	Up to 30s delay (Global feed only)
Fallback Mechanism	Yes (Standard Chainlink feed)	Yes (Standard RedStone feed)	Yes (Global API3 feed)
Revenue Split (Protocol)	~60%	~50%	~80%
Current Usage	Aave V3 (Ethereum)	Morpho (PoC), Moonwell Base (Pilot)	Compound Mantle, Mendi, Ionic, Yei, etc.
Maturity / Proof	Relatively New Product: Primarily tested via Aave since late 2024/early 2025. Lacks long-term, multi-protocol track record for OEV specifically	Newest OEV Implementation: Primarily in Proof-of-Concept (Morpho) and Pilot stages (Moonwell Base). Lacks extensive production history or proven performance in major market events	Proven in Production: Used live by multiple protocols (incl. Compound Mantle) for months since mid/late 2024. Successfully handled major market crash (Feb 2025 stress test), demonstrating robustness.

Key Considerations for Compound V3

Several key factors should guide Compound V3’s OEV decision. Maximizing revenue is crucial, and API3 leads here with an 80% share for the protocol, potentially meaning millions more for the DAO compared to SVR’s ~60% or RedStone’s ~50%. Given Compound V3’s multi-chain strategy, the immediate availability of API3 and RedStone across all L2s and sidechains is vital, whereas Chainlink SVR is currently limited to Ethereum.

Regarding risk and maturity, API3 has the strongest track record for OEV in production, including surviving stress tests and being used by Compound itself (on Mantle). Chainlink SVR carries Chainlink’s reputation but is newer as a product. RedStone is the newest OEV solution, although its base oracles are audited and used.

Switching from Chainlink on Ethereum markets requires careful consideration, making SVR the path of least resistance there. Finally, the trade-off between latency and speed matters: API3 introduces a controlled ~30s delay for its global feed (proven safe), RedStone promises ultra-fast auctions with no delay, and SVR operates at standard Chainlink speeds.

Possible Strategies for Compound

• Single Provider: Choose API3 or RedStone for all networks for consistency. API3 appears strong due to the best revenue share and proven reliability.
• Hybrid Approach: Use Chainlink SVR on Ethereum (leveraging existing integration) and API3/RedStone on L2s/other chains for immediate coverage everywhere.
• Pilot Projects: Start with pilot implementations on specific, perhaps less critical, markets to gather data before a full rollout.

Conclusion: Compound has a choice among three strong OEV solutions. The decision should align with community priorities: maximizing revenue, immediate multi-chain support, proven reliability, or sticking with established providers. API3 stands out with the best combination of revenue share (80%), multi-chain readiness, and proven performance. Chainlink SVR offers ease of integration on Ethereum and Chainlink’s brand trust, but is limited to one chain. RedStone is compelling for its speed and multi-chain support but offers the lowest revenue share and is less battle-tested. A hybrid approach or phased rollout are also sound strategies. Critically, Compound can significantly boost its economics by selecting and implementing the right OEV solution.

Resources & Links

View More

https://www.comp.xyz/t/chainlink-v-api3-a-case-for-protocol-owned-liquidations/6343
https://docs.api3.org/oev-searchers/glossary.html
https://blog.chain.link/chainlink-smart-value-recapture-svr/
https://chainlinktoday.com/aave-integrates-chainlink-svr-on-ethereum-mainnet/
https://x.com/Api3DAO/status/1906973926808318463
https://forum.moonwell.fi/t/additional-revenue-stream-for-moonwell-ecosystem-via-oev-implementation/1392
https://x.com/redstone_defi/status/1806354180518617565
https://docs.api3.org/dapps/#oev-rewards
https://blog.redstone.finance/2024/07/05/oracle-extractable-value-in-defi-part-1what-is-oev-and-how-does-it-work/
https://medium.com/uma-project/use-oval-to-capture-oev-with-redstone-price-feeds-620c8a634152
https://medium.com/@sebc30/understanding-oev-in-defi-c80585607ccd
https://members.delphidigital.io/reports/api3-the-state-of-oev#in-search-of-oev-6e28
https://wublock.substack.com/p/api3-what-is-oev-oracle-extractable
https://x.com/solidifiedhq/status/1387484187993600002
https://certificate.quantstamp.com/full/api-3.pdf
https://docs.redstone.finance/docs/security/audits/

[Kyle]

Hey @PGov, and @woof – Appreciate you pushing this topic forward.

OEV Recap:

In early February, I co-authored a post with @ugurmersin, which catalyzed a conversation about OEV between API3 and Chainlink – and a few days later, @mattgurbiel of Redstone joined in the conversation.

All of this was initiated by API3, who captured ~$150k in OEV on Mantle, and shared a Dune Dashboard, which shows ~$13M lost to Mainnet Markets alone, due to our current liquidation process over the last several years.

In the last two months, I have facilitated a number of discussions to explore the topic:

• Compound’s 𝕏 Community Call with API3 and Redstone.
• Chainlink on their 𝕏 Space about SVR.
• Individual Calls with each Oracle provider, and in person conversations with API3 and Redstone in Denver.
• Calls with Platonia to discuss strategy and evaluation of data, as a neutral third party.

Each Oracle expressed why they were the best solution. I proceeded with the following actions:

• Organized terms for a Trial Structure which met all objections, and allowed a performance based evaluation.
• Secured incentive commitments from Redstone and API3 to serve this Trial Structure.

Unfortunately, a Trial Structure was determined to be too easily gamed, and Compound cannot afford to fragment liquidity on Mainnet – so that approach was nixed.

.:.

Consulting Platonia:

1. Platonia advised that the value of being selected as the OEV service provider could far exceed the cost of gaming the Trial. This risk can be mitigated to some extent by maintaining flexibility in the evaluation period duration and criteria where the outcomes can be reviewed retrospectively by neutral third parties.

2. Platonia also advised that an Insurance fund be established by each OEV Service Provider, to cover the protocol in case of wrongful liquidation, or bad debt caused by delays on the markets they operate.

3. Platonia advised that @Chainlink ought to be assigned to the highest value networks.

In the words of @platonia:

Chainlink has the most to lose, more reputation and market cap at stake. That in itself leads to more safety to Compound.

The insurance fund may provide some ease of mind to the community and hypothetically Chainlink could provide the best insurance in terms of $ coverage, creditworthiness etc but the size of the fund probably isn’t going to be the differentiating factor.

That being said, the more the notional size of the markets the larger the insurance fund should be. So if Chainlink covers all of mainnet where most of the TVL is, the insurance fund they should have to post should be proportionally the largest. This should only apply to markets being trialed so if the initial rollout is very broad there should be more insurance and if its gradual and small in scope then the fund could start small as well.

Having the insurance fund consist of the oracle provider’s tokens themselves would be unfavorable, as in bad events the fund itself would incur losses / be smaller.

A more realistic option is just stables like USDC but the varying degrees of coverage could be:

1. Some blanket promise to make Compound users whole in the event, handshake agreement with no enforcement other than reputation.

2. Park actual USDC in escrow (seems capital inefficient, probably unnecessary).

4. Platonia observed that OEV itself is a symptom of inefficiencies in liquidation processes, and that lending markets on Compound v4, ought to evolve to become more capital efficient by reducing protocol risk in liquidations more cheaply which in turn reduces the magnitude of OEV.

.:.

OEV Update:

Platonia, and AlphaGrowth are aligned on preliminarily exploring the following line of thought:

1. If Chainlink would like to assume responsibility for OEV for Mainnet, and Base Markets following the conclusion of their trial with Aave, Chainlink can offer Compound an Insurance Fund sufficient in size to cover potential SVR failures in those markets.

Chainlink’s solution was designed for Mainnet, and in order to switch to SVR, all that is necessary is to direct from the current Chainlink Price Feeds, to the SVR Feeds.

Chainlink’s current plans are to complete their term of service with Aave, and then move forward with their L2 Expansion plans for SVR. Once these two are completed, they are willing to serve Compound on Mainnet, Base and other chains.

2. If Redstone would like to explore a trial on Unichain and Polygon, they can offer an Insurance fund sufficient in size to cover potential OEV failures in those markets.

Redstone currently serves as the Oracle for Unichain, and their OEV solution was designed to operate on L2s, in partnership with @jacob_fastlane.

3. If API3 would like to continue to operate on Mantle, they will offer an insurance fund sufficient in size to cover tail events, such as misreported data updates in those markets.

Platonia has done retrospective analysis on API3’s OEV solution for Compound on Mantle. They will be releasing the results of this in the next few weeks.

With these safety nets in place, Compound will receive the benefit of OEV on Mainnet, Base, Unichain, Polygon & Mantle.

Platonia will provide ongoing quantitative analysis of the performance of these solutions, and report to the DAO throughout the year.

AlphaGrowth and EigenLayer will facilitate a slashable insurance fund, in partnership with Sherlock, and specific insurance terms will be negotiated with providers.

We believe that this course of action provides each Service Provider the opportunity to demonstrate their strengths, and continue to develop their solutions – while preserving the security of deposits on Compound, and safely increasing revenue to the DAO.

We welcome feedback and contributions from the DAO.

Thank you to all members involved for going through the process necessary to explore this solution.

[ugurmersin]

Gm Kyle,

just to go into this point.

Platonia has done retrospective analysis on API3’s OEV solution for Compound on Mantle. They will be releasing the results of this in the next few weeks.

Currently Compound doesn’t utilize the correct proxies on Mantle that allow for optimal OEV recapture. Compound currently utilizes the “global feed” (mentioned by WOOF! above) meaning, there is no way to bid to update & pay Compound exclusively.

At the time of integration a revamped version of the dApp specific proxies was undergoing audit, which is why the Compound integration on Mantle was performed with the global feeds only. Additionally, the OEV matter on Compound wasn’t approved or cleared which is why we didn’t want to force that in without approval from the DAO either.

It is true however, that we’ve paid Compound well over $150K already on the deployment, because our parnter searchers also have the ability to update the global feed with the 30 second delay, which allowed them to recapture every single liquidation that occured in Feb.

So whatever analysis is currently being done by Platonia on the Compound Mantle Deployment isn’t really reflective of a “correct”/true OEV integration utilizing API3. For that Compound would need to utilize Compound specific proxies, which we would only supply after the DAO approves the usage of an OEV solution.

[Kyle]

GM Ugur,

Platonia did observe the delay you describe in their report.

AlphaGrowth supports approving of OEV specific price feeds for API3, so that more data can be gathered with increased speed of the OEV specific feeds you mention.

We also in agreement that an insurance fund be provided by all OEV Service Providers, as a measure of reassurance for Compound.

One solution might be that the OEV already generated by API3 be deposited toward an insurance fund, and the DAO votes to install the official OEV feeds for Mantle.

Then, API3 OEV would have higher performance in time for the upcoming market expansions and incentives programs being run on Mantle, and Platonia would be able to do another evaluation.

[Thogard]

Hi everyone!

My name is Alex Watts and I am the founder and CEO of FastLane. We’ve been working on OEV together with RedStone for the last year. I saw some misconceptions here about Chainlink SVR vs RedStone OEV and I wanted to point them out.

The fundamental difference between Chainlink SVR and RedStone OEV is that Chainlink sends two transactions: [tx(oracle update), tx(liquidation)] via an MEV bundle, whereas RedStone sends a single transaction: tx(metatx(oracleupdate), [metatx(liquidation)]). There is a significant difference between the levels of trust, centralization, and (most importantly) liveness risk that these two models have, which I believe is important for the Compound governance team to understand when evaluating the solutions.

Chainlink SVR fundamentally trusts the Flashbots relay to keep the oracle update and liquidation bundled together. Unfortunately, the Flashbots relay, itself, trusts block builders (titan builder, beaverbuilder, etc) and then the block relay (ultrasound, bloxroute, etc) to keep those transactions bundled together. The reason why the SVR solution only works on Ethereum Mainnet is because these trusted actors only exist on Ethereum Mainnet.

RedStone OEV, on the other hand, fundamentally assumes that all of the actors in the MEV supply chain are adversarial and dishonest. This assumption is also why the RedStone OEV solution works on all EVM networks - not just Ethereum Mainnet. Where the Chainlink solution has multiple, cascading liveness and trust dependencies, the RedStone OEV solution has none. It accomplishes this by bundling the liquidations with the oracle update inside of a single transaction. The technical term is ‘meta transactions.’ The logic for the atomicity of the liquidations and oracle updates is handled on chain via a trustless, immutable smart contract.

Importantly, this means that FastLane is not working with RedStone as an infrastructure dependency in the same way that Flashbots is working with Chainlink, which is why this sentence is incorrect:

@woof

The winner (or a RedStone relayer) delivers the price and liquidation transaction on-chain, possibly via specialized relays (e.g., Fastlane on Base) or Flashbots alternatives, avoiding the public mempool.

RedStone is RedStone’s relayer. FastLane will send RedStone the liquidation operations, which RedStone takes and includes in the transaction that updates their oracle price. If FastLane goes down then RedStone’s oracle updates are not affected. Importantly, this means that RedStone can easily send transactions to the public mempool or use any relay without disrupting the value recapture by OEV.

In other words, the flow is:

FastLane → RedStone → (all relays + mempool) → proposer

And because FastLane is not in the ‘hot path’ in between the oracle network and the validator, if FastLane goes down then there is no impact on the oracle updates. This is because FastLane primarily operates as a smart contract company, and smart contracts cannot be taken offline. Our infrastructure is simply a way of getting the liquidation operations (meta txs) to the oracle - our solution was explicitly designed not to require any custom transaction relay because those relays are liveness risks that are not appropriate for security-focused lending protocols.

Meanwhile, with chainlink SVR, the flow is:

Chainlink → Flashbots Relay → (permissioned builder) → (permissioned relay) → proposer

The fundamental difference is that Chainlink’s solution depends on third parties to handle the OEV in between the oracle and the blockchain, which adds trust assumptions and dependencies to the hot path, while RedStone’s solution is a combination of gathering liquidations upstream and then settling them on-chain via immutable smart contract auction settlement logic (FastLane’s MEV entrypoint smart contract, ATLAS). Note that the downside of RedStone’s approach is that because it uses trustless smart contract logic instead of trusted intermediaries to handle the auction, it does use more gas, and while that gas cost is paid for in full by the liquidators, that increased gas cost does have an impact on how high the liquidation bids are.

In summary, Chainlink SVR’s solution maintains “atomicity” between the oracle update and the liquidation by trusting multiple parties in the MEV supply chain to behave. RedStone’s atomicity is enforced by just creating a single transaction that uses an immutable on-chain smart contract and assumes the MEV supply chain to be adversarial. If compound is comfortable with adding multiple third party trust assumptions in between itself and its oracle updates, then doing so could lead to marginally higher OEV revenue by virtue of the reduced liquidation gas cost. However, if compound prioritizes decentralization and trustlessness, then it’s clear to me that it would choose the solution that uses immutable smart contract logic rather than trusting handshake deals with block builders and relays.