Recapturing OEV without breaking your oracle

Xora Labs Research  ·  7 min read

Every time an oracle updates a price, it creates a moment where somebody can profit from acting first. That profit is real, it is created by your protocol, and by default it goes to whoever is fastest. Recapturing it is worth doing, but several of the obvious designs quietly trade oracle integrity for revenue.

Where the value comes from

Oracle-extractable value is the profit available to whoever acts on a price update before anyone else. The clearest case is liquidation: a price moves, a position becomes unhealthy, and the first transaction to liquidate it collects the bonus. That bonus is a cost your protocol pays to guarantee someone shows up.

The important observation is that the bonus is usually far larger than the cost of the work. It is priced to guarantee liveness under bad conditions, and most of the time conditions are not bad. The surplus is competed away in priority fees, which means it leaves the system entirely, paid neither to the protocol nor to the user who was liquidated.

Why it is not just ordinary MEV

Two properties make OEV structurally different, and both are exploitable in the protocol's favour.

• You know when it happens. Unlike a random arbitrage, the opportunity is created by a specific, observable event: your oracle updating. That makes it schedulable.
• You control the trigger. The protocol, or the oracle serving it, decides when the update lands on chain. Whoever controls timing controls who gets to act first.

Together these mean the right to act on an update can be sold before the update is published, rather than fought over afterwards.

The auction designs, and what each costs

Three broad approaches, in increasing order of both capture and risk:

• Back-running rights. The oracle update is bundled with the right to submit the next transaction. Searchers bid for that bundle; proceeds return to the protocol. Least invasive, because the update itself is unchanged.
• Auctioned update submission. The right to publish the update is itself sold. Higher capture, but you have now made publication depend on someone winning an auction.
• Protocol-internal liquidation. The protocol liquidates itself and keeps the bonus. Maximum capture and maximum responsibility: you have taken on the liveness obligation you were previously paying others to carry.

Every design that increases capture moves liveness risk from the searcher onto you. That trade can be correct. It should never be accidental.

The failure mode to design against

The dangerous version is any design where a failed or uncompetitive auction delays the price update. Under normal conditions this is invisible. Under the conditions that matter, such as a violent move, a congested chain or searchers withdrawing, it means your oracle goes stale exactly when accuracy is worth the most.

The constraint we hold to is simple: the auction may determine who profits, never whether the price arrives. Practically, that means a hard deadline after which the update publishes unconditionally, with the auction forfeited. Capture is what you optimise; publication is what you guarantee.

Where the proceeds should go

Returning OEV to the treasury is the easy answer and often the wrong one. The value was extracted from a specific user, the one liquidated, and returning part of it as a reduced liquidation penalty is both more defensible and a genuine product differentiator. Splitting between the liquidated user, the protocol and the liquidity providers who bore the risk is more work to account for and, in our view, the design most likely to survive scrutiny.

Working on something like this? Get in touch.