From OEV to API3: How should the oracle solve the OEV problem?
Author: @ShewWang, Geek web3
API3 is a push-based oracle model that currently supports over 140 data sources for 16 blockchains.
Simply put, when the oracle operator detects a deviation between off-chain and on-chain price data, the operator can initiate a transaction to update the price perceived by the on-chain oracle.
When a transaction that can modify the oracle price occurs, it often signifies the generation of MEV. We refer to this MEV that depends on the oracle as OEV (oracle extractable value).
The existence of OEV has led to value redistribution among different stakeholders, and API3 uses an auction mechanism to redistribute OEV as reasonably as possible and strives to bring about faster price updates.
Generation and Extraction of OEV
OEV is a subset of MEV. Here, we briefly introduce how OEV is generated. The core reasons for its generation are as follows:
DeFi systems use oracles to obtain prices and execute liquidation logic based on oracle prices.
There are granularity issues with oracle updates. Only when there is a certain deviation between off-chain and on-chain prices will the on-chain data be updated, and on-chain data updates will be presented in the form of a transaction.
The generation of OEV implies a loss of value for liquidity providers. Some data shows that based on the above two aspects, OEV has three ways of generation:
Frontrunning, where OEV seekers monitor the occurrence of an oracle price update transaction in the transaction pool and can insert their own transaction before this transaction to profit from the price update. This is the most traditional frontrunning trade.
Arbitrage, where due to the on-chain price update of the oracle being dependent on the difference between on-chain and off-chain prices, this means that the oracle quote may be inconsistent with quotes from other systems, creating arbitrage opportunities.
Liquidations, where the oracle's price update triggers a series of liquidations of loan positions, and liquidators can obtain a large amount of liquidation income during the liquidation process.
The profits extracted through frontrunning and arbitrage methods actually represent losses for liquidity providers.
As for the profits obtained from liquidation trades, on one hand, it affects the interests of borrowers because they may lose a significant portion of their funds during the liquidation process, and for lenders, due to the delay in the oracle's quote, the final value of the collateral received may be lower than expected.
For the extraction of OEV, seekers will monitor oracle update transactions in the mempool and bundle the oracle update transactions with their own transactions through MEV infrastructure to execute and obtain profits.
Of course, for arbitrage and liquidation trades, seekers only need to monitor the deviation between on-chain and off-chain prices and ultimately package their own transactions through MEV infrastructure.
Regardless of the process used by the seekers, we can see that the profits from OEV are allocated to the MEV infrastructure and OEV seekers, while the protocols that generate OEV do not receive their rightful income.
GMX's OEV Solution
As a derivative trading platform on-chain, the GMX protocol has a significant amount of OEV space. According to data, OEV has once reduced GMX's profits by 10%.
To avoid the adverse impact of OEV on the GMX protocol, GMX has introduced Rook to address the OEV problem.
Simply put, GMX's oracle updates are executed through Rook, and Rook will extract OEV based on the current market situation to obtain OEV within the market. 80% of these OEV will be returned to the GMX protocol.
GMX grants Rook the right to update the oracle and extract OEV to avoid being extracted by other seekers, while returning 80% of the OEV to the GMX system. This approach is somewhat straightforward.
API3's OEV Auction Solution
Before introducing API3's OEV solution, let's briefly introduce API3's oracle operating principle.
The core of API3 is called the Airnode protocol. This protocol allows API service providers to directly wrap their Web2 APIs as Web3 oracles.
Simply put, the Airnode protocol requires API service providers to use their private keys to sign each data publication. Users can obtain the latest data and its signature from the service provider of the Airnode protocol at any time, and then publish it to the on-chain oracle to update the data.
For API service providers, wrapping their Web2 API services as blockchain oracles actually only requires adding a private key signing step. This greatly reduces the entry barrier for API service providers to enter the oracle field, as a large amount of their infrastructure can be directly reused.
However, under normal circumstances, Web3 DAPP developers do not need to directly obtain data and execute oracle updates through the Airnode protocol. They can directly read data using the contracts provided by API3.
However, it is important to note that in order to save gas fees for data updates, API3 will execute data updates on-chain when there is a significant difference between on-chain and off-chain data.
Based on the Airnode protocol, API3 has implemented an auction scheme similar to Flashbot but tailored for the oracle system to achieve a reasonable distribution of OEV, while also further increasing the frequency of on-chain oracle updates.
The following image shows API3's OEV solution:
API3's OEV solution introduces the OEV Relay as the core of the entire OEV auction process. The OEV Relay collects data within various oracle network nodes and uniformly returns it to the seekers.
The existence of the OEV Relay brings the following two advantages:
It provides all data uniformly to the seekers, reducing the need for individual interactions between the seekers and oracle nodes.
It protects individual oracle nodes within the network, avoiding the initiation of DoS attacks by seekers.
Seekers can obtain aggregated oracle network quote data and their signatures within the OEV Relay. When seekers believe that the current oracle network quote can help them complete certain OEV extraction operations, they will bid with the OEV Relay.
During the bidding process, if the seeker offers the highest bid, the OEV Relay will return a meta-tx that has been signed and can be directly executed on-chain for the update of the on-chain oracle price.
Seekers can bundle this price update transaction with other transactions and execute it on-chain to obtain OEV income. At this point, because the price update transaction is also bundled and executed on-chain, the on-chain oracle price is also updated.
We can see that one consequence of extracting OEV is the efficient update of on-chain oracle prices.
Taking the AAPL/USD data source as an example, before the OEV auction, when there is a 1% deviation between on-chain and off-chain prices, it will trigger an on-chain price update. However, after the OEV auction, seekers may believe that a 0.1% price difference between on-chain and off-chain is sufficient to generate significant OEV income.
This will drive seekers to bid for the meta-tx used for price updates when the difference is 0.1% and execute the transaction. This will accelerate the update of the AAPL/USD data source and will not incur additional oracle update costs for applications using this oracle.
It is foreseeable that as the OEV market expands, seekers will fiercely compete in the auction, leading to the transfer of most of the OEV to the API3 protocol during the auction process.
As mentioned earlier, OEV itself comes from protocols that use oracles. After receiving OEV income, the API3 protocol will distinguish the source of OEV and return it to the corresponding protocol.
Summary
Inspired by the Airnode protocol and Flashbot, API3 has developed an OEV auction scheme, which brings the following advantages:
Returning most of the OEV to the protocols that use oracles
Providing more granular price updates, and oracle users do not need to incur additional costs for higher granularity updates
Compared to GMX's specialized solution, API3's solution is more general, and the users of API3 oracles only need to provide a wallet address, and the API3 protocol will automatically deposit OEV income into this wallet, making the redistribution of OEV more convenient.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
