Latency Races In PBS

Overview

Sensitivity to latency from searchers can have a centralising effect. Currently, latency-sensitive searchers have an incentive to submit traders via integrated builders partly because sending transactions to other builders incurs a latency cost, creating a centralising force on the builder market. Additionally, searchers may prefer landing transactions only via builders which are located in desirable positions, leading to geographical centralisation. What changes to PBS (or similar interface) can be implemented to reduce this effect?

Why Latency Sensitivity

The overarching answer is that there is more information available if you submit at a later date. More concrete examples:

  • Statistical arbitrageurs shorten window of uncertainty (between trade submission and knowing the outcome in order to reposition on other domains)
  • CEX-DEX trades facing adverse selection from lower-latency bidders. (e.g. if my competitor always bids later than me, they bid higher than me when the price moves favourably and let me win when the price doesn’t)
  • Opportunities which show up late. For example, a transaction which causes a liquidation or arbitrage opportunity may show up very close to the block-submission deadline
  • Last look bidding: low-latency bidders have the opportunity to react to other public bids, making the last move before the block is chosen.

Ideas & Initial Directions

  • One idea that Flashbots has been toying with is providing fresh oracle information in key infrastructure (“MEV-time oracles”). For example, a builder could offer a price feed for binance price data and searchers would submit bundles which are conditioned on this price feed. This idea requires some expansion:

    • It is unlikely that all of the proprietary data that a trading firm relies on will be provided by infrastructure providers like builders (e.g. stock price movements), but the more data that is provided the less of an impact latency differences should have
    • This idea likely works best when oracles are provided as late in the supply chain as possible (at the proposer), because there may still be latency differences otherwise (e.g. between builders because they have different physical locations)
    • Incentive compatibility of providing up-to-date price information may be difficult to achieve. Some initial directions involve TEEs and TLS certificates. Finding an incentive compatible way to guarantee this is an open question.
  • Private bidding (Cryptography, Incentives)

Guiding Questions

  • What impact would a successful implementation of MEV-time oracles have?
  • Can incentive compatibility be achieved for providing up-to-date information at key infrastructure points (builder, proposer)?
  • What protocol<>MEV-market interface reduces the centralising impact of latency racing the most?

Relevant links

1 Like