In Search of OEV

Validators, builders, and searchers possess privileged access to transactions before they are finalized into blocks. These entities can extract value or MEV by inserting and reordering transactions included in successful blocks. The lower end of estimations for the MEV market size on Ethereum is roughly $1 Bn. This is gathered from what is observable deterministically. The actual market size of MEV could span much higher as it would account for cross-domain MEV, Multi-block MEV, and more. 

Value extraction strategies centered around an oracle update transaction seen in a mempool can be classified as OEV or Oracle Extractible Value. Searchers use methods such as front running, arbitrage, and liquidations to capture OEV. On the Ethereum mainnet, lending protocols have paid over $180M in liquidation incentives to liquidators/searchers.  

Research and implementation of MEV mitigation solutions have been a major focus in the Ethereum community so far, but they have mostly been limited to DEXs because they have the most value flows. Now, we’re seeing OEV solutions catering to protocols that rely on oracles, such as lending and perpetual DEX protocols. In this report, we will take a closer look at the state of OEV on lending protocols and study OEV solutions put forth by API3, UMA, and Pyth.   

There are three primary forms of MEV extraction around Oracle updates:

1. Frontrunning

Searchers notice a pending Oracle update in the mempool and create a bundle of transactions where they insert their value-extracting transactions ahead of the Oracle update. They effectively execute their transaction at a more favorable price before the Oracle price update takes effect across the state of the blockchain. 

2. Arbitrage

With arbitrage, searchers try to take advantage of price differences across DEXs and CEXs. Perpetual DEX protocols such as GMX and Synthetix have been subject to toxic flow due to searchers running arbitrage and frontrunning strategies.

3. Liquidations

Now, coming to focus, liquidations are a backrun strategy used by searchers, who insert their transactions after the Oracle update. Based on Flashbots data, about seven of the top ten most valuable MEV-capturing transactions have been liquidations.

So, what does a liquidation look like? To borrow from lending protocols like Aave or Compound, users deposit collateral before they can borrow. Once a loan is taken out, the health factor of the loan is monitored based on the value of the collateral to the loan and a liquidation threshold. In most cases, the value of the collateral is higher than the loan’s value. Aave, for example, allows users to borrow only up to 80% of collateral value and Instadapp’s fluid up to 95%.

Now, if the collateral’s value drops due to market fluctuations, the collateral is at risk of being liquidated or sold off. This is because the loan’s health factor would have decreased and reached the liquidation threshold. This way, the protocol would not have to carry bad debt and have its lenders bear losses. When the collateral value breaches the liquidation threshold, lending protocols usually allow third parties (searchers) or their bots to liquidate the collateral. Liquidators are incentivized to perform liquidations as the protocol avoids bad debt if the collateral value continues to drop. 

Most lending protocols rely on external oracles to help value or price the collateral. Oracles update the prices of collaterals by aggregating off-chain data in an oracle contract, and lending protocols consume price data in the form of an on-chain transaction. Searchers keep track of the loans at risk of crossing the liquidation threshold and the oracle’s transaction in the mempool, which would update the collateral’s price. When a searcher comes across a potential liquidation opportunity, they backrun the upcoming oracle price update with the transactions that would perform the liquidation placed directly after the oracle transaction.

 

In these transactions, the searcher buys off the collateral from the protocol, repays the loan with their funds, or borrows through a flash loan to receive the collateral. The protocol applies a liquidation penalty to the collateral on the user for having a lower collateralization ratio. These penalties can range from 0.1% to more than 20%. Collectively, lending protocols on Ethereum Mainnet have liquidated over $3.1Bn. 

Liquidations are mostly considered “good MEV,” as searchers benefit the protocol and its LPs by helping with liquidations. Searchers are incentivized with a liquidation bonus for liquidating loans that have helped the protocol not accrue bad debt or losses to the LPs. This also preserves lenders’ value on the protocol by ensuring they get back what they lent. The chart below shows liquidator revenue on Aave v2 and v3.

But often, liquidators don’t enjoy most of their liquidation profits. They have to give away most of their liquidation profits to block builders in the form of tips/bribes. These conditions have gotten worse for liquidators since the merge. We will dive deeper into the reasons below.

 

