Priority is all you need

Hey everyone. So I'm going to talk a little about the philosophy that's guiding how Unichain is approaching MeV. And it's guided in part by this one particular philosophy, or this one particular system, but really even more by a philosophy about how, what L2 should do with maximum extractable value or MeV. And I think this is more important than any particular solution for it. The question really is, who should this go to?

Who does MeV belong to? I think my belief, and I think one of the core philosophies that Unichain is taking, is that MeV belongs to the users. MeV belongs to the applications and users on the chain. It doesn't belong to the sequencer who happens to have the power to the users. Mev belongs to the applications and users on the chain.

It doesn't belong to the sequencer who happens to have the power to order transactions. And in fact, the sequencer should try as much as possible to alienate that power and to give it back to the users. Why? Because Mev is really bad for user experience. And it limits what applications can do.

If you're building an application and you're building on a chain that is extracting maximum MEV, there's just certain kinds of things you can't do. You can't necessarily give a user the best possible price for their trade. You can't design certain kinds of auctions. And in general, you can get some revenue from a chain by extracting MEV from it as a sequencer, but it's a really inefficient way to do it. So instead, our philosophy is that chains should try to enforce rules that allow applications to capture MeV for their users.

And our belief is that in the long run, a platform that lets users and applications capture their MeV is going to outcompete one that doesn't. So this is how Unichain is approaching MeV, with the help of Optimism and Flashbots. And it's based on this belief that MeV belongs ultimately to the users, and that the applications are closer to the users and so they're able to give that to them. So how should a general purpose L2 support applications being able to capture their own Mev? I think there are a lot of ideas for this and I think on the roadmap potentially we're going to get to many more and Robert was talking about some that Flashbots has in mind.

But I think in the near term one really simple way to do it comes from priority ordering. How does that work? So priority ordering is just ordering transactions in a block from highest priority fee to lowest. And this is what OP stack sequencers do by default. It's what Unichain is going to do within each 250 millisecond Flash block.

And it turns out to be actually a really powerful primitive for allowing apps to capture their own mev if the chain actually sticks to the rules of priority ordering. And so it allows you to do this technique called mev taxes that I'm going to talk about. It also allows you to do a lot of types of what people call application-specific sequencing. And in general, I think it's an underexplored design space of what we can do just on top of this very simple primitive of having a chain that orders transactions by priority and doesn't deviate from that. Now the big catch with priority ordering is that it's not incentive compatible for the sequencer.

And so trustlessly enforcing it on a sequencer or on a proposer on L1 is kind of a difficult problem. And so in order to do a MEV action fairly on-chain, you don't need to just have priority ordering of transactions within a block. You also have to guarantee that nobody, the sequencer's not censoring transactions from that block. You have to guarantee that they're not peeking at transactions that are in the mempool, and you have to guarantee that there's no last move advantage. They're not acting later than anyone who's able to add transactions to that block.

It's easy to do with a trusted L2 sequencer. And most L2s basically do this already, ones like OP stack sequencers that obey priority ordering. But making this trustless is a difficult research problem. And in my view, it's an important prerequisite to ever being able to fully decentralize a sequencer. Because if we were to decentralize a sequencer.

Because if we were to decentralize a sequencer right now, for example, just by having sequencer rotation from one sequencer to the next, you're going to end up in much the same kind of MEV free-for-all that you have on L1. And that's just a worse situation for users. So in order to get a decentralized sequencer, we're going to need to first figure out how to take whoever is a sequencer right now extract excess mev from the chain, or still allowing applications to be able to extract it. And I think there's a lot of promising research on this area. It's not the primary topic of this talk, but I think we all talk a little about how this fits into the Unichain roadmap, particularly through the work that Uniswap, Flashpots, and Optimism are working on with the Unichain validation network and with Rollup Boost.

So the main body of this talk, I'm talking about how priority ordering actually allows you to achieve this. So some background on this, on MeV in general. So when there's competitive MeV available in a contract, for example, an automated market maker that needs to be at the top of a block, or a Dutch auction that is changing its price every block, and whoever first interacts on the block gets to trade with it, usually there's a lot of searchers who are just fighting to win it. And you can think about a searcher as just like someone in their basement just running a script. They don't necessarily have any particular advantage over anyone else, it's very competitive.

