Oracles and the New Frontier for Application-Owned Orderflow Auctions

Today, we are excited to announce our investment in Pyth Network, the leading first-party oracle in crypto.

The implicit premise behind legacy oracles in crypto has been that all data—including financial data—is freely available and accessible to on-chain contracts. Accordingly, oracles simply need to incentivize supply-side network contributors to scrape and aggregate this data, come to consensus on it, and bring it on-chain. While this method may work for widely available public datasets, such as weather data or election outcomes, it largely does not generally work for latency-sensitive data, like financial data. For latency-sensitive data, large market participants (e.g., HFT firms, market makers and lit order book exchanges for equities) are actually superior data sources compared to 3rd-party aggregators because they create—rather than just scrape—it, and therefore possess inherently higher-quality, lower-latency data.

Pyth’s oracle design is guided by the thesis that first-party financial data is not naturally open; rather, it's proprietary to its creators. Financial data is generated, not aggregated, via open market transactions across a breadth of CeFi exchange venues, and these venues, along with groups who trade on them most frequently, are the best sources of data. Accordingly, Pyth partners directly with first-party data partners—market makers, trading desks, exchanges, etc.—instead of third-party aggregators to deliver direct, low-latency price updates on-chain.

Pyth first launched in 2021, and since then has partnered CBOE, Wintermute, Two Sigma, Cumberland and 90 other market makers, exchanges, and other first-party data partners. Today, Pyth delivers mid-market prices and confidence intervals on more than 400 tickers—e.g., BTC, TSLA, EUR/USD, crypto, equities, FX, commodities, rates assets, etc.—and delivers high-fidelity data to over 45 different chains, while securing over $1.7B in value across some of the space’s largest protocols in the space, including MarginFi, Drift, Helium, Jupiter, Synthetix, and Hashflow—and 90 others.

In addition to pioneering the first-party data contributor model in crypto, Pyth also pioneered a pull-based price publishing model. Instead of constantly pushing data on chain at some defined interval (e.g., every time there is a 50bps price deviation, or every hour for oracles like Chainlink), Pyth allows smart contracts to pull precise data at the exact moment they need it. This is a fundamentally new design that results in fresher, more accurate prices than oracles that only update on arbitrary, epochal basises. It also structurally reduces costs for user-protocols and applications because they don't need to constantly pay gas for unnecessary updates. This design also makes Pyth inherently able to scale asset and chain coverage faster because the pull mechanism removes the need for individual oracle deployments. For instance, applications building on Base and Mantle were able to integrate Pyth immediately because Pyth didn’t need to write any custom code.

As a firm, we’re deeply interested in oracles because they are a foundational primitive for application development in crypto and serve as the bridge between off-chain and on-chain state. Their primary job is to keep prices consistent across liquidity venues; however, behind that, there is a vast design space to capture and redistribute value from emergent state transitions. In our research, Pyth’s model is best positioned today to capture that opportunity and pave the way for protocols and applications to unlock new lines of revenue via oracle extractable value (OEV).

An Introduction to Oracle Extractable Value

As a refresher, miner extractable value (MEV) is largely a misnomer. Today, it broadly refers to the profits captured by validators and stakers from arbitrage or liquidation opportunities that arise from the reordering of transactions that capitalize on temporary state inconsistencies. In many cases, MEV emerges when there is a dislocation between price as represented by the application, and price as represented by the canonically accurate external off-chain state. Oracle extractable value (OEV) is a subset of MEV in which applications rely on an oracle update for arbitrageurs or liquidators to capitalize on this state inconsistency.

By bringing external data (like public market prices) on-chain, oracles naturally mediate valuable blockspace. This creates lucrative windows for arbitrages and liquidations between states and presents opportunities for oracles themselves to step into the MEV lifecycle—either directly or via auction dynamics—and capture some of the MEV that emerges from their price updates.

In push-based oracle systems, the transaction space immediately following an oracle update is highly contested. In pull-based oracle systems, applications have more autonomy over how they choose to incorporate the update into their application, which therefore gives them more control over MEV extraction and/or redistribution systems.