How Auction Design Influences Value Capture

But why does most of the value flow to block builders and validators? A couple of different factors lead to such a market condition. Block builders and validators play a crucial role in forming new blocks. As a result, they have significant control over the ordering of transactions and the inclusion of blocks. To further exasperate the situation, we have high levels of centralization among block builders, with just 3 Builders taking up 95% of the total block-building market. They’ve established dominance partly due to their block-building advantages due to private order flow access. This is heavily influenced by the nature of auctions in which searchers play bribing games for better chances of inclusion.

The currently used Flashbots auction allows bidders to submit sealed bids. The bid amounts remain sealed until MEV has been extracted, so bidders have no real-time idea of the value of the bids placed by other bidders. To win the auction, liquidators place higher bids, sacrificing their MEV revenue from liquidations.

The liquidation mechanism used by a lending protocol also dictates the flow of OEV. We will review auction designs and liquidation mechanisms to understand this issue and explore potential solutions in the space.

Auctions allow value exchange between those who own a commodity (sellers) and those willing to pay for it (bidders). In an auction, the commodity is sold to the bidder willing to pay the highest price. An auctioneer holds a significant influence over an auction as they host the auction, collect bids, select a winning bidder, and may even facilitate the transfer of the commodity to the winner. 

Such auctions are held at several points in the Ethereum transaction supply chain. The sellers ultimately are users who originate transactions, the commodity being valuable transactions, and the bidders are searchers and block builders. In these auctions, bidders compete to capture profits by winning the right to include their version of the Ethereum state’s future in the following finalized blocks. 

Some lending protocols also utilize auction mechanisms as an inherent part of their function. These mechanisms liquidate positions that may accrue bad debt. Let’s look at what kind of auction mechanisms are used in lending protocols. 

Lending Protocol Auctions

Among the few lending protocols that use auctions, Dutch auctions are mainly utilized to liquidate collateral. MakerDAO, however, initially used an English Auction. This is where bidders’ bids are publicly known. This design required liquidators to lock up capital until the auction terminated. MakerDAO and several other lending protocols, like Euler, Yield, and even Oracle-less protocols like Ajna, use Dutch Auctions.

In a Dutch auction, the price of the collateral starts much higher and gradually decreases over time until the collateral is sold off. There are no vital capital lock-up requirements for bidders. With Ajna, an auction could last for over 72 hours, with the collateral price starting 256 times higher and gradually decreasing until the price reaches 0. While beneficial to borrowers, Dutch auctions are not the most efficient at timely liquidations or preventing OEV extraction. Most liquidations happen across short periods of high market volatility. The collateral price may crash even as the auction price gradually decreases.

Some protocols, like Maker, have a reset function in their auctions to mitigate this. Even Dutch auctions can be reset when too much time has passed since the start of the auction. This measure could also be set in place when the price of the collateral has changed drastically.

Intent-based DEXs Auctions

We see auctions being used in intent-based DEXs as well, and unlike auctions used in lending protocols, they help reduce MEV extraction. These auctions take place on the earlier end of the transaction supply chain. Intext-based DEX such as Cowswap, UniswapX, and 1inch Fusion rely on auctions where solvers compete to fill users’ intents. CowSwap runs Single Block Batch Auctions where all trades in a batch are cleared at a uniform price. With a uniform clearing price across the whole batch, reordering transactions within a batch wouldn’t reap as much MEV as the position of orders/transactions in a batch is irrelevant, reducing MEV extraction to a high degree.

UniswapX and 1inch Fusion run Dutch Auctions with an exclusive period for the winner. When users place orders, the Dutch Auction starts at a price that is better for the user than the user stated. For example, if a user’s sell order states $3000 for 1 ETH, the auction may start at $3050. The price will then decay over time until it reaches the worst possible price the user is willing to pay, with slippage factored in the price. 

The idea behind the protocol-held auctions mentioned above is simple: Reduce MEV extraction and aim to return extracted value to the protocol and the user. 

While these mechanisms work well for transactions originating from DEXs vulnerable to searcher strategies, users of oracle-based lending protocols remain susceptible to liquidations. Even when there is an OFA setup, the competition to capture the liquidation honey pot moves into blockspace auctions. Let’s take a closer look at them.