But in general, they're competing to be the first to fill it. And as a result of the competition among these searchers, and there are a lot of people out there in the world trying to do this and doing it very well, generally they don't actually make that much money. Most of the profit from competitive MEV usually goes to the sequencer or to the proposer on L1. And one way that this happens on L2 chains in particular right now is priority fees. So most, like I said before, most OP stack chains, so like Base, Unichain is going to OP mainnet, blast, these all sort transactions in descending order of priority fee.

And what happens is searchers are competing to be first in this block in order to extract this MEV from it, which means they're going to compete by paying the highest priority fee possible. This means that effectively all of the MEV that they would be getting actually ends up going to the sequencer. And you can think about this as a type of on-chain auction. It's an auction that's happening in this mempool or in the block itself, where people are just bidding to pay the highest priority fee to be included first. Now right now this MEV often, if applications are written naively, goes to the sequencer.

But the contract, of course, would rather have this MEV. Now, what if I told you the contract can actually get this MEV right now on these chains without the chain having to do anything special to support it, just based on how the sequencers are currently working? And that's how MEV taxes work. So here's the core idea behind MEV taxes. The priority fee that people are bidding on, this is visible to the smart contract so the transaction is interacting with.

So imagine if the smart contract just looks at the priority fee and says, okay, if you're charging $1 in priority fee, I'm going to charge $99 on top of that. So any searcher who wants to pay is going to have to pay 100 times as much as what they pay to the sequencer to meet the smart contract. In that case, that means that in equilibrium, 99% of the MEV ends up going to the smart contract instead of the sequencer. And you can actually make this arbitrarily large. You can make it 99.

999% ends up going to the smart contract rather than the sequencer. Now, what is this ultimately? I think the best way to think about it is an auction. The smart contract is auctioning off the right to interact with it first, but normally this is an auction that's happening for the benefit of the sequencer, and MEV taxes means that it happens for the benefit of the application. And ultimately the application is in the best position to give it back to its users and properly allocate it to the users.

So it's important when looking at this to really understand what's happening here. This isn't money that's coming from the searcher. The searcher is making the exact same amount of money that they were before. Instead, you should think about it as the money that would otherwise, look at this before, be paid to the proposer, to the sequencer. So before, there was some amount of profit that the sequencer was going to make.

That's the little green bar there. But most of the MEV was going to be paid as part of the priority fee, which basically just currently goes to the sequencer. Once you've added MEV taxes, the green bar stays the same. The searcher isn't paying anything different because they're changing how they bid. They're changing the priority fee that they pay because of the MEV tax.

Instead of paying the full amount of the MEV or the MEV minus their profit to the sequencer in priority fee, instead they're setting a much lower priority fee because they know they're going to need to pay this 99 times larger Mev tax. So searcher changes their behavior. They still pay the exact same amount, make the exact same profit total. What happens is the proposer, the sequencer, gets less in priority fees and the application gets gets all of it. So I think this is a very powerful primitive.

It actually covers a lot of what we think about when we think about MeV. So one example is automated market makers that capture MeV for their LPs. So this is this famous problem of loss versus rebalancing. If you can auction off the right to interact with your AMM first in the block, then you can capture that MeV for yourself and give it to your LPs. case, and I think in my view the motivating case for MevTax is order routers like Uniswap X.

This is a case where searches are optimally routing users. Basically you put an order in and you say I want whoever is able to fill this order at the best price. A user is trying to sell 1 ETH. Whoever is able to give the most USDC in exchange for that 1 ETH gets to fill the order. And the way the MevTax is with the Uniswap X work, and this is in test right now.

It's actually been prototyped and running live on base right now, is searchers are bidding to pay the most USDC possible to that user. And that gets them actually included first in the block. So it's a way to have this auction for Uniswap X happen on-chain, which used to be an off-chain auction for order routing, now it's happening on-chain as part of this priority auction. Another example is oracles that capture value that is created by their updates. If you imagine someone like Chainlink saying anyone who includes our oracle on-chain has to actually pay us for whatever back-running profit they're going to get from this being included, then that MEV can actually potentially go back to the oracle.

