How to Solve the Oracle MEV (OEV) Problem by Using Market Mechanisms?

Note: The original text is compiled from a tweet of over 2,000 words on the official Twitter of Geek web3 about the OEV problem and its solution. Since this topic is particularly intriguing, we have compiled it into a short article for your reference.

What is OEV (Oracle MEV)

Simply put, when the oracle operator monitors a discrepancy between the off-chain and on-chain price data, the operator can initiate a transaction and update the price perceived by the on-chain oracle. When a transaction that can modify the price of the oracle occurs, this often means the generation of MEV. We call this MEV that depends on the oracle OEV (oracle extractable value).

The existence of OEV has resulted in value redistribution among different stakeholders, and API3 claims to use an auction mechanism to make the OEV redistribution as reasonable as possible (allocated through market mechanisms), and try to bring faster and lower-cost price updates.

It is generally believed that the generation and extraction of OEV is a subset of the MEV problem. Here we briefly introduce how OEV is generated. The core reasons lie in the following two aspects:

1. The DeFi system uses oracles to obtain prices and execute liquidation and other logic based on the oracle prices. And asset liquidation often indicates that there is a large profit margin.

2. There is a fine-grained problem in the oracle update. Only when there is a certain deviation between the off-chain and on-chain prices, the on-chain data will be updated, which will be presented in the form of a transaction.

The generation of OEV means the loss of value for liquidity providers. Some data show that based on the above two aspects, there are three ways for OEV to be generated:

Frontrunning: When OEV searchers monitor that an oracle price update transaction appears in the transaction pool, they can insert their own transactions before this transaction to obtain the benefits brought by the price update. This is the most traditional front-running trade.

Arbitrage: Since the on-chain price update of the oracle machine depends on the difference between the on-chain price and the off-chain price, this means that the oracle machine quotation may be inconsistent with the quotation of other systems, and arbitrage space will arise at this time.

Liquidations: The price update of the oracle will trigger the liquidation of a series of lending positions, and the liquidator can obtain a large amount of liquidation income during the liquidation process.

The profits withdrawn with frontrunning and arbitrage methods are actually the losses of the liquidity provider. As for the benefits obtained from liquidation, on the one hand, it affects the interests of the borrower, because the borrower will lose a considerable part of the funds during the liquidation process, and on the other hand, due to the delay in the quotation given by the oracle, the lender finally receives the value of the collateral that may be lower than expected. Therefore, no matter what, the withdrawal of OEV will bring losses to the corresponding Defi protocol in terms of custody property.

The extraction process of OEV is essentially frontrunning

For the extraction of OEV, the searcher will monitor the “oracle data update instructions” in the memory pool, bundle the oracle data update transaction instructions with the transaction instructions initiated by them through the MEV infrastructure, and finally execute them to obtain profits.

Of course, for arbitrage and clearing transactions, searchers only need to monitor the deviation between the on-chain price and the off-chain price, and finally ensure that the transactions they initiate are executed on the chain first through the MEV infrastructure.

Regardless of the process used by searchers, we can see that the benefits of OEV are distributed between the MEV infrastructure and the searchers of OEV, and the protocols that “capture” the OEV value do not receive the benefits they deserve. (According to some data, the OEV problem has previously caused almost 10% of the profits of the GMX platform to be taken away)

In order to solve this problem, GMX, which has contributed a large amount of OEV value and is an on-chain derivatives trading platform, adopted a simple and crude method: let some people designated by themselves capture the OEV value, and then return the OEV value as much as possible to GMX platform.

In this regard, GMX introduced Rook and whitelist. Simply put, GMX’s oracle update is executed through Rook, and Rook will perform an OEV extraction operation based on the current market conditions to obtain the OEV in the market. 80% of these OEV will be returned to the GMX protocol.

To sum up, GMX gives Rooks the right to update the oracle through the whitelist, extract OEV through Rook to avoid being extracted by other searchers, and at the same time return 80% of OEV to the GMX system. This routine is actually a bit simple and crude.

The OEV auction mechanism based on market bidding