Blockspace Auctions

The idea with OFAs is to capture value bleeding away to validators and return it to originators such as users and protocols; not all auction mechanisms help with this recapturing. Blockspace auctions on Ethereum mainly bleed value away toward validators. Let’s examine some of these auction mechanisms in the Ethereum transaction supply chain and see how they influence the flow of value, competition, centralization, and a protocol’s general welfare.

Blockspace auctions occur in two main ways: the first between searchers and block builders and the second between block builders and Proposers. Searchers bid for the right to order their bundle of transactions within a block according to their preferences, making value extraction possible for the searchers. Searchers bidding the highest win the auctions. Auction mechanisms such as MEV Share and MEV Blocker capture MEV and split the rewards between users and block builders. 

 

After PBS, in MEV Boost auctions, Block Builders aggregate bundles and transactions from private and public sources to create a block. Block builders bid with these blocks, and a relayer is an auctioneer who selects a valuable block. Builders compete with each other in an English auction to have the proposer propose the block they created. Bidders keep bidding higher against each other with thousands of bids per second until no one else is willing to bid more. The Block Builder bidding the highest wins the PBS auction. 

These auction mechanisms demonstrate a consistent pattern: a unidirectional flow of value. In competitive MEV strategies, where the potential for value extraction is highest, searchers must allocate a significant portion of their MEV revenue to secure winning bids in blockspace auctions. Block builders then recycle this bidding fee to participate in PBS auctions.

Among these strategies, liquidations are a remarkably competitive “short-tail” MEV strategy. Searchers engage in intense bidding wars in these auctions, using their war chest capital or flash loans to outbid one another. Consequently, despite capturing substantial value (OEV), searchers pay a significant portion—often up to 99%—of their profits to validators. 

Here’s an example from Aave: A position worth $4.1M was liquidated, and a liquidation bonus of $141,477 was paid to a searcher. The searcher used $141,416 of the gains to pay a bribe to a block builder just so the searcher could have the right to liquidate that position. 

This is because block builders are positioned as gatekeepers of transaction inclusion in blocks. It gives them undue power over value extraction, especially with growing centralization in the block-building market. It is not in the best interests of users or protocols to have dependencies such as liquidations under the mercy of block builders accepting costly bribes. While the above chart may show higher searcher profit in protocols like MakerDAO and Compound, it is essential to note that it may have been a vertically integrated searcher builder. It is widely known that 2 3 top block builders, Beaverbuild and r-sync, are vertically integrated across the stack.

What if we could move the auction down to the oracle level? Successful liquidations are reliant upon the execution of a price update transaction sent by oracles. Oracle price update transactions can be commoditized and sold in auctions to searchers who perform liquidations. This way, the rights to liquidate a position will only be given to a single bidder. This way,  when it comes to bundle inclusion in blocks, it is doubtful that there will be a searcher competition that bids up the amount of bribe/tip paid to builders. 

But bringing the auction down to the oracle level isn’t free of trade-offs. Centralization vectors could be added as lending protocols already rely on Oracles for price updates. Giving oracles more ground to control how and when liquidations happen could exasperate the situation. Effective decentralization and incentive design will be essential for oracles that have chosen this route.

Now, we’ve understood how several aspects of an auction design can influence the flow of value: the position of the auction, the role of the auctioneer, the level of competition, and the nature of bidding. Let’s examine oracle-based auction mechanisms aimed at OEV, such as API3’s OEV Network, UMA’s Oval, and Pyth’s Express Relay. 

 

API3’s OEV Network

OEV Network is an Optimistic rollup built on Arbitrum’s Orbit stack, solely created to conduct Order Flow Auctions that recapture OEV leaking away from oracle-reliant protocols. With OEV Network, an auction is introduced back at the oracle level, where searchers compete to win the right to call an oracle price update transaction. This shifts the power dynamics of capturing OEV from the block builder to the Oracle. How is this done? Only the auction winner can use the price update transaction to liquidate collateral. Value leaking away towards validators can now be internalized within oracle-reliant protocols and their users. Let’s go over some core components of OEV Network’s architecture. 

OEV Network Architecture