Whether it belongs to the oracle, again, I think depends a lot on what competition there is for oracles. But in general, this is just a mechanism that actually oracles will be able to use. And this is what people have called oracle extractable value. And finally, you can do this really in a very general case, if you have just any transaction that's arbitrarily going to potentially produce some kind of backrunning mev, you may not even know what that mev is, but you know that there might be mev from backrunning it, you could actually just feed it out to the world as a meta transaction and just auction off the right to backrun it. Auction off the right to include it in a transaction, and whoever actually includes it pays a fee to the user proportional to the priority of that transaction that goes back to the user.

In order to capture any back running or potentially even front running Mev from this arbitrary user operation. So that's one type of application that can be built on top of priority ordering or one type of mechanism on top of it, Mev taxes. But I'm also going to talk about one other kind, because I think there's actually a very wide design space around how you can use priority ordering. And one other category of this is application-specific sequencing. I'm not going to use the acronym.

But in application-specific sequencing, the idea is apps might want there to be some rules about how you can interact with their smart contract. So we call these sequencing rules. So example, suppose you have an on-chain order book and you just want applications that interact with it, you want users when they interact with it to be able to cancel transactions before anyone is able to fill orders on that order book. And this is kind of a typical thing for how some central limit order books work in TradFi, which because often market makers are worried about getting picked off by sophisticated fillers if they place an order and then cancel it. And aren't able to cancel it until a user outbids them to fill it.

They're sort of faster in getting this fill transaction included. So this is one type. Again, I'm not sure this is necessarily the best design for an on-chain order book, but it's one kind of thing you might want to do with a sequencing rule. And you can do this, actually, with just priority ordering. What's cool is people have talked about ways to do this, build in different lanes into the end of the blockchain itself, but you really don't need that.

the transactions are ordered by priority, and you could build application-specific sequencing on top of it. So here we say, if you're going to cancel an order, you have to include it in a transaction that has priority greater than some number n. And if you're going to fill a transaction, you have to include it in a transaction that has priority less than that number n. And so that gives us blocks where all cancels end up preceding all fills. And so market makers who want to cancel their orders because the prices have moved, they get the right to do that.

And they're not competing for MEV with the users who are trying to fill. And I should note that these priority fees, I imagine this being very low numbers for N, a very low number for N. So actually, the priority fee that you're paying to the sequencer is pretty trivial in terms of what you're paying there. And then you could potentially layer a MevTax on top of this for the actual fills themselves so that they're still competing, so that any Mev that comes from that is actually still going to the application or to the users whose transactions are being filled. A lot of designs around this.

My point is MevTaxes are not the only kind of mechanism you can build on top of priority ordering. So some benefits of priority ordering and mechanisms like Mevtaxes. One is that they're really easy to implement. So in general, building a Mevtax into an application is just a couple lines of solidity. You don't have to write any Rust.

We love our Rust developers. But you don't have to do anything off-chain. You don't have to get any kind of special support from sequencers as long as they're obeying the rules of priority ordering. And in fact, this is the default behavior in Geth and Reth and the OP stack sequencers. And it's what Unichain, what Rollup Boost is going to be using within each flash block.

It's just like a lot of chains and Arbitrum perhaps is the biggest and most well-known exception because they use currently first come first served and are planning on this change to a totally different thing called time boost. But for most sequencers, the order transaction by priority, this just works out of the box. And there's no need for additional off-chain infrastructure. You don't have to run your own consensus. You don't have to run your own relayers or anything.

This just works. And searches can just follow it and obey it. Another benefit is that applications remain composable and atomic with on-chain liquidity to what I think is about as well as it can do. Although, again, I think there's probably ways to potentially improve this. And we're researching that.

But in general, the benefit of this is unlike an off-chain auction, so the way that Unistop X works right now on mainnet is that if a user has an order, they want to sell, say, one ETH, there's an off-chain auction, sort of an RFQ process, request for quote, where fillers bid to fill that quote at the best price possible. And then whoever wins that auction then is committed to fill it on-chain. But this means that the filler has to actually win two auctions. They have to win the RFQ auction and then separately, maybe a few seconds later, maybe even longer, they have to win this auction to get their transaction included on-chain. And the situation could change a lot in that time.

