Season 4 | Episode 4
In this episode of Bell Curve, we are joined by Jon Charbonneau and Robert Miller to discuss how Ethereum's modular roadmap impacts the future of MEV. We explore L2 MEV design, decentralized sequencer models, cross-domain MEV, latency games, and Suave. Jon and Robert are two giga brains that understand the bleeding edge of modular MEV design!
- -
Timestamps:
00:55 Intro: Pre-Interview
02:39 How Ethereum’s Modular Roadmap Impacts MEV
08:18 The Rollup Revolution: Consensus and Latency Games
18:35 How Sequencers Work Today
23:43 L2 MEV Models: Optimism and Arbitrum
29:42 Why L2s Need PBS
32:21 Decentralized Sequencer Designs
44:45 Cross-Domain MEV and Atomicity
53:46 Suave: The Mechanics, Order Flow Auctions & Roadmap
57:07 “Rook Ad”
59:09 Suave: The Mechanics, Order Flow Auctions & Roadmap
1:27:50 Recap: Post-Interview
- -
Follow Jon: https://twitter.com/jon_charb
Follow Robert: https://twitter.com/bertcmiller
Follow Hasu: https://twitter.com/hasufl
Follow Mike: https://twitter.com/MikeIppolito_

Subscribe on YouTube: https://bit.ly/3R1D1D9
Subscribe on Apple: https://apple.co/3pQTfmD
Subscribe on Spotify: https://spoti.fi/3cpKZXH
- -
This episode is brought to you by Rook. Close to a billion dollars has already been taken out of users’ pockets through MEV. Rook built a solution that automatically drives this value back to where it belongs: with the users and applications that create it.

If you use on-chain products, tell your wallet, favorite app and go-to node provider to use Rook; if you're a developer, message us today to find out how to integrate Rook with your product. Follow Rook on Twitter and them a message at https://twitter.com/Rook.
- -
Resources:
Rollups Aren't Real by Jon
https://joncharbonneau.substack.com/p/rollups-arent-real

Hasu's Mevconomics talk
https://www.youtube.com/watch?v=6xS0xMzh9Tc&ab_channel=ETHGlobal

MEV Share
https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264
- -
Disclaimer: Nothing said on Bell Curve is a recommendation to buy or sell securities or tokens. This podcast is for informational purposes only, and any views expressed by anyone on the show are solely our opinions, not financial advice. Mike, Jason, Michael, Vance and our guests may hold positions in the companies, funds, or projects discussed.

Welcome back to another episode of bell curve.

Before we jump in quick disclaimer, the views expressed by my co-hosts today are their personal views, and they do not represent the views of any organization with which the co-hosts are associated with nothing in the episode is construed or relied upon as financial, technical, tax, legal, or other advice.

Before we get into it today, just want to give a quick shout out to this season's sponsor, Rook.

Close to a billion dollars worth of MEV has been taken out of users' pockets and that's just on Ethereum and that number is only getting larger, unfortunately.

Rook thinks that it's time for a change and they've built a solution which is going to automatically redirect that MEV back to where it belongs into your, the user's pocket.

So you're going to be hearing all about them later in the show.

I'm a huge fan of this team and what they're building.

Uh, today we're going to be talking to John Trombino and Robert Miller.

You want to talk a little bit about why we've got John and Robert on today?

So I think our topic is MEV in the modular stack, right?

And I mean, I couldn't imagine 2 better guests basically to interview about this.

I think John has written some other similar posts about Ethereum's rollup-centric roadmap and recently also hit it out of the park with his post on...

Rollups aren't real is what it was called about.

Like, I mean, it's, it's even hard to say what the post was about because it covered everything, right?

Like different, uh, sequencer options for rollups to like decentralized block bidding.

It's like, can really recommend this post to everyone.

And I think we will explore in this episode, basically, like what this rollup-centric roadmap will look like for crypto, like the different options for decentralizing sequencers, like the challenges also that rollups face in doing that.

We will talk about chat sequencing and cross-domain MEV, and then ultimately we will make the bridge also to Swath.

And I'm very glad that we have today Robert Miller with us, Head of product at Flashbots.

So he's 1 of the main folks in charge of actually designing and implementing Swath.

And yeah, he's also someone who has just this incredible wealth of knowledge about the MEV supply chain.

