We want to design a system where oracle updates from existing oracle solutions, such as Chainlink, can be run through an MEV-share auction enabling the extraction of Oracle Extractable Value (OEV) by protocols that use the oracle update (and produced the value). Functionally, this would look something like the diagram below wherein a price is pulled from an existing oracle solution and an MEV-share auction is inserted between the oracle update and an output oracle contract that represents an equivalent interface as the input oracle.


Additional functionality can be added to the OEV Oracle block, such as Optimistic verification using the UMA system, aggregation of other oracle types or requirement for some additional verification to overlay the input oracle type. Note also that this pattern is agnostic to the input oracle; Chainlink can be swapped out to a different oracle.

This design enables the re-direction of value in the oracle update from standard MEV auctions to the protocol that used the price and inherently created the MEV. For example, Compound could receive some percentage kickback from the oracle update that produced liquidations within Compound. Put differently, this modifies part of the MEV supply chain through the re-allocation of revenue that would normally be sent to validators further up the president chain to the protocol that produced the MEV in the first place.

There is one primary problem with current MEV-share implementation that prevents this solution from working: There is no way on-chain to know that a transaction came from MEV-share. This is required to ensure that the initial update flows through the mev-share auction before getting to the OEV oracle contract. This is also required to create a failsafe against MEV-share breaking by enabling prices to be automatically pulled directly from the incoming Chainlink contract if there has been a delay for some fixed number of blocks without an MEV-share update. To do this, however, it is required to know that an update came from MEV-share (or not, as the case may be).

Additionally, it would be required to verify on-chain that both the refund address and refund percentage are set correctly. In particular, MEV-share chooses the winner of the auction based on the transaction that pays the maximum to a given slot’s validator. However, the above mechanism should ideally choose the winner of the auction based on the transaction that pays the maximum to the protocol that used the oracle update (such as Compound). To achieve this we would require to verify that the refund percentage set within the MEV-share transaction is set to some fixed value, such as all bids are set to 95%. Secondly, we need to verify that the refund address is set correctly. This could be set directly to the protocol in question or to a pool that then further distributes the funds.

**Effectively we are asking for some ability to read the refund address and refund percentage associated with a MEV-share transaction on-chain.** The implementation of how to achieve this is not totally clear at this point. One option could be to have an optional type of MEV-share transaction wherein part of the matchmaker duties is including some information associated with the bids within the bundle that is sent to the flashbots auction. All reverting/non-winning MEV-share transactions will be dropped, as per usual. Winning transactions will operate as per usual and include additional on-chain information associated with the bid, such as the refund address and refund percentage. This implementation could see some kind of registry contract that maps backrun transactions to the associated refund address and refind percentage for a given MEV-share transaction. An alternative mechanism could see the matchmaker providing the searcher with a signature associated with their bid which is then included as part of their back run transaction submition to prove to an on-chain contract that the matchmaker saw the refund address and percentage associated with that backrun transaction.

This modification would also open up the space for a number of other use cases to be built on top of MEV-share as a generic marketplace for protocols to capture the MEV they produce. For example, NFT mints could send the initial NFT minting action via a similar contract setup to construct a system wherein the NFT minter captures the majority of the value associated with the initial drop. This would entail having the NFT mint contract restrict itself to only receiving mint transactions that: a) came from a predefined address(i.e only the project address could initiate the drop, same as current status quo) and b) met some specific conditions on the MEV-share auction properties, such as setting the refund address to the NFT DAO and having the refund percentage set to some desired percentage, like 90%. Through this mechanism the NFT launch could operate as per usual, without needing to do anything funny to hide from MEV-seeking on-chain actors, while restricting the backrun calls to only actors who meet the criteria of setting the refund address and percentage to something that the NFT DAO dictated. In doing so the initial MEV launch transaction will be able to capture the vast majority of revenue associated with that on-chain update, in a way that before now was not possible at all.