dAPIs/Oracles – API3’s dAPIs are data feeds from first-party sources operated by the data providers.

Auctioneer Node – OEV Network auctions are conducted by the Auctioneer Node. As of now, there is a single node that manages all auctions on the OEV Network. The auctioneer node is responsible for selecting and announcing the winning bidder. The auctioneer is also responsible for creating the meta transaction with the winning bidder’s details.

Bonding Contract—Bidders must deposit collateral on OEV Network in binding contracts to place bids. The collateral is set to be about 10% of their bid.

Meta Transaction—The winning bidders are awarded a meta transaction. This meta transaction allows the bidder to use the oracle update, perform the liquidation, and capture OEV. Multiple oracle providers sign this transaction with the winning bidders’ details. This way, the winner can only use the transaction, and no one else can front-run them.

 

Auction Process

Let’s go over how the OEV Network works.  

1. To participate in OEV Network auctions, liquidators bridge ETH to OEV Network to create a deposit. This amount will be used to place bids in auctions. As searchers will bid for a price update and the right to use it, the oracle costs can be offloaded to searchers. This way, price feeds can be more granular. 
2. When a bidder wins an auction, the auctioneer pushes a meta-transaction to the OEV Network. This meta transaction contains details of the winning bidders and how much they bid. The data feed updates cryptographically signed data from all relevant Oracle nodes. 
3. Once the auction has concluded, the winning searcher fetches the meta transaction from the OEV Network. The meta transaction is signed with the winning bidder’s public key. This way, no other searcher can front-run the winning bidder with another price update, as it will not have the oracle’s signature, rendering their transaction useless.
4. The winning searcher then performs liquidations on the respective chain where the opportunity was present. To complete the liquidation, the searcher performs an atomic transaction in which it executes the Oracle price update, extracts OEV, and pays the bids. To ensure that searchers pay their bids when the data feed is updated, the bid amount will be included in the meta transaction utilizing the signature added by all the Oracle nodes individually. This way, searchers must pay their bids to use the price update to capture OEV. 

As we previously discussed, one key reason searchers end up bidding most of their liquidation revenue to block builders is that searchers one-up each other in bidding wars to pay the highest bid and win the auction. So, how will this auction be any different?

Bidding In Private

Most OFA mechanisms use an English auction where bidders can see each other’s quotes and raise bids. Initially, OEV Network will also operate using an English auction and later transition to a First-Price Sealed-bid Auction (FPBSA) that is fully on-chain. Bidders submit their bids to the auctioneer in an encrypted format in this auction. Searchers would be unable to learn who their competitors are and how much they are bidding, preventing the drastic increase in the number of bids that will be placed on the chain. Only the auctioneer is allowed to view bidder identities and their bids. Once the auctioneer has viewed the encrypted bid values, the highest-paying bidder will be chosen as the winner. This also ensures that searcher bidding strategies are hidden.

But hiding bidder identities and bids is not as straightforward as it seems. Encryption using cryptographic tools comes at additional costs. Actions like deploying the auction, bidding, revealing the bids and claiming the rewards incur gas costs if the auction is hosted on-chain. A paper by Menelaos Kokaras and Magda Foti studying the costs of privacy on blockchains wrote that hiding an identity on-chain can potentially increase gas costs up to 2.5 times. This adds a limitation concerning how innovative an auction design could be. To avoid such high fees and be more flexible with the auction design, the most popular auctions we’ve discussed, such as those running on intent-based DEXs and Flashbots Auctions, are held off-chain. 

But this comes at a compromise on the auction’s fairness, transparency, and accountability. A bidder could manipulate the auction’s outcome by posting false balance proofs to win the auction by bidding the highest, even when the bidder would not have sufficient funds to pay. Their goal could have either been to win the auction or disrupt it. With off-chain auctions, bidders could collude among themselves or even with the auctioneer, and there would be no way of publicly knowing or verifying. Auction participants would have to be trusted to NOT act against the best interests of the users and the protocols.

This is why an on-chain private and verifiable auction is ideal. The bidders’ and auctioneer’s identities and actions can be private and verifiable. 

Orbit & Hyperlane