And so, yeah, I think this would be just a blast of a conversation.

All right, everyone, welcome back to another episode of Bellcurve.

Today, Hasu and I are joined by Robert Miller of Flashbots and John Trabino of DBA.

going to give us a good morning, good afternoon, good night.

Guys, we are really stoked for this episode.

The title of the episode is MEV in a modular world.

Thus far in the first 2 episodes of this season, Hasu and I have really explored the infrastructure from the perspective of main chain Ethereum.

Obviously, as everyone in crypto knows, the roadmap for Ethereum is a modular 1, and a lot of MEV-based activity is going to move up the stack onto some of these rollups and layer twos.

So maybe if we could just start from sort of a 10, 000-foot vantage point.

And John or Robert, whoever kind of wants to take this first.

I mean, how do you see MEV changing as Ethereum adopts this modular roadmap?

Yeah, so obviously things will change a lot.

There's kind of 2 parts to what I would say would change as you move to rollups?

Some of it is kind of what I'll call like fundamental to rollups in that there are different kind of interactions at the boundaries between a rollup and an L1 versus potentially other chains where, for example, if you have like layer 1 sequencing for a layer 2, where that is not normally the case for any kind of other chain.

The reality is that most of it that will change is just the kind of simple stuff and a factor of what rollups look like today.

So simple example being generally all of the MAV is going to be done in real time by the person who is the leader of whoever is choosing the ordering of those blocks.

So if I'm doing swaps on Uniswap on L1, then generally it's the Ethereum validators who are doing that.

To the extent that I move to an L2, it's obviously going to be the sequencers who are doing that there, as opposed to the Ethereum L1 validators who are not going to be that kind of real-time person who's deciding the ordering for most transactions.

And the big difference between most rollups today and the way that any other chain work is the fact that all of them run centralized sequencers today, which is obviously just not a thing that we see on any other L1 chains, because if you had a centralized sequencer for an L1, I don't really know what the point of that would be.

And that has had a lot of nice things for users, but also obviously a lot of negative externalities in that very just kind of simple setup that all of them have taken because what effectively all of them do is we run a centralized sequencer and we keep all the order fill private and we just do a simple first come first serve because that sounds really nice for users of, yeah, you can trust us, we'll give you fast confirmations, we're going to make sure that you don't get front run, we're going to give you, quote unquote, fair ordering of, as we see everything, we're going to put it in order, and that sounds really nice.

The problems that you obviously start to see with that are a lot of the problems that we've seen with, for example, Arbitrum over the past months as they're thinking through their strategy long-term of when you have this simple first come first serve and the only way that I can express my preference of what order do I want to be in that block is, well, I'm going to race to be the first person in that block.

So that means people are investing in latency infrastructure, trying to co-locate with the sequencer, they're trying to spam in many cases.

And you start to see the result of that is you end up with an incredibly heavy load on the sequencer to the point where Arbitrum sequencer had hundreds of thousands of connections to it and they were thinking about implementing proof of work to kind of meter those connections.

Don't do proof of work as a solution to MAV will be my only response there.

So all of these rollups are trying to think through their longer term strategy of, OK, we're going to have a lot of the same problems that L1 set to deal with.

So you see people like Arbitrum starting to think about their longer term plans of, OK, how do we implement some kind of way for people to express their preferences and an ability to express those preferences by paying for those preferences directly, as opposed to just paying by investing in latency infrastructure and spamming the network.

So those are things like their time boost proposal or what Shannon proposed with the frequent batch auction first come first serve variation, where you allow that flexibility to layer on some kind of auction mechanism for people to pay so that you can get much better, much more robust infrastructure in the same way that we see on the layer 1 to deal with MEV today.

I think the only thing that I would add to that is that I think L2s give you a role, specifically give you a place where you can experiment more with these types of different types of ordering policies in a much faster way rather than L1.

It's kind of part of the thesis of the roll-up-centric roadmap for Ethereum that you have more space for experimentation before you can break things down to the protocol level if something works.

So very interested to see how these experiments around fair ordering fare in the wild.

We've already seen some of it play out with the Arbitrum airdrop a few weeks ago that John alluded to.

Interested to see maybe some cryptographic solutions or solutions in quotes to MEV that I've heard might launch.

The last thing that I would add is that I think as you have more rollups proliferating, you have more MEV that exists not just on these rollups, but between the rollups as well.