Before introducing the OEV auction scheme proposed by API3 that was discussed greatly in recent days, we first briefly introduce the operating principle of API3’s oracle machine. The core of API3 is called the Airnode protocol. This protocol allows API service providers to directly package their Web2 APIs into Web3 oracles.

Simply put, the Airnode protocol requires the API service provider to use its own private key to sign each published data. Users can obtain the latest data and its signature from the Airnode protocol service provider at any time, and then publish it to the on-chain oracle to update the data.

For API service providers, packaging their Web2 API services as blockchain oracles actually only requires adding a private key signature link. A large amount of the API service provider’s infrastructure can be directly reused, which greatly reduces the threshold for API businesses to enter the field of oracle machines.

Based on the Airnode protocol, API3 uses an auction scheme similar to flashbot but targeted at the oracle system to achieve a reasonable distribution of OEV, and at the same time further increase the update frequency of the oracle on the chain. The following figure shows the OEV scheme of API3:

API3 allows anyone to actively update the data recorded on their oracle contract through bidding, and introduces the OEV Relay node as the core of the entire OEV auction process. OEV Relay collects data in each oracle network node and returns it to the searcher. The searcher then uses it to update the data recorded on the API3 oracle, and takes the opportunity to bundle MEV transactions together.

The existence of OEV Relay brings the following two advantages:

1. Provide all data to searchers in a unified manner and reduce the number of searchers interacting with oracle nodes alone;

2. Protect a single oracle node in the network and prevent a single oracle node from being attacked by DoS attacks conducted by searchers;

Searchers can obtain aggregated oracle network quotation data and signatures within OEV Relay. When searchers believe that the current oracle network quotation can help them complete certain OEV extraction operations, searchers will initiate a bid to OEV Relay.

During the bidding process, if the searcher gives the highest bid, OEV Relay will return a meta-tx that has been signed and can be directly uploaded to the chain for price update of the oracle machine on the chain. Searchers can package this price update transaction with other transactions on the chain and execute it to obtain OEV income. At this time, since the price update transaction is also packaged on the chain, the price of the oracle on the chain is also updated.

We can see that one effect of supporting OEV auctions is to achieve high-frequency updates of on-chain oracle prices. Taking the AAPL/USD data source as an example, before there is an OEV auction, when the off-chain and on-chain prices deviate by 1%, this large deviation will cause the oracle to actively update the on-chain prices.

But if the oracle machine allows the outside world to submit data update instructions to it after the OEV auction is opened, searchers may think that the 0.1% price difference between the on-chain and off-chain prices can bring huge OEV benefits. This will drive searchers to take the meta-tx for price update when the price difference is 0.1%, and upload the transaction order to the chain.

This will speed up updates to the AAPL/USD data source without incurring additional oracle update costs for applications using this oracle.

Therefore, the cost of oracle data update is passed on to OEV value capturers, and API3’s OEV Relay can obtain large bidding fees from OEV players, and then feed these fees back to the Defi protocol that captures the OEV value.

It is foreseeable that as the OEV market expands, searchers will compete fiercely on the auction price, causing most (even 95%) of the OEV value to be transferred to the API3 protocol. After the API3 protocol receives this part of the OEV revenue, it will differentiate the source of OEV value and return it to the Defi protocol where the OEV value was captured.

It should also be noted that for insurance purposes, API3 will automatically perform data update operations when the difference between on-chain data and off-chain data is large, provided that no OEV auctioneer has actively updated the data recorded in the API3 contract.

Summary

Based on the Airnode protocol and inspired by Flashbot, API3 developed an OEV auction solution, which brings the following advantages:

Return most of the OEV to protocols that use oracle price feeds, providing more fine-grained price updates; protocol platforms that use oracle price feeds do not need to pay high costs for more fine-grained data updates. This cost is passed on to the OEV front-runners who bid through auctions.

Compared with GMX’s specialized solution, API3’s solution is more versatile. Moreover, the user of the API3 oracle only needs to provide a wallet address, and the API3 protocol will automatically transfer OEV income into this wallet, making the redistribution of OEV more convenient .

Disclaimer：

1. This article is reprinted from [PANews], All copyrights belong to the original author [Geek Web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.