Mastering DeFi Trading, Block Building, and MEV

By: Eyal Markovich, Co-founder & COO

I presented at ETH Denver 2023 and shared several slides with some interesting stats on latency in the MEV-Boost ecosystem. I received several requests to share the stats from my presentation, so here they are.

GetHeader (get_header)

GetHeader is the endpoint request a validator performs to get the block bid (block value) from the MEV relay. Below is a plot based on 1800 blocks where the bloXroute relay won. For each block, we analyzed the time when each validator asked for the get_header relative to the slot start time. We found that, on average, validators are asking for a bid 400ms. after the slot start time. For each slot, a relay will serve hundreds of get_header requests. So, for the plot below, we matched the get_header request from the same IP that performed the validator registration request. Interestingly, we see that there are several slots with HUGE delays in the timing of the get_header request.

Here’s a histogram that summarizes the stats in the plot above. Most get_header requests happen around 300–500 ms. post the slot start time.

Times blocks are ready at the relay

Next, we look at the time blocks are available at the relay relative to the block slot time. In order for the relay to deliver a block in the get_header request, the block must be available prior to the get_header. So when are winning blocks received? We looked at the time a winning relay received the winning block and reported it in the builder_blocks_received endpoint. Averaging over 800 winning blocks, we see that, on average, blocks were ready 149 ms prior to the slot time; yet, the median is only 73 ms. So there is a large variance where some blocks were ready more than 2 seconds before and after the slot time.

And again, a histogram shows that most blocks are ready between 200 ms before or after the slot start time.

We looked at 1000 blocks that were sent to at least 2 different MEV relays and compared the time they were available in each relay. On average, it takes the second relay an additional 99 ms for the block to be available, another 122 ms between the second and the third relay (for block sent to 3 relays or more), and another 342 ms for the the block to be available on the fourth relay (for blocks sent to 4 relays or more).

I’m hoping that someone will repeat the analysis above now that we see more optimistic relays, as I’m sure this has improved since then.

Bundles’ submission time

Next, let’s look at when do searchers submit their bundles to block builders. We looked at the time successful bundles (landed on chain) were sent. As expected, we see submissions throughout the entire 12 sec slot time. However, the distribution is bi-modal: many were submitted early on, but more were submitted close to the end. One explanation for the first peak is an increase in bundle submission after receiving the previous block. A possible explanation for the second peak is that searchers on some strategies (e.g., CeFi-DeFi) wait until the last minute. Bundles in the rest of the slot time may be a result of strategies where time is less of a concern (mempool sandwich attack).

More research is welcome here!

RPC Inclusion rate

RPC inclusion rate is an important metric for retail traders who send private order flow to avoid front-running and can send their transactions only to a single RPC (think Metamask custom RPC). We designed a test where we sent 20 transactions to several RPCs and measured how long it took each transaction to be included in a block. We sent each transaction in the middle of the slot, leaving enough time for the builder to package it.

As the plot below shows, it might take some of the RPCs several blocks to include the transaction since it depends on when the particular RPC builder wins the next block.

bloXroute RPC showed better results because it sent the transaction to many builders.