Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data

I Did already Friday morning quite a few people make it to the MEV stage seems like they're quite some MEV ultras Looking forward to it. I'll be doing quick intro on multi block MEV just quick lightning talk to dive right in. Quick recap, what is multi-block MEV? Actually, multi-block MEV means one block builder has multiple slots in a row and can extract more MEV by having the slots in a sequence than by having individual slots. This arises due to the fact that MEV accrues Exponentially if we look at the data we can see that over time it slightly exponentially grows for example one strategy could be to Manipulate prices a block builder can for example buy a certain token in slot one, then only include buy transactions on one side and not include the sell transactions, and then in his last slot capture the MEV of selling the token first.

This is one potential strategy of manipulating the price. There are other ways to do it. We can do liquidation attacks of also forcing the price to go below a certain threshold and thereby liquidating assets and capturing the liquidation gains. So I won't go too deep into it, but a whole set of strategies. What did we do?

We looked at data since the merge, 4.3 million data points of MEV boost payments, and did, on the other side, a Monte Carlo simulation of daily market shares of builders to see what would be like a statistically normal distribution of multi-slots to have a baseline. And based on this, what we saw is, interestingly, we have less multi-slots to have a baseline and based on this what we saw is interestingly we have less multi-slot sequences than expected. We see especially on the chart on the right we see the blue bars being the expected distribution of multi-slots. We see less of them also interestingly what we saw, however, longest sequence was 25 slots in a row by the same builder, Beaver Build.

And for the same validator and same builder, it was 11 slots in a row March of this year. So what we see just by statistics, there are long sequences, which would allow for multi-slot MEV strategies. So in the next step, what we looked at was the payments, are long sequences which would allow for multi-slot MEV strategies. So in the next step what we looked at was the payments, the MEV boost payments for longer sequences. So this is basically for a sequence of length 5 for example, what was the average payment.

What we see interestingly it increases for longer. So it seems to be there is a value in longer sequences. However, why this is the case, so far we can only speculate. One hypothesis could be that MefBoost, it's a continuous first price auction, so it basically, from an economics perspective, works like a second price auction from the value where we end and so it could be actually driven not by the highest bidder but by the second highest bidder who has an increasing value for the blocks based on private order flow, MEV captured in private order flow so it could be the case that actually the intrinsic value of the second highest bidder increases and that drives these increasing values. So what we also did is looked for the payments per slot.

So in longer sequences, what was the bid for the slot at a specific point there? We saw so far there is an increase but only a very very slight increase so this led us to the conclusion that so far we don't see dedicated multi-slot strategies. We also looked at the top 10 builders to see if there's a certain pattern for the top 10 builders if there's there are builders that are deviating from the mean. We didn't see any very outstanding data. In the case of few builders that have more slots, more multi-slot sequences, or that are particularly strongly correlating with the same validators.

However, from our perspective, that's probably based on things like latency and co-location and not based on other types of strategies that are run. Last thing that we looked at was autocorrelation of math boost payments to see if we can use historical math boost payments to predict future ones. There what we see is based on different correlation metrics that it strongly goes down after the second or third slot so it means there's a very very low auto correlation so a low predictability so we don't have times of high or low MEV but there's a fast reversion to the mean overall. Yes, there was the quick run-through. If the topic in general is interesting, there's a post on ETH Research.

I'm going into the details, also linked to the Jupyter notebook with all the data, and I'm also doing a workshop today in the afternoon on execution tickets, agent-based simulation of execution tickets, so whoever is interested, feel free to join. Otherwise, happy to take on questions. I think I have around one and a half minutes or one minute left for questions. Feel free to scan the QR code or ask them directly. So we already have two questions.

We want more. You can just scan the QR code and put it. And one quick question, Pascal. Where is your talk so that the audience is aware of the room that the talk is in? The talk is in classroom B, so just down the aisle.

So I'll read out the question for those who are joining virtually. Have you studied Arbitrum Time Boost? Do you think DAO should be capturing MEV revenue? To be honest, I haven't looked deeply into Arbitrum Time Boost. I think there are people in the audience that have much more knowledge of this, so I can't really give their in-depth take.

Unlike Proposer, Builder is not guaranteed to win PBS auction multiple times in a row. Would you advocate for a random Proposer allocation, which does not allow the same Proposer in a row? In general, I think it makes sense. However, I think there is. So, I mean, that's a bit of an outlook already on the simulation.

What we saw is that the secondary market usually reduces decentralization, which means there should be some component of just-in-time auction. However, I think with the current MF boost setup, what we have is the problem of in-flight variation. So I think a combination of both could be interesting. But I think some component of randomization does make sense to prevent multi-slot MEV strategies. Thank you so much.

That was a great talk and a good start to the day. To MEV Day, I like the name that you gave. This is MEV Room, you know? Thank you. Thank you.

So we have our next talk coming up really quick with Felix Leupold. The talk is on do we really even need PBS and how we can solve MEV at the app versus infrastructure layer. This is going to be a full day of hardcore research, so really glad to see all of you here and engaging and asking questions. Make sure to scan the QR code if you have any questions for our speaker. And with no further ado, let's welcome Felix on stage.

Hi, I will have to speed run this talk. so if you want a more relaxed version of it, you can scan the QR code or go to tinyurl.com slash DAPCon, where I gave this talk in a 25-minute version. Let's start with the problem that I have with proposer-builder separation, why I think it's not a good idea. There are three main arguments in my point of view.

