Beyond Multidimensional Fee Markets

automated block building come on up well thanks for the intro sorry for ragging I've changed the title and the content isn't that different, but this was more exciting. Cool. So I'm Mariam. I work with Ritual. This is based on joint work with Naveen, also at Ritual and Columbia.

So let's get into it. Okay, so one mental model for what blockchains do for us is providing this fundamentally new primitive, which is permissionless, verifiable computation on a shared global state. And this computation is sold in these indivisible units called blocks. So you can think of that as the supply side of this exciting new market. And on the demand side, we have users who want to use this computation.

So this is all the apps, all the people whose happiness and welfare we care about and we want to onboard. And naturally, we need a fair key market to sit between these two sides, supply and demand, and ideally figure out how to allocate supply to demand and how to price things in an efficient way. And everything would be great if the picture was just these two sides, but there is a third set of participants in the system called agents, or what I will call agents. And these are not users or the computation providers. They are facilitators of the market.

But the role is pretty complicated. They can be useful, they can be adversarial, and I argue they're necessary. And the reason they're necessary is that to get the permissionless, verifiable, all these new properties of blockchains, we need decentralization. And that means we need to distribute power geographically and across nodes, and that means every part of the blockchain, including its fee market, might be run by a selfish party with its own objectives. So we need to design markets with these agents in mind.

So this is a nice diagram by Frontier. It shows just how complex the ecosystem of agents involved in block building is. They have specialized, they have into like little parts of the market and, yeah, like have a mixed influence, I would say, on the quality of user experience. And I guess this is kind of at the core of what MEV is. These agents have a different set of objectives than the network or users.

All right. Cool. than the network or users. All right, cool. So here's a narrative that I think is pretty prevalent.

And it's that agents are bad and MEV is toxic. So I will just outline the narrative. I think it will be familiar. So these agents have their own objectives. They have outsized control over block production.

And as a result, I guess first let me show you the outsized control over block production. And as a result, I guess first let me show you the outsized control. This is, I took this maybe an hour ago. The most recent Ethereum blocks are built by two builders. That's not fully decentralized.

And because of this potential incentive misalignment between agents and users, user welfare can suffer. And this is an old tale that has been told many times. I will mention this paper that we kind of formalized this, the challenges imposed by this incentive misalignment, where we show an impossibility of designing any, like no matter how clever you are, you can't design a good market so that this incentive misalignment doesn't cause issues. The user welfare will always suffer. Okay, so in response to the evil agents and bad MEV, people have taken some approaches to reduce or mitigate or democratize MEV, where reduction is at the app layer, let's make new applications, let's use batch auctions instead of the AMMs we use now, just to have less MEV, less value available on chain for these block producers to extract.

Mitigation is things like encrypted mempools, suave. This is where you tie the hands of the agents, limit their power so that they don't have that much leeway to extract value. And democratization is kind of throwing your hands in the air and saying this evil is inevitable. It will be there because there is this degree of freedom these agents have, so at least let's try to reduce this negative side effects. Let's make sure we don't get censorship, let's make sure that at least the validators are decentralized.

So I think this is kind of the lay of the land and what I hope to do here is give some form of a counter-balancing argument. I'm not going to say agents are amazing and there is no MEV issue, but I'm hoping to argue that agents can be useful and sometimes crucial to use, and MEV is more nuanced than just toxic and evil. And I guess more concretely, I will give a framework. I will define this concept of agenticism and we can give a framework for how to talk about the degree of agenticism in different block production paradigms and then follow up with the way of reasoning about for a specific application or chain, how do you choose which block production paradigm to use? More agentic or less agentic?

Cool. Let's get into definitions. So automated is something I haven't mentioned. I'm using that as the opposite of agentic. So let me define what it means to be an automated block building function or paradigm.

You have users, they insert transactions into a mempool called mThisMempool. Then there is some function that looks at the mempool and generates a block. As simple as that. So there is some, let's say even deterministic function that goes from the mempool to what the final block will be. The point is there are no agents in this slide at all.

