Inclusion Rates
Understanding Oval's MEV-Share inclusion rates and associated delays to consumer applications.
Last updated
Understanding Oval's MEV-Share inclusion rates and associated delays to consumer applications.
Last updated
Oval runs its OEV auctions using MEV-Share. With MEV-Share it is possible for a short inclusion delay to be introduced to oracle updates due to the probabilistic nature of proposer-builder separation (PBS) on Ethereum. If an inclusion delay occurs that exceeds lockWindow, the price will be automatically released in order to protect the health of the integrating protocol.
Inclusion rates have two components to think about: 1) how many blocks a searcher must wait until a connected builder has a chance to produce a block and 2) how much to pay to be competitively and consistently included, assuming connection with a builder for a given block. Each of these components are broken down below.
Currently, MEV-Share has all the main builders enabled. At present, ~90% of all validators run MEV-Boost, therefore ~90% of validators (proposers) are connected to a builder that supports MEV-Share. Assuming a competitive bid is placed that warrants inclusion, each Oval update & searcher backrun bundle has a 90% chance of being included within the same block as the oracle price update.
Given this, the chance that a transaction is not included after 3 blocks is 0.1%, assuming a sufficient block payment (). This informs how high the lockWindow value should be set, as this bounds how much time can be spent delaying an Oval update for inclusion (either due to block inclusion time or auction initialization time) while waiting for an appropriate builder to produce a block.
Under EIP1559 block inclusion, when sufficient builder payment is made, inclusion is likely to occur in the same block as submission. When the chain is under high congestion it is important to pay the builder a sufficient amount to incentivize fast inclusion. For example, if there is a lot of onchain activity and crypto prices are moving dramatically it is possible to have to wait a few blocks for inclusion if a transaction is not appropriately priced.
These kinds of inclusion delays can impact the time that it takes for an Oval update to land onchain. The burden for fast inclusion & sufficient builder payment remains on the searcher: this is the same dynamic that exists before Oval. It is in the searchers best interests to make sure that their liquidation bundles land on-chain quickly and with minimal delay to be competitive in executing liquidation vs other searchers. In this regard, Oval adds no additional delays to updates, assuming sufficiently profitable liquidations, vs the pre-oval landscape.
Oval functions by taking a part of the builder payment and re-allocating it to the integration. The profit a searcher makes is unaffected. For example, if the overall Oval take rate (see Revenue Sharing) is set to 90% then the builder is being paid 10% of the total searcher payment.
Because of this, using Oval means the searcher pays less for the right to use block space due to a lower builder payment. Under times of extreme network congestion this might be sufficient to impact inclusion rates. A transaction might have to wait a few blocks for its builder payment to be sufficient to have inclusion. The impact of this change is a function of how high the demand for block space is and how much a searcher is willing to pay for inclusion, vs other demand for the same blockspace.
An important thing to note is that the impact of Oval on the decreased builder payment is felt equally by all searchers.