So I think we're going to see the rise of cross-domain MEV and more demand for solutions for some kind of synchronicity between different asynchronous execution environments as liquidity fragments to many different more places and you see more activity across different rollups.

You know, I have a follow up question to that, but I think we put a pin in it and move it to the section on shared sequencing, which we'll get to later.

I have a follow-up question for you, John.

So you've written a lot about the roll-up-centric future for Ethereum.

You had some iconic articles here, both about that and sequencing.

So can you give us your best guess, how you think, not in terms of MEV, but just overall, how you think the ecosystem will look like in a couple of years?

So the main thing that I probably expect to see out of most rollups is they start to look like L1s in the way that they run in very simple traditional ways.

My guess is that it's not going to be all of these radically different everyone's using a shared sequencer or everyone's using a centralized sequencer type thing.

My guess is that there's going to be meaningful pressure to decentralize, whether that is on a technical level slash social level if we want to, or very possibly, quite frankly, on a regulatory level of guessing, but we don't know what that is going to look like.

There are probably some questions when you're the only person operating this thing.

So there's probably going to be pressure to do that.

And the simplest thing that we know works is you strap a consensus set on there.

You have some form of PBS, you have some form of option between these validators who are on the roll ups.

And we know that's a system that works reasonably well.

So my guess is we start to see that across a lot of roll ups over the next year plus.

I've got a question if I can steal the mic from Michael and Hasu.

So John, how do you square things like existing consensus sets, auctions like PBS, which generally take a little bit more latency with users' existing desire for super low block times on rollups, as well as private mempools.

So how do you think these 2 things, which seem intention to me, will play out in the future?

So as far as the latency, I understand that some rollups care a lot more about that than I care about that.

And that I think low latency, certainly well below Ethereum on block times.

Does it have to be 300 milliseconds, 400 milliseconds?

I think it's fine if your blocks are a second or whatever.

I really don't notice the difference quite frankly as a user.

I don't get the obsession with, let's do this literally at the speed of light.

So that would be my general intuition on latency as far as that.

As far as some of the privacy aspects and like layering on these kind of additional features that users like, you know, we don't want everyone to get front run and stuff.

My guess is it's going to be a little bit easier to implement a lot of that stuff on these rollups compared to something like say, Ethereum.

Because while I expect some form of PBS auction mechanism, et cetera, to arise in these rollups, they're also going to be realistically much smaller validator sets because we have a much weaker trust assumption of what can an L1 validator set do compared to an L1 validator set.

We have a much smaller semi-trusted on weak assumptions type of validator set that's probably running these, maybe you have 10 sequences, 20 sequences, whatever it is.

You start to end up in a situation that looks a little more like the Mevgetes or even a step further of Cosmos, where you start doing protocol on builders, stuff like that.

We're not going to have these super strict requirements of what you guys have to do for Ethereum today, where we have to do this commit reveal process and you know, you want to support this long tail of hundreds of thousands of validators, it's probably okay to have some level of trust on, hey, you know, we'll show you the bundles in this kind of builder interface with the proposer.

And yeah, if you start to steal them, we're going to kick you off because you're 1 of 10 or 20 validators and we know who you are and like you're gone.

So being able to start to offer those features when you have a known set of smaller validators becomes a lot easier.

And similarly enforcing those things like, you know, if you start front running, et cetera, and, you know, have some kind of privacy trust around them.

And I'm going to go back to 1 thing that you said earlier about a single sequencer that I want to follow up on there.

1 is it's just latency in general in these systems.

And I think it's like not very well understood generally that if you have an ordering protocol on your rollup that incentivizes latency gains, what you, sort of the structure of the market you're incentivizing is all actors to eventually co-locate in 1 place.

And so you may not get a rollup that has a single sequencer controlled by a single party, but you may get a rollup that is controlled by a single data center in a single jurisdiction somewhere subject to a single set of laws, which is a huge surface area for regulation risk, as you were saying earlier, John, I think it's only like 1 step worse than having a single sequencer, having your entire chain co-locating in a single Amazon or a similar data center somewhere else within the world.

And what we really want is to have these systems geographically distributed across the world in many different places, such that no single sequencer is able to impose its utility function on the network and arbitrarily sensor a set of transactions.