No one has power over what goes into the block. So an allocation rule is automated if it takes this format. It's a function of the mempool. So agentic block building, we have this second category of agents. They also give an input to this allocation rule, and their input is abstractly defined here as a vector of actions.

They're sophisticated. Their actions can be complex. And the point is that this function now depends on the actions of the agents. This is very abstract, not very useful, but the point is that depending on the structure of this function, agents can exercise more or less power over the output that is the block. So let me now define what it means to be agentic.

It's defined as a relation. We say an allocation rule F is more agentic than an allocation rule G if, I guess, maybe the picture is more useful, if the set of blocks that agents can generate, just the range of blocks that they can generate, is a superset of the range of blocks of the less agentic one. So this is saying G is less agentic because if the agents collude together and range over all possible action vectors, the set of blocks that they can generate is limited. It's a smaller set. Good?

So that's the definition of agentic and automated. And naturally, there is a spectrum from agentic to automated. So let's throw some example projects onto this. I will throw some acronyms. Don't worry if you don't recognize them.

The hope is that if you do recognize any of them, hopefully it will help you understand how the spectrum works. But it's not important if you don't recognize them. So at the very agentic end, I've put in Bitcoin and Solana. And why do I... Let me actually...

The way the Bitcoin fee market works, in case you don't know, it's a first price auction. Transactions submit bids. If they're included, they pay that bid. There is no restriction on what the miner can include in the block. It's agentic because it's just not restrictive.

The set of blocks that the miner is able to create is just all valid blocks. Solana, similarly, doesn't have any... The protocol doesn't impose any restrictions on what blocks are valid. And Ethereum, I think, is very close to the agentic end. It's almost a subtle point why AFF59 is slightly to the right, because currently a valid block is not allowed to include a transaction with a bid lower than the base fee.

So that is some form of restriction. Maybe a block producer wants to include a, maybe like there is MEV in a transaction, they want to include a transaction and subsidize its bids. That is not allowed right now. So MevBoost, a lot of the block production pipeline in Ethereum is very agentic, get the MEB out, then figure out how to democratize and distribute it. All right, so I think the shared sequencing marketplaces also, like Espresso, take a very agentic approach.

Let's outsource this to a market of complex agents and hope then sequence that way. Alright, on the other end of the spectrum, automated block building, there's ordering rules that are enforced by a combination of consensus, cryptography, and trusted hardware. So for example, Chainlink's fair sequencing service is the first come first serve service. It's kind of dictating the ordering of transactions. Most L2 sequencers are this way.

Suave, Prof are used cryptography to encrypt them and pull and then enforce a specific ordering. These are fairly automated. There isn't that much room for block production markets. There isn't that much freedom. Okay.

I put Fossil and Braid in the middle. I think these are somewhat restrictive of what the block producer can do. So in Fossil, there is a committee that enforces a template on some fraction of the block and what it can include. In Braid, the power of any specific proposer is limited. So both of these are, they're still a market.

Agents altogether can affect the outcome or the block that is produced, but they can't produce any block they want. Cool, so how do we choose the right place on the spectrum for our specific app? And to do that, we need to define benchmarks. So what do we care about? These are some properties that people like in fee markets.

None of them is new. Low latency is pretty obvious. You want fast turnaround times. Tractability, this is maybe less often cited as a property that we need, but if you have an automated rule, if it requires solving very complex MP hard problems, we can't run that on-chain. So it is crucial that the auction itself is computationally tractable to run.

Simple UX is capturing a bunch of things, but roughly speaking, we don't want users to have to do very complex strategization to participate in the mechanism. And then there are these two points that are addressing efficiency. One of them is surplus maximization. And if you remember the first slide with supply and demand, there is gains from trade, the possibility of generating surplus by matching supply and demand effectively. And ideally, we want to create the most surplus possible.

And simultaneously, to be efficient, we don't want extraction. So users are the people whose utility and welfare we care about. Agents are not. So we don't want all of the surplus to go to agents. And if we're not careful with market design, the surplus will go to agents.

