MEV and the Limits of L2 Scaling | Daniel Marzec - Flashbots

Hey everybody, welcome back. Uh for all you scaling heads out there, we've got uh Demars and he's going to be talking about Mev and the limits of scaling.

Awesome. Thanks so much for the intro. I can't see anyone. Um who here knows what ME is? Can you raise your hand?

Okay, a bunch of people. If I say the word back running, do you know what what that is? Yeah. Okay. Okay.

A couple of people. That's some helpful calibration. Cool. So, let's get into it. Yeah.

I'm Demars at Flashbots. I do uh a lot of our protocol related work. Um and let's get into it. So, MEV and the limits of scaling. We posted some research a couple of months ago about a new thesis we had which is that MEV has become one of the dominant limits to scaling blockchains.

Uh and so we're going to get into that. the um the like the key takeaway here is that um there is a lot of onchain searching. This is a new paradigm in high throughput chains where gas is very cheap and they consume a lot of the chain's capacity and it is very inefficient. So we'll get into it. Um the problem at a glance spam bots consume more than 50% of gas and pay less than 10% of fees on certain L2s.

uh base added 11 million gas per second throughput between uh November 2024 and February 25th and almost all of it was consumed by spam. So you can see how this thesis makes sense now. The more we scale the chain, the more spam shows up. Um cool. And then another like add-on thing is that two searchers were responsible for 80% of that spam.

So there's a lot of opportunity if uh there's any searchers in the crowd. Cool. Um, so we're going to go through the anatomy of a spam transaction first. Uh, this may be hard to see. Uh, it's definitely hard to see.

Uh, but this is an Ether Scan um, quote unquote successful arbitrage. Uh, and if you look closely at it, uh, there is a, uh, 12cent profit and it pays 2% in fees. Uh, sorry, 2 cents in fees. So, you might think, ah, that's that's efficient. Okay, they extracted 12 cents and they only paid 2 cents of computation.

Um, but the true cost when you look under the hood, this specific searcher tried this arbitrage 350 times. Uh, so that was uh that's that's roughly 130 million gas per successful ARB if you uh take this to the extreme. And that is four full Ethereum blocks of gas for 12 cent arbitrage. Um, and how we actually find these is we look at these failed attempts. Uh we saw a successful example and this is a failed example.

It looks like a regular transaction if you look at it. There's none of the fun like fancy insights that Etherscan uh adds to it. Um but so you can see there's no token transfers. Um and it's just a successful execution, but it uses 2.6 million gas and it does nothing suspicious.

Um this is probably also not readable but these uh are some of the the logs from the transaction and you can see that we are this this transaction is constantly querying uh pool state. So it is essentially just checking a bunch of pools on chain and doing some type of computation to see if there's an arbitrage between different pools. Um and so this really is is the like spam bot loop. You send a transaction, it lands on chain. What is happening is it goes and checks 50 pools.

It checks if there is some type of uh arbitrage between two different pools. Uh if it does, it executes it. So it will actually swap the assets on one, sell them on another. Uh if not, it does nothing. So basically, we're using a large amount of gas just to read prices and do nothing.

Uh by we I mean these searchers. Um yeah and and so this is like the core insight. Um on L1 we didn't see this type of activity because gas was so expensive and block times were so large. So a block comes in uh you've got another 12 seconds before the next block. You can download that block.

You can check all of the pools on chain. You can see ah there's an arbitrage for 50 bucks. And then now you can go to your friendly block builder and pay them which is passed on to the validator 49 bucks to try and execute this arbitrage. But because L2s are so fast and so cheap, um you it's it's in a completely different paradigm. So the one example was uh you know two seconds uh two cents to execute, but often we see 1 cent per execution and we even see like $10,000 arbitragees people are finding.

So you can see how this quickly gets very out of hand. On top of that, the more L2s become used, the more arbitragees that are available. Um so the root causes of spam. Um I mentioned some of them. So like transaction expressivity.

Um so onchain programs with conditional logic not static orders. Um so they are actually like doing this searching on chain and looking for things. Private mem pools are another example. They are good. They stop like sandwiching and front running.

But the fact that you can't see any of this like signal, it's all private. You need to wait till it's onchain and then that forces you to spam. you're optimistically assuming I'm going to do a you know some user is going to swap on chain and it cost you one cent to just hope that you're going to land behind that person on chain and extract some arbit uh arbitrage uh and then yeah cheap fees and then no efficient auctions. So that's like the key point of this is that uh people are just yeeting thousands of transactions on chain just hoping to land behind every single person on chain uh to check if there's an arbitrage. So I'll go through some findings from the OP stack uh from OP stack roll-ups.

So the spam is systemic. Um maybe I can zoom in. Okay, hopefully that's better. Uh so when we did this analysis which I believe this was from this went up to June 2025. We've got some new updated numbers but you can see that the share of gas used by spam bots is insane.