And the other thing that I wanted to follow up on what you were saying is the sort of pushback against the notion that the PBS style is only useful if you, I think what you were trying to say was, is if you don't have kind of trust requirements between validators.

And if you have a smaller set that is more trusted, you can use something like MapGeth where you're sending bundles in the clear.

And I think what is interesting about PBS is not only this commitment reveal scheme in the privacy in it, but that it gives you the ability to iterate more quickly on features that are user facing than what validators would.

So if you've ever worked with These companies that run validators right now, they're not going to roll out features as quickly as your Builder 69 or your Beaver Builder does on ETH mainnet.

To bring this back as an example of a feature that you could see being offered by a builder on a roll-up, not on, probably won't be rolled out as quickly.

The validator would be something like pre-commitments where a user is paying a small fee to a builder and in return, the builder commits to including the transaction in a certain place with certain states before that the Builder's Block has actually been included on chain.

So I think this PBS style is still useful even in the absence of super hard trustlessness requirements that you're gesturing towards.

You know, that is a very interesting answer to me.

And I think maybe we should jump ahead to kind of this idea of roll up sequencing and shed sequencing, because you were saying that you would expect block builders to offer pre commits or soft commits as a service for users.

Who do you think is kind of in the better position to offer this?

So do you think it will be the sequencer who ends up selecting the BlockBuilder?

What kind of the proposal in that kind of system?

At the roll up level, I would fully expect it to be the sequencer.

I think that there is a use for that type of service on Ethereum L1, particularly because the block times are so slow.

I don't think you need that kind of thing at the roll-up level, because that's the whole point of putting on a roll-up consensus, is that they're going to be giving you these half-second, one-second type pre-confirmations anyway, which is much faster than the L1 itself.

And while there are potentially other features that builders could certainly give you, I don't think the pre-commit is necessarily as valuable, at least at the L2 level compared to the L1 level on that kind of typical UX, because you don't have these super long block times anymore at the L2 level.

And there certainly could be other features that builders give you and are very helpful with.

But that 1 in particular, I would guess, is less applicable.

So I think the unsaid reason why I brought that up as a feature is, I think if you start from the place that these consensus sets need to be decentralized, then, and they're going to be, they have centralizing tendencies and you lose some of the properties that you want if they're all co-locating in 1 data center, then you, like, how do we provide users this really fast confirmation of the transactions being on chain in the absence of having low block times?

And I think pre-commitments is 1 way to do that, even if you have block times that are a little bit slower.

That's why I think they are still interesting in a roll-up context, because I think we may have to lengthen block times anyway.

And like the 300, 500 milliseconds instant confirmation thing may just be an aberration of the past.

I'm not sure that that is true, but I think that is an interesting argument and like an alternative way we can service those needs and why I brought it up.

Do you think that any roll-ups will take that trade-off of trying to look more like a decentralization goal of an L1 where even the L2's consensus itself has longer block times and say a very decentralized committee.

Because at that point, I would just say, why not just use the L1 as your sequencer?

You do some variation of a base rollup if you want those super, super strong guarantees?

Well, so I don't know whether a rollup will try that.

And I think the design space here is pretty broad for like doing a little bit faster, a little bit faster block times than L1, but not a based rollup, maybe based rollup, but with pre-commits.

These are all different trade-off spaces that I'd like to see tried out in practice.

I don't know what is the best, But I do worry that this desire that users have for super fast block times and the implementation of first-come, first-served would lead to geographically centralized chains, which would lead to censorship over time.

And that's sort of what I'm seeing in the future.

And I think this is an interesting design space to play in.

But frankly, I don't know what to expect people to adopt in the future.

The only thing that I would touch on is I think there are reasons why you may not want to be a base role of an independent of this too.

So that's sort of a different dimension of choice than block times and pre-commits.

Hey guys, I almost hate to jump in on such an interesting conversation here, but on the off chance that there are a couple of listeners out there who might not be fully following everything that we're saying here, I'd love to almost like just back up for a second and just level set on sort of a definition of terms.

So, you know, at the risk of almost starting at a pretty basic level, like maybe John, I could call on you because again, you've done so much work on this.

Can you just kind of give us a high level definition of what a sequencer sort of looks like today?

And for an audience that's very familiar with like what a validator sort of does from a functional standpoint, could you kind of compare and contrast how they're different?