First, the trust and centralization problems that it brings onto the Ethereum base layer for all types of transactions, not even the ones that actually contain MEV. Ethereum today is proud to have more than one million validators proposing and validating the chain, and we are one of the most decentralized chains, or the most decentralized chains in the world. But at the end of the day, if you look at it, there's only two very well-known entities, Beaver and Titan, that propose more than 90% of the block's contents. And how valuable is it really to have a vast validator network when the most important part, the content of the block, is decided by two entities. Moreover, PBS adds this trusted component to the supply chain, the MEV relay that builders have to put their faith in.

And even if we trust the research that's ongoing, that's trying to propose ways to enshrine the MEV relay into the base layer and get rid of that trusted component, I think there's a couple of issues with that. First, it adds complexity to the core protocol, one thing that we're trying to avoid. And second of all, it's not even clear that if implemented, it will find adoption because MEV is a very latency-intense game, and any decentralized peer-to-peer gossip-based solution is always going to have latency disadvantages and also feature disparity. Builders today want to have bid cancellation as an example. They want to make a bid and then cancel it if they change their mind.

And such a feature is simply not possible in an enshrined PBS version because once you gossip the message, you cannot take it back. And let's not forget that PBS actually maximizes the harm that is inflicted on users. In order to win the PBS auction, you have to create the block that is extracting the most value via sandwiching or other types of MEV attack, and thus we've created a system that really favors the worst possible outcome for the user. Okay, enough of a rant. What do we do about it?

First, let's maybe take a step back and try to find out why does MEV exist in the first place. And here, really, the fundamental reason is that in today's system, every token trades at many different prices within the same block. Here I brought you an example block from a couple of days ago in which ETHUSD trades at least seven different times with seven different prices. And so you'll see 6-6 arbitrageurs that are able to access, for instance, the Uniswap pool at the previous block's outdated price. And then the rest of the block will trade at the new kind of fair equilibrium price.

You will see liquidators that are able to get bad collateral at a fixed liquidation penalty, 15-20% below fair market price, and the rest of the block trading at a different price. And last but not least, you have sandwichers that frontrun a user to buy a token at price A, the user then priced it at price B, and the sandwicher sells it at price C. All of these strategies have one thing in common. The same asset trades in the same block at different prices. And the reason for this is that we basically took our very well best known standard first come first served mechanisms that work in traditional continuous time markets and deployed them on blockchain.

And this was the key mistake. Ethereum doesn't have continuous time. There's only new information being released every 12 seconds, and then it's released in one go. And the ordering of the information within the block is up to a unilateral party, the proposer, to decide how to order things there. And so it's unsafe to deploy any kind of mechanism that works on continuous time on a discrete time blockchain.

So what's next? How can we do to fix this? Well, as you might guess, we need to come to a point where trading the same asset in the same block should lead to the same execution regardless of trade ordering. Or put differently, we need to get to one price per token per block. This design requires to be able to batch trades together so it doesn't work on raw Ethereum transactions.

Instead, we need trade intents or just signed limit orders and batch those together in a multidimensional auction which can later be cleared at a single price. For details on how this looks, I encourage you to look at Cow Protocol, the trading mechanism that powers CowSwap, which pioneered and implements this mechanism. It's processing many billions of dollars in transaction volume every month and is basically proof that this mechanism can work on-chain. Cow Protocol provides MEV protection for all the cases that I mentioned on two slides ago. We protect swappers by having buyers and sellers that trade the same asset receive the same price regardless of their ordering.

And we can even match them together in what is known as coincidence of wants. By making AMMs part of the batch and treating them like swappers, LPs no longer trade at outdated prices, but instead get the fair new equilibrium clearing price. And liquidations are just stop-loss orders, which you can also add to the total liquidity pool and make sure that collateral recovery happens at the most efficient and fair price. I want to leave you with this number, which is a DUNE query that you can check for yourself that shows that more than 97% of MEV today is trading-related, and that is sandwiches, sex-sex arbitrage, backrunning, liquidations. And those can be vastly reduced, if not completely eliminated at the application layer by not using pseudo-continuous time mechanisms.

So I'd like you to join me on my mission to convince this space that we should fix the mechanism rather than making the chain more complex. And with that, thank you very much. Thanks for that great talk. If any of you have questions, you need to scan the QR code and ask the questions remotely. I'm going to read out the question for those joining virtually.

Do you have an estimation of reduction in MEV if only DEX used is cow? Yeah, so right now, CowSwap focuses on swap MEV protection. I didn't break the number 97% into swap AMM resistance and liquidations. So right now, it would probably be less than 97%. But the mechanism itself, not the product as it exists today, but the mechanism itself would be able to reduce MEV by that number that I showed.

The other question is, do you think PBS causes centralization or is it correlation? I think PBS causes centralization mainly because it's a winner-takes-all latency game. I wouldn't say it's correlation. There's also a reason I couldn't get to that slide because I didn't have enough time for why I think cow protocol or an application specific, um, auction is not going to cause the same centralization or even if it would not affect kind of all types of transactions. So if I want to make a transfer, I'm not kind of subject to the censoring that happens today in the, in the builder market.

Um, but yeah, for this, I would refer to the longer talk. How would you compare cow with what Sorella is doing to fix MEV on the application layer via Uniswap hooks? Yeah, I mean, cow is working out there and live. I think the mechanism is relatively similar. And yeah, I think that's the gist of it.

You can deal with the last question. How does cow deal with multi-block MEV? It doesn't, because basically the batch itself has its own kind of heartbeat, its own time. And so if you were to try to do multi-batch MEV, I think you're running the risk that whoever solver will win the batch is going to execute the trade before you. So there's no real incentive for you to...