On uni chain alone they were accounting for over 60% of the gas uh were these spam bots. Uh you can see on base we were also close to 40% and optimism and then world was also close to 20%. Um yeah, so spam underpays massively. Um so the key stat here is oops uh on OP mainet for example 50 so spam used 57% of the gas but they only paid 9% of the fees which is kind of insane. Um resource usages on base for example is another one.

So um yeah, you can see that non- spam accounted for about 44% of um the gas used and uh actual spam accounted for 56%. And then the other really interesting insight is that L2s also pay DA costs to the L1. So the non-spam accounted for 74% of the DA, but the actual spam accounted for 26% of DA. Um, and there's also some more analysis on the fees paid which I mentioned. Um, so yeah, we've got some more in interest of time.

I won't go I won't go too deep into this one, but um we can see that uh as the gas uh per second increased uh or like the effective throughput uh the amount of spam also uh the the amount of onchain searching also increased. Um, some more graphs. I will skip through this, but if you're interested, let me know. Um, some more analysis we did as well is looking into uh who is actually doing the spam. Um, it's there's there's no way to actually attribute um the specific bots across different addresses.

So, um you know, a lot of searchers will uh have multiple different types of arbitrage strategies and they will split those across different addresses. Sometimes they're uh very fun and they leave a little mark in their address. They like to do little uh you know um they like to you know mine for different addresses so they have a little signature. Uh but often times they're not that nice. So top spam gas users by smart contracts.

We see that this 0xbf69 accounted for about 23.9% in this block period. And then we have a whole host of ranges of other people doing uh between two to two to 5%. Um and then by profit taking addresses it is also very interesting uh as we have this uh quite uh you know uh triopoly of uh people um that are actually taking profit. And so yeah this this is ultimately the efficiency gap we see.

It is 200 uhk gas for a two swap arb. Um but uh you know it's 130 million gas in practice on base and this is uh 650x um uh gap to close. Uh so how do we move forward? Um two pillars that we believe are the path forward here. Uh programmable privacy and uh explicit bidding.

So as I mentioned, part of the problem here is that uh all of these transactions are private until they land on chain. On Ethereum L1, there are mechanisms to expose parts of these transactions to searchers and let them compete uh to um backrun these transactions. Uh backrunning is just trying to insert yourself behind the user transaction. Um so we typically call these like orderflow auctions and there's a variety of variants on the layer one. Um there are some on layer 2s uh but because the mem poolool is private by default they are like a little bit less efficient.

And so what we believe the answer to this is like actually giving some type of real-time access to TX flow to searchers while programmatically restricting what they can do. So the the holy grail of this would be hey I can give uh you know searcher a access to some user's transaction data uh as long as I could be sure that they are not going to take advantage of it. Um and then the other pillar of this is that like we do want to create an actual auction. So what do I mean by actual auction? Well today as I mentioned people just send a thousand transactions and they're just competing against every other transaction to land on chain.

And what we want to do is say like, hey, here's a users transaction that creates MEV. All of you searchers bid to be behind this, not bid behind every other transaction. This allows us to create an efficient auction. An efficient auction should in theory uh you know bid most of the value of the arbitrage back to the user or the uh chain or however it wants to be distributed. Um so we think as um taking a step back uh I I mentioned this fancy primitive like how could we actually give a searcher a transaction a user sensitive transaction data and and convince them to not leak that data.

Well we think uh you know we we really shouldn't scale this based on trust and cont like uh legal contracts. That's not what blockchains are for. Uh so we believe strongly in trusted execution environments. These are a specific type of hardware that uh uh produces something called an attestation and this is some type of like commitment from the hardware about what software it's running. From here we run a IO restricted sandbox on these trusted execution environments.

So this is a fancy way of saying we can control what goes in and out of the TE and um as well it enables uh searchers to deploy proprietary searching logic to it in a way that we can't see uh but we can still give them access to this sensitive data. This allows us to safely share sensitive user data without risk of uh the user getting um you know sandwiched or these types of things. Um, another thing that we're building on top of this is a primitive we'll be rolling out pretty soon. Uh, it's actually a family of protocols called signal boost. And, uh, as as you can probably guess, uh, part of this problem is these private mess don't share any of their signal.

So, we want to create a variety of primitives that allow different types of order flows to share uh, signal with these searchers to allow efficient execution and reattribution of the value back to the user and the chain. Um, yeah. Yeah. So there's some early results that we find uh searchers inside of TE's are uh these are very early by the way. So we'll actually post some stuff here uh pretty soon.

But we are finding that when we give searchers inside of TE's full access to the transaction data, they are able to more efficiently extract value than uh in the case where they're just blind searching. So yeah, uh that's the presentation. Um, we think that solving these types of problems uh will be fundamentally uh a fundamental requirement to all chains that want to scale their throughput. No matter if you're an L1 or an L2, you will need to encounter this. And we think the adoption of ME auctions is not a luxury but a requirement.

Uh, cool. That is it. Thanks.