And I guess let me highlight the fact that these two are, they interact in a subtle way. They're kind of a dual objective, both trying to target welfare and the tension between them is at the core of when you use agentic versus automated block building. And the reason is that sometimes one end of the spectrum is really good at maximizing surplus, but at the same time it will be extractive. So you have to figure out how to trade these two off based on your application. So I have some time left.

I will go through two specific DeFi based examples and use them to highlight the trade-offs between the two ends of the spectrum. The first one is front-rending. If you're not familiar, I'll quickly explain what it means. There is a user wanting to buy ETH on UNI. This is the current ETH price.

It's $3,200 USD, USDC. And the user submitted this transaction to a public mempool. An agent sees that transaction and puts a, sandwiches it with a buy on the left and the sell on the right. And the effect of that is that the first agent transaction drives up the price of ETH on UNI, then the user transaction happens at a worse price, and then immediately the agent can turn around, sell the same amount of ETH, basically make $300 of profit at the cost of $300 lost to the user. This is a perfect example of purely extractive MEV.

It's a zero-sum game between the user and the agent. This is the kind of MEV we want to get rid of, avoid as much as possible. Okay, so it should be pretty clear that agents will extract this MEV. So agentic block building will be bad at this, whereas automated will be pretty good at this. The design principle of PROV or SUAV and these increment mempools were exactly to mitigate this.

Maybe if we hide the direction and size of the order, we will leak less information and there is less front-running and sandwiching happening. So the second example is arbitrage between a centralized exchange and a decentralized exchange. Again, I'll kind of define it quickly. Basically, you can have an asset pair, again, ETH and USDC or USD, trading on two different exchanges, in this case Binance, a centralized exchange, and Uniswap. And so block times are discrete.

Centralized exchanges are not. They operate continuously with wall clock time. So here the orange line is the price on Binance, and the red line is the price on Uni. Basically, the price was as of the previous block, 3,200. Nothing has happened since because this is the deadline for the next block and there can be a discrepancy, a gap between the prices on the two exchanges.

So what an agent can do is, for example, at this point in the slot, observe that, oh, the price is lower on Uni, higher on Binance. I can inject a transaction on chain to buy ETH and sell on Binance and collect a profit. Very simple. And I guess, first of all, why is this good? I'm arguing there is possibility for generating surplus.

Those arbitrageurs are providing a service. And I guess the reason is the same reason markets being efficient is good. You want the markets can be viewed as a venue for aggregating information. And you want prices to be reflecting the true value of assets. And so for the health of the market, it's good that the price on uni is reflecting the price on Binance and they're all reflecting the overall market sentiment and everyone's information.

But at the same time, there is a possibility for extraction. So this person is making money. Where does the money come from? You can't print it. There are liquidity providers on Uniswap, and this is coming kind of at a cost to them.

I won't be able to fully define this, but this is what lever, loss versus rebalancing, refers to. And I chose this example because it shows the trade-off between the two welfare objectives. You can't simultaneously satisfy both of them at once. And yeah, there's a tension between them. Okay.

And maybe one other observation here is that to successfully run this trade, it's important that this agent knows that they will be the block producer. So remember in this step, the selling on Binance I can do at any time. The buying on ETH in the middle of the slot, I'm not sure necessarily that I will be able to do this side of the trade. And if I can't do it, if I'm uncertain about that, there are a lot of costs I will pay. In fact, this trade is negative EV.

It's bad for me. So the more uncertainty arbitrageurs have about their ability to do both legs of the trade, the less willing they are to do it, they will require higher margins, larger art bounds, then the price between uni and binance will deviate more and more. That is less accurate pricing. That's less surplus. That's bad.

Okay. So this observation, I want to highlight and ask you to remember because it will be relevant to the next slide. I am short on time, so let me maybe pick a specific point to make. Okay. So let me focus on this point.

So the claim here is that automated block building will not be able to get surplus maximization and be computationally tractable. And here, let's consider a specific way of automating block building based on priority ordering. There's this nice post about why this is a pretty good idea. So the way this works is every transaction comes with a single bid, you order transactions in decreasing order of bids and that's all it is. And the hope is that this will be efficient, but as this post also points out, this scheme is vulnerable to reversions.

