api3-oev-primary-sources-2026-05-11

Api3 OEV primary sources

Collected: 2026-05-11 UTC

Primary sources reviewed

• https://docs.api3.org/dapps/oev-rewards/
  • Official OEV Rewards docs
  • Used to confirm the live dApp-facing integration path: drop-in OEV-enabled proxy contracts, onboarding steps, native-token payout address requirements, and the 80% revenue share to dApps
• https://github.com/api3dao/oev-litepaper
  • Official OEV litepaper repository
  • Used to anchor the intended mechanism at the protocol-design level
• https://raw.githubusercontent.com/api3dao/oev-litepaper/master/oev-litepaper.tex
  • Litepaper source
  • Used to confirm the framing of OEV as oracle-update-specific MEV and the proposal to auction signed oracle-update rights / meta-transactions to searchers through an order-flow-auction design
• https://github.com/api3dao/contracts
  • Official contracts repository
  • Used to confirm that OEV-auction-related contracts sit inside the same delivered package as the data-feed contracts and proxy tooling
• https://raw.githubusercontent.com/api3dao/contracts/main/README.md
  • Contracts repository README
  • Used to confirm that Api3 treats OEV auctions as part of its contract and integration surface rather than as an entirely external addon
• https://github.com/api3dao/oev-v1-compound
  • Archived official repository for an earlier OEV integration path
  • Used as historical evidence that Api3 treated OEV as a distinct integration layer with dedicated adaptors and onboarding logic
• https://raw.githubusercontent.com/api3dao/oev-v1-compound/main/README.md
  • Archived repository README
  • Used to confirm the historical searcher/dApp integration path and the fact that the earlier implementation is now deprecated in favor of the main docs flow

Local copies saved

• api3-oev-litepaper.pdf

Notes

• Api3 OEV cleared the bar because it is not just another generic MEV mitigation narrative; it exposes a distinct control plane where the oracle becomes the source of privileged update rights and the dApp becomes a beneficiary of the resulting auction revenue.
• The most useful reusable split is between data publication and update-right distribution. Ordinary oracle systems answer “what price is published?” while Api3 OEV additionally answers “who gets to package the update with surrounding profitable operations, and who gets paid for that right?”
• The current docs are especially useful because they show that the mechanism is operationalized through proxy routing and payout administration, not through a completely separate dApp contract interface. That keeps the OEV layer analytically distinct from liquidation engines or sequencer auctions.
• The integration path also reveals the current practical chokepoints: dApp registration, aliasing, feed/chain mapping, payout-address capture, and proxy deployment remain meaningful operator-controlled surfaces even when the orderflow-capture story is decentralized in spirit.
• This entry is worth keeping separate from the parent API3 entry because otherwise the corpus would flatten first-party-source oracles and oracle-side orderflow auctions into one generic oracle brand.