Let’s walk through two examples where MEV opportunities present based on state transitions: one where OEV is not present, and another where OEV is.

1. MEV (Oracle-Independent): Application state is either organically, or through some on-chain action, out of line with external state. For example, if a whale trader executes a large buy order against a constant-product AMM exchange therefore throwing the quote price out of line with the external price, a bot can capture that MEV by correcting the dislocation and closing the arbitrage without the protocol directly needing an update.
2. OEV (Oracle-Dependent): A price change on external markets creates profitable opportunities to bring the application state back into line with the canonical, off-chain state after an oracle imports the updated state on chain. For example, a MEV bot on a borrow-lend protocol may choose to liquidate an account that is underwater after adverse price moves on price discovery centralized exchanges.

We classify OEV as the latter in this categorization, in which an oracle update triggers the opportunity for value capture. Today, activity that generates OEV disproportionately benefits validators and stakers at the expense of their users, the liquidity providers. If protocols and applications are able to capture more OEV, they can redistribute these profits to incentivize and reward user loyalty. Ultimately, the ability to align OEV with users makes user-protocols more competitive. Application design for MEV capture is difficult. All applications have a desire to minimize MEV for their users, and redistribute what’s left efficiently to their users, or internalize it themselves. Many developers today think the only way to do this is to deploy their protocols as standalone app-chains with the goal of accruing value to their native tokens via MEV, but this introduces vast technical, operational, interoperability complexity. The first-order correct solution to internalizing MEV is to operate an orderflow auction (OFA). OFAs facilitate a market where the supply side consists of a batch of MEV-prone transactions aggregated by an application, and the demand side consists of MEV bots or market makers that seek to insert or reorder those transactions in a manner that benefits them. The proceeds of the auction go directly to the application, and represent a share of the net MEV generated that applications can capture for themselves.

Operationalizing OEV Capture

The seemingly intuitive approach would be for applications to spin up their own orderflow auctions and realize profits from bids on the blockspace that surrounds oracle updates. This is, however, a non-trivial endeavor. Each application controls a limited amount of orderflow, and OFAs are fundamentally marketplaces that rely on deep liquidity on both maker (user transaction batches) and taker (MEV bots) sides. Application-specific OFAs would fragment liquidity and limit atomic composability (e.g., carrying out a liquidation often requires a token swap after the collateral has been seized to complete the arbitrage, if the MEV bot cannot guarantee that both legs of the strategy occur exactly as they intend, they may reject the opportunity entirely). The operational and social overhead of configuring application-specific OFAs may be too steep to justify building an in-house solution.

A better route to capturing emergent MEV is to outsource the auction via a global orderflow auction (GOFA). Pyth is structurally positioned to run OFAs directly in aggregate for all the applications it powers since those applications already rely on Pyth’s oracle updates to keep their systems functional. As such, Pyth holds access to high-value blockspace across a large set of applications, and the natural next step is to commoditize the complement by mediating the blockspace surrounding the oracle update (i.e. the portions of the block where MEV is extracted).

Rather than each application reinventing the wheel, an oracle-run GOFA leverages natural economies of scale. Deep liquidity begets more liquidity: MEV bots are more likely to be takers of bundled orderflow across multiple applications (due to atomic composability), and more applications are incentivized to participate when there are more competitive takers (submitting higher bids that translate directly into revenue for the applications).

New Frontiers for Pro-Application OEV

OEV represents a novel approach toward value capture for oracles and applications. Oracle-run OFAs directly deliver the emergent value from OEV to applications, thereby allowing applications to receive the benefits of owning their own OFA without any of the overhead. As neutral third parties to the exchange of orderflow between applications and MEV bots, Pyth has the option to command a service fee from either party, introducing a new line of revenue for the network without compromising neutrality in the ecosystem. We are excited about novel mechanisms that channel toward a tighter capture of MEV directly at the application layer. To view Pyth price feeds or learn how to integrate them into your applications, please visit the Pyth documentation portal.