Oval Update Lifecycle

Walkthrough of a sample Oval auction & update lifecycle.

It is illustrative to walkthrough a sample transaction lifecycle that showcases all actors operating together and data moving through the system.

Consider a price update that catalyzes a liquidation within Aave. The liquidation the flow would be:

1. $t_1$: Source oracle update pushed on-chain An update is pushed onchain (example transmit call). This transaction can be seen by a searcher once it enters the mempool, at which point they can start bidding ($t_2$) before mainnet inclusion.
2. $t_2$: Searchers bid to backrun the update to liquidate the position

   Searchers wanting to use the new price value to execute a liquidation submit bids to the Oval node RPC endpoint (see Oval Node). Before Oval, they would submit directly to the builders, and from the searcher perspective, this is the only thing that has changed. These bundles contain the standard data: [chainlinkUpdateTx, ...searcherBundle] with the eth_sendBundle RPC method, including a builder payment (transfer to block.coinbase or an included priority fee).

3. $t_3$: Oval node submits bundle with unlockTx & searcher bundle to MEV-Share

   The Oval node receives the eth_sendBundlepayload and prepends an unlockLatestValue transaction (see #permissioned-actors-to-initiate-the-auction) to the searcher's bundle. The Oval node forwards this modified bundle of the form [unlockLatestValueTx, searcherBundle] to MEV-share using mev_sendBundle RPC method. This includes the associated protocol (Aave) refund parameters, like refund percentage and target (see Oval Node). The oval RPC will send every bundle to the MEV-Share node. It does no filtering or ordering.
4. $t_4$: MEV-Share releases bundles & refund config to block builder

   Now that MEV-Share has received a modified searcher bundle from the Oval RPC at $t_3$, the MEV-Share node forwards this bundle to the set of defined builders using the eth_sendBundle RPC method (see Titan's eth_sendBundle method). The MEV-Share node will include the refund preferences (refundPercent, refundRecipient & refundIndex see here) in this payload.
5. $t_5$: Builder runs auction during the block building process, selecting the highest paying bid

   After receiving all bundles from MEV-Share, the builder runs their standard block building process: packing the highest-paying (typically non-reverting) bundles and transactions to include in their bundle. Because competing bundles are typically mutually exclusive, the lower bids will be dropped, with only the highest bid being included in the final block.

6. $t_6$: Builder gives block to proposer, who appends it to the chain. Update unlocks, winning bundle executed

   After the builder auction has concluded, the completed block is given to the proposer (validator who is randomly selected to propose the block). This block contains the winning bundle, which contains: 1) the unlockLatestValue transaction, 2) (maybe) the oracle update, and 3) the searcher's backrun. It also includes the repayment transaction(s) from the builder to the associated protocol's (Aave, for instance collection address). Because the builder selects the bundle that pays the most, this bundle is the searcher whose bundle included the highest builder payment at $t_2$.

Note: In the happy path, the oracle update and the finalization of the searchers backrun bundle ($t_1\rightarrow t_6$) happen within one block. In this way, the use of Oval adds no delay to price updates that generate OEV. Oval only adds payment transactions from the builder to the protocol. The protocol is able to set a maximum delay that it will have to wait for a price update to be passed through. Setting this value too low, however, increases the likelihood of OEV leaking back to the builder. See Controlling when to release what price.