And then maybe like at the end of that definition, if you could kind of segue into when we talk about a decentralized network of sequencers or shared sequencing, if you could kind of feed into that definition, I think that'd be really helpful.

So the way that roll-up sequencers work today is quite simple, because there's 1 person running it for each of them.

As a user, I send my transaction to this centralized sequencer.

This centralized sequencer then determines, based on what they've received, the ordering of those transactions, and they give immediate soft confirmations to users, which is really easy for them to do, because, I mean, in particular, they're not doing any kind of complex ordering around them, you know, waiting for long block times or anything.

They're basically just giving you out first come first serve as they receive them.

We give you a soft commitment of, hey, I will eventually put this on the L1 in exactly this order.

So you are trusting the sequencer for that ordering.

They could lie if they wanted to, they could reorder them, put them in a different order based on that feed that they've put out there because there is no explicit penalty against them.

So they're giving out that real-time feed.

And then after the fact, as they're doing this feed, as they have published that, and the users have the soft commitments, they're applying the deterministic, whatever it is for that rollup, state transition function of, okay, I have all these transactions, I execute all of them, and I compute, what is the updated state of all of those things?

So generating a new state route, et cetera.

And pointing out, because this will probably come up later, that sequencing and that determining the state and executing, while they are the same party today, those are 2 logically distinct roles, which can be separated.

So just an important point, cause I'm sure we'll touch on that later.

But that what they are doing today is they're also executing and generating that state.

And then eventually they take that updated state, they post that on the L1 along with all the transaction data, et cetera.

And that's the point at which you actually have a confirmation now of, OK, any full node can look at the data that's been posted to the L1, the state route that's been posted to the L1, and say, OK, this is definitely going to be the state of this rollup.

In the case of optimistic rollups, the L1 isn't aware of what is finalized because you have this fraud challenge timeout period, but anyone, once it is posted to the L1, presuming the full transaction date is there, anyone can compute this will be the state of this rollup.

So the difference is going to be obviously decentralizing what does that actual sequencer role look like.

So a lot of that is today you are entirely trusting that sequencer for real-time censorship resistance, liveness, and the ordering of your transactions.

They could censor you in real time, they could go down, they could reorder them as they want, they could do all of that stuff.

And there's really no explicit penalty against them.

So decentralizing that role in some way, whether that be just a simple leader selection algorithm, or you just implement the whole new consensus mechanism on this layer 2 that looks very much like an L1 at that point, such that there is an actual penalty.

So in the simple example there, if say, you know, we throw a tendermint on a roll-up to decentralize that sequencer, as opposed to the centralized sequencer just giving you out the soft commitment, you now have a whole validator set on that L2 that even prior to the layer 1 confirming it, says yes, we also agree that this is the ordering and this is what will eventually go on the L1.

So if you, even before it gets posted on the L1, if you tried to change that ordering, you know, they would be slashed for reordering the chain at that point because they have made now a much stronger soft commitment to you with the economic weight of whatever their stake is of saying, yes, this is actually what will end up on the L1.

And that also improves the censorship and liveness of the system, just because you're no longer waiting for just 1 operator to potentially censor you to include your transaction, you now have, you know, maybe you're cycling through 100 validators.

So it improves your real-time censorship resistance and ordering guarantees, with the important point that for any mature roll-up, you should get eventual censorship resistance and eventual inclusion at exactly the same rate guarantee of whatever the L1 is itself.

Because you should always be able to, if you have a mature system, be able to force inclusion directly into the L1 itself and do stuff like that, such that even if the entire L2 is censoring me or they've gone down, that I can always get in through the L1 directly.

But those real-time guarantees get much, much better as you decentralize that operator.

And I really like the example, actually, of just imagine the issue with being a single sequencer, right, roll up is obviously okay for now, but you would never have that at the layer 1, for instance, right?

Imagine having 1 validator on Ethereum that defeats the entire point.

And I think users can kind of intuitively grasp there that that's probably not a permanent state of affairs, but in the meantime, it's definitely sort of a honeypot for MEV type activity.

Maybe either Robert or John, if you want to just, before we get to that very important point about sequencers kind of combining the role of proposer and builder that we've separated on the layer 1.

Could you actually just talk a little bit about the different models that we're seeing in terms of MEV on rollups?

Like if you could even sort of compare and contrast that MEVA, the auction sort of style that we're seeing on Optimism versus Arbitrum.

