Api3 OEV

• Name: Api3 OEV
• URL: https://docs.api3.org/dapps/oev-rewards/
• Category: oracle-side orderflow auction / OEV recapture middleware / dApp revenue-sharing oracle extension
• Tags: ethereum-ecosystem
• Summary: Api3 OEV is an oracle-side orderflow auction bolted onto the API3 feed stack. The point is not generic MEV mitigation. It is to route oracle-update rights through dApp-specific proxies, sell those rights to searchers, and send most of the recovered value back to the integrating application.
• What it does:
  • Lets dApps swap ordinary API3 reader proxies for OEV-enabled Api3ReaderProxyV1 contracts without changing the basic read path
  • Sells oracle-update rights to specialized searchers instead of leaving update-adjacent value entirely to public liquidators and block producers
  • Sends 80% of recaptured OEV back to the integrating dApp and keeps the remainder as protocol revenue
  • Makes dApp registration, feed onboarding, proxy assignment, and payout-address configuration the practical integration choke points
  • Turns the feed stack into a searcher-routing and revenue-share layer rather than only a price-publication layer
• Key claims:
  • The OEV litepaper defines oracle extractable value as the MEV created by oracle updates or by their absence, then proposes auctioning the right to request signed oracle meta-transactions so the dApp can capture part of that rent.
  • That means the oracle stack is not just publishing data. It is also deciding who gets privileged access to update-triggered execution opportunities.
  • The current docs keep the mechanism narrow and legible: replace the old proxy, let Api3 handle the OEV-specific onboarding path, and receive native-token payouts from the recovered value.
  • The 80% dApp revenue share is the part that matters. This is an oracle feed with an attached rent-routing policy, not just a nicer update path.
  • The real control surface still sits with bidder access, dApp onboarding, proxy assignment, and payout accounting. The auction may move value away from ordinary MEV capture, but Api3 still controls meaningful admission and routing points.
  • The archived oev-v1-compound repository is useful because it shows Api3 treated OEV as its own integration layer with dedicated adaptors and onboarding logic rather than as a trivial feature flag.
  • Api3 OEV belongs in the corpus because it is a clean oracle-side comparison point for orderflow auctions: the auctioned right is the oracle update itself, not generic protocol orderflow or sequencer priority.
• Whitepaper: The strongest primary materials in this pass were the official OEV litepaper PDF, the current OEV Rewards docs, the contracts repository, and the archived OEV integration repository; see ../whitepapers/api3-oev-primary-sources-2026-05-11.md.
• Sources:
  • https://docs.api3.org/dapps/oev-rewards/
  • https://github.com/api3dao/oev-litepaper
  • https://raw.githubusercontent.com/api3dao/oev-litepaper/master/oev-litepaper.tex
  • https://github.com/api3dao/contracts
  • https://raw.githubusercontent.com/api3dao/contracts/main/README.md
  • https://github.com/api3dao/oev-v1-compound
  • https://raw.githubusercontent.com/api3dao/oev-v1-compound/main/README.md

Internal linkages

• Base stack context: api3
• Strongest auction-layer comparisons: express-relay and flashbots-auction

Comparison cut

• Keep the comparison set narrow: Express Relay and Flashbots Auction for auction-layer analogues, and API3 for the feed stack underneath this thinner rent-routing layer.

Governance / control risk

• The real questions are who gets bidder access, who decides which dApps and feeds receive OEV routing, how transparent payout accounting is, and how much discretion Api3 keeps over proxy assignment.

• The rent sits in access control and routing, not in some abstract oracle innovation story.

• Last reviewed: 2026-05-30 UTC