Author: Shew, Geek web3
Note: The original text is compiled from a tweet of more than 2,000 words on the official Twitter of Geek web3 about the OEV problem and its solution. Since this topic is special Interesting, we have compiled it into a short article for your reference.
What is OEV (Oracle MEV)
To put it simply, when the oracle operator monitors a deviation between the off-chain and on-chain price data, the operator can initiate a transaction , 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 the auction mechanism to make the OEV redistribution as reasonable as possible (allocated through market mechanisms) and try to bring for faster, 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 means 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 will the on-chain data be updated, and the on-chain data update will be presented in the form of a transaction.
The generation of OEV means the loss of value of liquidity providers. Some data show that based on the above two aspects, there are the following three ways to generate OEV:
Frontrunning, That’s front-running. 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, that is, 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
< p>
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 through Frontrunning and Arbitrage are actually the losses of the liquidity provider. As for the benefits obtained from Liquidations 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 for the lender, due to the delay in the quotation given by the oracle, it finally receives The value of the collateral may be lower than expected. So no matter what, the withdrawal of OEV will bring losses to the custody property of the corresponding Defi protocol.
The extraction process of OEV: the essence is still a front-running
For the extraction of OEV, the searcher will monitor the "oracle data update command" in the memory pool , through the MEV infrastructure, the updated transaction instructions of the oracle data are bundled with the transaction instructions initiated by itself, and finally executed to obtain profits.
Of course, for arbitrage and liquidation transactions, searchers only need to monitor the deviation between the on-chain price and the off-chain price, and finally use the MEV infrastructure to ensure that the transactions they initiate are executed on the chain first. Can.
Regardless of the process used by the searchers, we can seethat the proceeds from OEV are distributed between the MEV infrastructure and the searchers of OEV, while the OEV value is “captured” by the protocol, and Didn't get the benefits it deserved. (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, a large amount of OEV value was contributed as an on-chain derivative. The GMX trading platform adopts a simple and crude method: let some people you designate capture the OEV value, and then return the OEV value to the GMX platform as much as possible.
p>
In response, GMX introduced Rook and whitelist. To put it simply, 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 GMX system. This routine is actually a bit simple and crude.
OEV auction mechanism based on market bidding
Before introducing the recently discussed OEV auction scheme proposed by API3, we first briefly introduce the operating principle of API3’s oracle machine . The core ofAPI3 is called the Airnode protocol. This protocol allows API service providers to directly package their Web2 APIs into Web3 oracles.
To put it simply, 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 infrastructure of API service providers can be directly replicated. This greatly reduces the threshold for API service providers to enter the oracle field.
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. It can also further improve the on-chain The update frequency of the oracle. The following figure shows the OEV solution 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. Provides all data to searchers in a unified manner, reducing the need for searchers to interact with oracle nodes alone. Event;
2. Protect a single oracle node in the network to prevent a single oracle node from being attacked by DoS attacks by searchers;
Searchers can obtain aggregated oracles in OEV Relay Machine network quotation data and its signature, when the searcher believes that the current oracle network quotation can help it complete certain OEV extraction operations, the searcher will initiate a bid to OEV Relay.
During the bidding process, if the searcher gives the highest bid, OEV Relay will return a meta that has been signed and can be directly uploaded to the chain for price update of the oracle machine. -tx. 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 allowing OEV auctions is to achieve high-frequency updates of the oracle price on the chain. Take the AAPL/USD data source as an example. Before the OEV auction, when the off-chain and on-chain prices deviated by 1%, this large deviation would cause the oracle to actively update the on-chain prices. .
But if after the OEV auction is opened, the oracle allows the outside world to submit data update instructions to it, searchers may think that the 0.1% price difference between the on-chain and off-chain can bring huge results. of OEV earnings. 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.
So, the cost of oracle data update is passed on to OEV value capturers, and API3’s OEV Relay can obtain large amounts of bidding fees from OEV players, and then These fees feed back into the Defi protocol that captures the OEV value.
It is foreseeable that as the OEV market expands, searchers will compete fiercely on auction prices, resulting in most (even 95%) of the OEV value being transferred to the API3 protocol, and API3 After the protocol receives this part of OEV income, it will distinguish the source of the OEV value and return it to the Defi protocol that captured the OEV value.
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 API3 contract. Recorded data.
Summary
Based on the Airnode protocol and inspiration from Flashbot, API3 developed an OEV auction scheme, which brings the following advantages:
Returns most of the OEV It provides more fine-grained price updates for protocols that use oracle price feeds.And protocol platforms that use oracle machine price feeds do not need to pay high costs for more fine-grained data updates. This part of the cost is through auctions. Passed on to OEV front-runners who bid.
Compared with GMX’s specialized solution, API3’s solution is more versatile, and the user of the API3 oracle only needs to provide the wallet address, and the API3 protocol will automatically generate OEV income. Enter this wallet to make the redistribution of OEV more convenient.