API3’s OEV Network is an Optimistic rollup built using Arbitrum’s orbit framework. With Arbtrum’s 200ms block times, auctions can be conducted faster and cheaper than on the Ethereum mainnet. 

Batching could reduce the overall costs of running an auction. Liquidator bids could be batched and proven in a single transaction on the OEV Network to reduce bidding costs. This could also encourage bidders to submit their bids faster in a shorter window.

To participate in the OEV Network, searchers need to be able to bridge over to the network to place bids. As OEV Network operates as an Optimistic rollup, the 7-day withdrawal period would affect the searcher’s flexibility to withdraw the bridged funds and implement strategies. For this cause, OEV Network will rely on Hyperlane for bridging. 

Hyperlane is a cross-chain communication protocol. It facilitates the flow of any ERC20 token across L1s, rollups, and app chains. Liquidators can use Hyperlane to bridge funds required to place bids from the mainnet to the OEV Network. 

Once liquidators have placed their bids and the auctioneer has chosen the winning searcher, the Oracle price update is rewarded to the winning searcher within a meta-transaction. 

Neither L1s nor L2s inherently have an auction mechanism to capture OEV. Once an auction is conducted on the OEV Network, a searcher can use the resulting meta-transaction to update price feeds on the specific chain to perform liquidations and capture OEV. This would help capture value that would not naturally exist on these networks.

 

Attack Vectors

However, even sealed bid auctions are not free of manipulation and collusion. The same entity could deploy multiple searchers to the auction and strategically place bids to manipulate the fair value of the transaction being sold. 

Auctions can also be subject to “shilling.” This is where the seller poses as another bidder bidding at a higher price to spread misinformation and inflate the value of the sold item. This may lead to other bidders changing their strategies by canceling their current bids and reposting higher bids before the auction clears. Tim Roughgarden has covered shilling in auctions in the paper Shill-Proof Auctions.

As OEV Network relies on searchers bidding and fulfilling their operations as intended, it is not free of risks of bidders misbehaving or colluding. To prevent this, OEV Network requires that bidders have about 10% of the bid amount as collateral to place bids. Searchers can place or cancel their bids as they please, but once a bidder is chosen as a winner, their collateral gets locked. To reclaim this collateral, the winning bidder must complete the price update and their OEV transaction and post the transaction hash on the OEV Network as proof. 

Another attack vector is that a bidder can choose not to liquidate and not post the proof to OEV Network to delay the price update even after winning the auction. But why bid and win the auction if you will not liquidate and extract OEV? The motive behind such a strategy would be to delay the price update until the OEV Network auction duration concludes after 30 seconds and then wait for the Oracle price update to be released in the public mempool. At this point, the search for OEV would take place in blockspace auctions where most of the value would flow to builders and validators. Given the costs it would incur, a one-off searcher is unlikely to use this strategy repeatedly. On Ethereum’s main net, an integrated searcher builder would likely use such a strategy to extract most of the OEV for themselves instead of sharing the pie with the protocol and OEV solution. A reputation bonding mechanism could help disincentivize these actors from engaging in such malicious behaviors. Let’s dive into it below. 

OFA Governance

OFAs require active governance and protocol improvements to account for centralization/competition, attack vectors, and the general welfare of the protocol. This is evident in how intent-based DEXs such as CowSwap, which have OFAs, have passed proposals to ensure farrier competition among solvers and to set up disciplinary measures if solvers misbehave. See proposal CIP 13 to learn more. 

Similarly, API3 plans to implement a reputation system designed to incentivize timely liquidations by liquidators on the OEV Network. When liquidators fail to liquidate within the specified timeframe, they face penalties in the form of slashing and a negative reputation score. On the other hand, liquidators who consistently provide timely proofs earn a positive reputation score. This reputation score directly influences the collateral requirements for liquidators. A positive score reduces collateral requirements, while a negative score increases them. Reputation bonding mechanisms aren’t necessarily foolproof. A bidder may still act maliciously If they stand to profit magnitudes higher than what it would cost them (punishment) to do so.  

 

UMA’s Oval

Oval, too, runs an OFA. Oval’s setup includes three main actors: an oracle, an auctioneer, and an auction platform. Chainlink acts as an oracle, Oval acts as an auctioneer, and MEV-share acts as a platform that helps facilitate the flow of value as determined by the conclusion of the auction process. 