The issue is that if coordination has to happen through the mempool, instead of by delegating fully to an agent who has full control and knows for certain that they will be in charge of this block and they can for sure do all legs of the trade, there is some risk that these people don't know for sure whether their trades will go through. There is some loss, efficiency loss, because of that. I think I'm about out of time. So let me skip to the conclusion. I've introduced agenticism, outlined the spectrum between agentic and automated block building.

Roughly speaking, automated block building is good with respect to latency. There aren't a lot of parties that have to communicate. And also generally, there's less extraction. But they might not be optimal. They might not generate the most economic value.

So what's an application where we should opt for automation for? If you want nice on-chain, you want low latency, you don't want front-running, you should be more and more automated. Agents, on the other hand, are very good for maximizing surplus, especially when the user preferences are complex, but they will be selfishly trying to extract as much of the surplus as they can. And one example of where agentism is good is Ritual. The Ritual Resonance is a marketplace we designed for AI computation.

The setting is nodes and AI queries all have very complex preferences, and because this allocation problem is very hard, because it's a large complex matching problem, so there's a lot of potential for generating surplus, and there isn't that much toxicity or DeFi activity going on. So perfect example for being very agentic, and that's the end of the spectrum that we were on. And DevNet is coming out today, so check it out. All right, thank you for listening. My me.

Thanks a lot for that talk. Super detailed and gets into, like, nuances and also, like, the examples were good. You can scan the QR code for your questions and let's quickly get to them. Talking about CERC surplus maximization and decreasing extraction, how do we draw the line between a user and an agent? What determines whether we think of an extracting entity as a user or agent?

That's a very, very good question. It's exactly the trade-off I was trying to highlight. I think it's an art, not a science. For example, in this type 6 arbitrage example, if we want to think of the liquidity providers as users whose welfare we care about, it's a different story than if we just care about the traders and how accurate the price is for them. So I think what happens is for a specific application, you try to decide, just draw a boundary that includes the people whose welfare and utility you care about the most.

And yeah, so you draw the line based on the purpose of your application. Right. The other question, will Jared from Subway be out of a job with automated block building? No comment. Can you talk about the resources the ritual is selling and what preferences the users might express over there?

Yeah, so ritual is selling AI inference, basically. But it could be different AI models. And there are nodes that are very heterogeneous. So they have different resources, CPU, GPU, bandwidth. It's very high dimensional, so much so that it didn't make sense to design a specific multi-dimensional fee market.

It's just too many dimensions. And users have inference queries and Ritual is providing this marketplace to match queries to nodes. And the preferences can be as complicated as a user might have privacy concerns, so it might want an MPC containing a set of nodes to run its inference. A user might have latency concerns where I'm patient, I'm willing to wait a while or not, and all of these preferences should be able to be handled. Why is it bad for automated strategies to give up on surplus maximization?

In the front-running example, the surplus capture appeared to be bad for user welfare. Yes, I would argue in the front-running example, there was no surplus generated. It was a zero-sum game. It was basically a transfer from the user to the agent. So in many extractive zero-sum examples, it's just not good to have agents.

But a good example of, I guess, surplus is maybe in the case of ritual. I described these very heterogeneous nodes and users. And if you write any piece of code to try to match these together, the problem of optimally matching them is just NP-hard, hard to approximate as well. So doing that on-chain will lose out on the efficiency you could get by having a more sophisticated agent find a better allocation. I hope that answered the question.

Seems a very L1 problem. Do L2 solve this by running a centralized sequence? I think it's not just an L1 problem. I guess if an L2 runs a centralized sequencer that is committing to a first-come, first-served ordering, they are choosing a very automated approach. They are potentially missing out on complementarities between transactions.

So yeah, I think it applies to other layers too. And the last question, what sort of support or major changes do you expect from the chain or the foundation? I don't know that this applies to me. Is it Ethereum chain or foundation? Yeah, I don't understand the question.

Yeah. Yeah, and the last one, if you want to comment.