It's kind of wanting to be a fair ordering type roll up.

I can start riffing and John, I'm sure you'll follow up when I'm done.

So MEVA was this really early idea for how you handle MEV.

It predates the official launch of Flashbots is in the Eve Research Post, I think, by Carl from Optimism in 2018 or

And at the time, so roll ups were just bubbling up as an idea, it wasn't as mature as they can now.

And I think the team was thinking about ways to perpetually fund rollups and perpetually use that funding that rollups get for public goods.

And MEVA, which stands for MEV Auctions, was this idea that the rollup sequencer would auction off the right to propose a block in an open market.

And so every single block you could bid, hey, I'm willing to pay 1 ETH or 2 ETH for the right to sequence this entire block, which is the idea behind MEV auctions.

It's kind of interesting because there are some reasons why this structure isn't a good 1 and why the Optimism team has moved away from MEVA.

And it differs a little bit from sort of the PBS, Mambu style market that we see on eFlare 1.

And the way that it differs is that, as I remember the MEBA structure, it is you're auctioning off a block in advance.

So you are buying a block in the future as opposed to bidding in real time for the existing block, which is slightly economically inefficient compared to a bunch of people bidding in real time for inclusion of a full block like you have in the boost today.

This Both of these auctions are in contrast to first come first serve, which is being pursued by the Arbitrum team right now and the way that most rollups actually work in practice today, where the sequencer is attempting to include transactions in the order that they receive them with sort of no way of expressing your preference of priority over other other transactions.

And this can be problematic because it incentivizes, you know, 1 of 2 things, depending on the economics of the domain.

So if your transaction is just included on a first come first serve basis, and there's really a low fee block space, then a way that you could optimize for MEV is just to hit the sequencer as hard as you can, and do your MEV search on chain.

So you actually implement like a background arbitrage model in a smart contract and just repeatedly hit your smart contract, trying to back run transactions probabilistically and reverting when you're not able to successfully do that.

And as a searcher, you have no idea when this is gonna be successful, but you're outsourcing this work of doing it to the sequencer, you're using up gas on chain because it's so cheap.

And the single time when you probabilistically are able to find some arbitrage on chain is going to pay for all of your reverts.

So this is kind of the way that we saw Frisco and Frisur play out on Solana as an example where searchers would send millions, tens of millions of transactions to try to capture a single liquidation, you know, probabilistically hitting the chain as much as possible.

The second way that you see this play out on first-cover search domains, which is like Arbitrum today, Optimism as well, since they're also first-cover search today, is optimizing for latency.

So you try to find where the single sequencer is, co-locate with them, and optimize to the absolute smallest millisecond possible of latency in your code to be able to have the first transaction hit the sequencer possible after some energy extraction opportunity is created.

And this creates all sorts of games that are being played today.

Arbitrum had a problem where there was an endpoint that searchers would listen to on their sequencer, and searchers would try to open up many, many, many, many different connections to this endpoint, I think tens of thousands of them, and it was really hurting their sequencers' ability to operate in an efficient process, And searchers were doing this because they're able to get some level of edge in the latency game here.

And like I said, the other externality of latency games is that incentivize co-location in a single geographic location.

And over time, this is a vector for censorship.

So these are kind of the 3 broad different ordering protocols that I would highlight to you right now.

There's kind of PBS style on on eFlair 1 with Map Boost, where you're bidding in real time, MEV auctions, where you're bidding in advance and in the future and first come first serve, which is trying to include transactions as they come.

Maybe if we could actually dig into that, you know, Actually, Hossam, maybe could I turn this over to you here?

Because I know you gave a great talk about this in Mevconomics, which was definitely worth watching, and I would highly recommend that.

But basically on the importance of PBS on roll-ups or layer twos.

So maybe with Robert's explanation there serving as a jumping off point, could you describe why it's important to kind of transport this concept of PBS from ETH main chain up to the goal up layer?

Yeah, I think it kind of connects to something that both Robert and john were already talking about, which is right now the sequence in these layer 2 domains, basically plays 2 roles, right.

It proposes new blocks but it also decides on the ordering of that block.

And in order to to decentralize the sequencer.

See all Bell Curve transcripts on Youtube

MEV in a Modular World | Jon Charbonneau, Robert Miller