Oval relies on Chainlink as an Oracle for price updates. Whenever there is a meaningful price change, data coming off of Chainlink is wrapped and auctioned off to searchers. The winning searchers get the right to back-run Chainlink’s Oracle update transaction with their MEV bundle. 

MEV-share is an OFA designed by Flashbots in which searchers bid for users’ transactions to include in their MEV bundles. MEV Share utilizes a type of private auction mechanism in which users can conceal and reveal only some information about their transactions. 

Let’s go over how Oval works. 

1. Searchers encounter a liquidation opportunity and observe the mempool for an oracle price update transaction from Chainlink. 
2. Searchers submit their bids to Oval Node to participate in the Order Flow Auction to win the right to backrun the Oracle update. 
3. Searchers submit bundles to the Oval Node. The bundle contains their backrun transactions, which include a builder payment or a priority fee.
4. Oval Node then adds an “unlocklatestvalue” transaction at the beginning of the bundle. This added transaction makes the latest price update from Chainlink available for use. 
5. The Oval Node then forwards this bundle to MEV-share along with parameters such as refund percentage. 
6. Now, MEV-share forwards these bundles to a set of builders with refund preferences such as refund percentage and refund recipients. 
7. Builders receive these bundles in an auction during their usual block-building process and select the highest-paying bundle to include in a block. 
8. The searcher’s bundle is executed successfully, and the resulting extractable value is refunded to pre-defined recipients, such as the protocol itself.

UMA initially considered a revenue split between the integrated protocol, Oval itself, and Chainlink. This has now been revised to a 50/50 split between Oval and the integrated protocol. In a later section, we will explore the dynamics of splitting auction proceeds more fully. 

Trust

Oval’s process relies on multiple parties acting in good faith. No technical barriers stop block builders from censoring Oval transactions or unbundling searcher transactions to replace them with their OEV-capturing transactions after three blocks. A reputed block builder would avoid engaging in such strategies, or they would stand to lose order flow. As an Oracle, Chainlink can set up a similar OFA and capture OEV without sharing profits with another party like Oval. This is likely to happen sooner or later. Revenue sharing that is more favorable to Chainlink and compensates them for running price feeds could work, but it is pretty uncertain. Flashbots MEV-Share is another trusted entity that could capture the value themselves or siphon off OEV-capturing transactions to colluding searchers in exchange for a fee. MEV-Share could delay the release of the newest price update by not calling for the “unlocklatestvalue” transaction. In this case, Chainlink’s price update would become accessible to everyone in the mempool after three blocks anyway, and OEV would bleed to validators as usual.

Latency

In the worst-case scenario, Chainlink’s price update can be delayed by up to 3 blocks, i.e., 36 seconds. Post which the auction will conclude. This could be due to insufficient payments or bribes from the searcher to the builder. Given that the idea behind OFAs is to keep a larger share of the extractable value pie with the protocol and Oval, and a smaller share is paid to builders. Block builders have lower incentives to include searcher’s backrun bundles in their blocks. This could especially be a problem during high transaction congestion, coinciding with a fear-driven market condition, further worsening the issue. The longer the delays, the less efficient liquidations an integrated protocol will have. Since most searchers have less than a 10% profit margin on liquidations, incentivizing them to liquidate positions could encourage them to pay block builders enough to maintain healthy inclusion rates.

Pyth’s Express Relay

Pyth, an oracle service provider, uses its infrastructure to host auctions for each protocol using Pyth oracles. Pyth’s Express Relay hosts auctions to sell liquidation rights to liquidators. The bidder is chosen based on the bid returning a higher portion of the captured OEV to the protocol. 

Similar to MEV Share, Express Relay hosts sealed bid auctions. Bid details are not visible to other participants until the auction is concluded and OEV is extracted. However, searchers will likely be able to reverse engineer bid values based on market data as with MEV Share auctions. 

Express Relay auctions would last as long as the chain’s block time. On Ethereum, for example, they could last 12 seconds and 0.26 seconds for Arbitrum. The delay into a liquidation could be reduced with shorter auction durations, leaving users with more value to recoup. However, with shorter auction durations, searchers may have less time to extract value maximally, which could lead to lower OEV captured by the protocol.  