Prices could change off-chain and they could change on-chain. It means they have to potentially win a MEV race in order to, for example, fill that user against on-chain liquidity. And if they're not able to actually fill it against on-chain liquidity, they might regret having won that first auction. And that adds some uncertainty that makes it harder to be a filler, and I think particularly makes it harder to be a filler with on-chain liquidity. And at Uniswap, we love on-chain liquidity.

We want on-chain liquidity to be competitivections on-chain. And that's what Uniswap X with MEV taxes does. It's particularly useful, I think, for complex auctions, like Uniswap X order routing. And the nice thing here is with Uniswap X, in addition to making on-chain liquidity competitive, it also means that you get these fillers who are able to now search the chain and find the most compelling routes to find the best prices for users and fill them on chain. And I think that's just always going to be more sophisticated than just any order router that Uniswap or anyone else could try to write, because it becomes a competitive process.

So there are some challenges to priority ordering. I think the biggest one is it requires the block reposer, or in the L2 case, the sequencer, to obey these rules of competitive ordering. And that requires them not to censor transactions, because if you can censor transactions, you can easily get around the MEV tax mechanism. It requires them not to peek at transactions, because that would actually make these auctions unfair. And it requires them not to delay transactions, or I'll say, the ability to move after someone else's transaction, after anyone else is able to submit transactions.

If you're able to submit transactions later, you might actually have more information and be able to cheat at these auctions in a way that discourages others from participating. And one problem is it's actually in the sequencer's interest, especially if applications are using things like Mevtaxes. It's in the sequencer's interest to try to violate these rules. And enforcing them trustlessly is an open problem, but it's a big part of the Unichain roadmap. Another couple of problems with it, or challenges, failed bids result in reverted transactions on-chain.

And I think this means that because you're doing an on-chain auction, if a lot of people are trying to submit these bids to participate in this on-chain auction, they might end up with reverted transactions and paying some slight fees and potentially filling up the chain. This could be prevented by the sequencer. And in fact, Unichain is planning to launch, thanks to support from Rollup Boost, Unichain is planning to launch with reverb protection. And so that actually prevents the failed bids from having to pay any fees, which is very nice. So one more, applications with MevTaxes.

Generally, you're going to be charging a very high multiple on top of the priority fee, which means if priority fees go up, which means generally because blocks are full, if the minimum priority fee to get included on blocks go up, that means you may get priced out of the chain entirely. This is pretty rare on L2s today. I think it's less than 0.3% of blocks on base currently. But this is one potential issue with them.

And finally, multi-app mev can result in some complex issues with attribution and some interesting different equilibrium behavior between applications. I'm not going to get into all the difficulties that that produces, but I think some of them might just be inherent to any system for trying to capture mev, which is when you're interacting with two applications, where does the mev go? It kind of is maybe an unsolvable problem. But I think, in my view, priority ordering might actually do almost or about as well as you can do in this. So how do we make priority ordering trustless?

There's a lot of designs for doing these, and I'm going to focus on the ones that are part of the Unichain roadmap. And I think those are two research streams going on. One is the Unichain Validation Network, which is a network of attesters who have tokens delegated to them to serve as attesters on the network. The current plan initially is to have them attest to the validity of blocks. You should check out the Unichain white paper for more details on how the Unichain validation works.

But one could imagine in the future them being able to attest to more than just validity, for example, being able to attest that blocks are not delaying inclusion of other transactions, that they're not censoring transactions. And that could potentially help make these auctions more fair. And then the other line of research that's going on in this is Rollup Boost, which is the work being done by Flashbots as a TE builder for L2s being prototyped for the Unichain. And there's a lot that RolloBoost I think potentially can do, including for helping make the chain more mev-resistant for applications, including things like Flashblocks and trustlessly enforcing priority ordering within the block. But one of the biggest difficult research problems I think that they can really help with is encrypted transactions, because if you want pre-transaction privacy, TEs like are used for RolloBoost are one of the best ways to do that.

So thanks everyone. Thanks so much for everyone for coming to Uni Day. And yeah, come reach out to me if you have any questions about priority ordering.