Express Relay and its auctions are hosted off-chain by Pyth, so protocols face relay downtime risk. Protocols would have to account for this risk by placing fallbacks: if the relay is down, the protocol should revert to liquidating using the usual methods, where block builders hold auctions. Not factoring in relay downtime could lead to delayed or missed liquidations and losses. 

Before the Express Relay, Pyth teased a Global OFA design that aggregated order flow from all protocols using Pyth oracles. This design allowed liquidators to participate in an aggregated auction. There are no official reasons for the change in design. However, implementing the Global OFA design would present major accounting challenges.

bro just kill me..😵‍💫😵‍💫 accounting builder profit onchain isnt easier than doing crypto tax

— danning.eth⚡️🤖 (@sui414) April 29, 2024

Conclusion

Protocol Design

It is not uncommon for OEV Protocols to rely on their Oracles. API3’s OEV Network uses API3’s Oracles. A potential OEV solution from Chainlink would use Chainlink’s Oracles. While this is undoubtedly a centralization vector,  it also means that the lending or OEV protocols may not have to trust a different third party. It is also optimal for an oracle to host an auction that sells the right to use its Oracle price update to searchers. This puts Oracle service providers in an excellent position to host the OFAs and control the release and use of the price update transaction. 

Alternatively, lending protocols can choose to build an in-protocol OEV solution. This way, they would not have to part with a portion of the captured OEV. While this is good, setting up and maintaining an in-protocol solution would come with OFA bootstrapping issues. Attracting searchers to perform liquidations would be challenging unless it is an extensive protocol with frequent liquidations like Aave or Compound. 

 

Auction Mechanisms

Protocols are responsible for designing and actively governing the auction. There are trade-offs between each auction design. English auctions may cause bidding wars, driving up prices too high, and sealed-bid auctions are costlier than English auctions, but this cost could be offloaded to third parties such as liquidators. Dutch auctions, as used in some lending protocols, don’t instill bidding wars but tend to last much longer, potentially delaying the price update. 

Splitting Auction Proceeds – It is essential to factor in liquidator welfare. Awarding bidders promising the highest percentage of OEV rebate may not necessarily be the best choice for user/protocol welfare. The more bidders pay as rebates, the less they generally have to bribe block builders in block space auctions, which could reduce the inclusion probabilities of that bundle in the expected block.

Using Dutch auctions for liquidations is not the best. The auctioneer would have to bear the burden of pricing oracle updates. They also take time to conclude as prices gradually decrease over a period. This is especially not suitable as positions would get increasingly undercollateralized over time. Duction Auctions turn into latency games between searchers rather than optimizing for pricing the collateral or the right-to-use price updates. 

It is also essential to factor in fallbacks for when an auction might be delayed or offline. In the case of API3, the oracle update is automatically released in the public mempool so that liquidations can proceed as usual when there is a delay or a liveness issue with the auction. Protocols using Pyth should factor in Express Relay downtimes and integrate fallbacks accordingly.

Implications On Oracle Reliant Protocols

Some OEV solutions may require protocols to switch over to a particular oracle provider, but switching oracles may not be as straightforward. Several security considerations come into the picture. Each lending market would have its optimizations concerning how an oracle sustains it. Some lending protocols rely on multiple oracles, making potential integrations even more complex. 

Timely liquidations are a foundational part of how a lending protocol works. If OEV solutions fail to deliver timely liquidations, lending protocols could accrue hundreds of millions in bad debt in volatile market conditions. There are potential attack vectors from integrated searcher builders who could delay price updates. In such cases, OEV Network nullifies the previous price update awarded to the malicious searcher after 30 seconds. It sends a newer price update as a backup to soothe this issue potentially.  

OEV solutions should be carefully piloted across smaller markets before attempting any protocol-wide integrations. A well-designed and competitive OEV solution could help capture OEV, distribute it to users, and maintain protocol welfare. However, arguments have been made that a lending protocol itself could host an in-house auction or use other mechanisms to capture OEV without sharing the revenue with a third party.