# A proposer's perspective on preconfirmations: a new game in town? by Michael Moser | Devcon SEA

- Speakers: [Michael Moser](https://streameth.org/speakers/michael-moser)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 20:15
- Watch: https://streameth.org/watch/yt-Wa5O4TMEdwE
- YouTube: https://www.youtube.com/watch?v=Wa5O4TMEdwE

## Description

This talk will provide a node operator's perspective on the preconf transaction pipeline by examining incentives and infrastructure best practices. 
Specifically, ways node operators may attempt to earn higher revenues than peers through custom optimizations will be discussed alongside, related risks, and potential mitigations.

Speaker(s): Michael Moser
Skill level: Intermediate
Track: Cryptoeconomics
Keywords: Validator Experience, PBS, Transaction fees mechanisms, preconfs

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

not operator's perspective on pre-confirmation transaction pipeline. Please welcome our speaker, Michael Moser. Hi everybody. Let me just calibrate this. Yeah, so I'm Michael. I'm the head of research at Chorus One. We are node operator with just about 3 billion in stake. Uh some of you guys might know us from some of our research papers actually. For example, we've designed MEV mitigation on dYdX before. Uh which is a system that's currently in production. We were also quite early to timing games. We started kind of experimenting with this type of thing early last year. And then and then we think it's always important to to strike a balance between rational competition and ecosystem health. So we've published quite a bit about our approach, right? And we took a very transparent angle to that. And I think philosophically, this presentation is an extension of that. I just want to talk about pre-confirmations from a proposal perspective. And maybe a more spicy way of framing this presentation could have been, you know, timing games in pre-confirmations, what do they look like? And then secondly, what could a an earlier approach to pricing pre-confirmations look like, right? I think first of all, it's important to note that it's very early days. I think there's just one public pricing model for pre-confirmations. And so what I'll describe here is more of a general approach rather than, you know, specific model because this will be very parameter dependent. And you know, in the spirit of rational competition, we'll talk about what it is that we do, but we might not have all the parameters public, right? Naturally. Um yeah, so here's the agenda. I'll quickly walk through the types of pre-confirmations. Then I'll talk about the pre-confirmations pipeline from a proposal POV. Uh game A is kind of like a timing game, right? What that would look like. And then game B is pricing and optimal inclusion. So, let's dive in. Um yeah, I think there's a lot of jargon flying around, and I think it's important to just bring these things back to what they actually are. They're basically inclusion preconfirmations, and then they're execution preconfirmations, and I think the key difference between those, you can really boil it down to the two points I give at the top of the slide. An inclusion preconfirmation is just a credible commitment that your transaction will be present in a future block, uh but it's not a commitment of the transaction actually executing, right? The transaction may fail. So, what the validator does is it tells you, I commit to putting your transaction in there, but then again, you know, if it touches contentious state, there's a chance that it will fail. An execution preconfirmation, by contrast, actually commits to the transaction being one, present, of course, and then two, subset executed in the block. Therefore, it should not fail. Okay, so, what does this mean in practice? Implication one, execution preconfirmations can touch contentious state, right? They also require the block to be simulated, because otherwise, you cannot commit to a transaction actually landing, right? You need to simulate the block out as a whole to understand whether this is a commitment that can be credibly given. And then, conclusion one from that is, execution preconfirmations are best issued by builders. And I think there's two really simple reasons for that, right? If you just demystify it, reason A is that builders have private flow, um and, you know, as a like a proposal, you don't see that private flow, so you a priori do not have the option of simulating a block out fully, simply because not all transactions are available to you. And then, um and then B, uh builders also have kind of sophisticated pricing, right? There's something that they they they do in terms of the ads, part of their competitive edge. For a proposer, it's really more about about running infrastructure really well. Okay, I see the I see the the light went out, but hopefully the the rest of my talk will be enlightening, but maybe I'll do my best. Inclusion preconfirmations on the reverse don't touch contentious state because otherwise, you know, it's not something that that you you could you could commit to without giving the execution preconfirmation, which means they're typically best issued by proposers. And the reason for that is just that the proposer is certain to propose, right? With a builder, builder A may may win the auction, but builder B may also win the auction. With the proposer, you know for sure that the proposer is going to propose to the next block, and therefore you do not have to probability gate it, right? If you get a preconfirmation from a builder, you always have to expect that that builder might not win the block, or you know, it must solicit downstream agreement from the proposer, but with the proposer, there is no such uncertainty, right? The proposer is quite quite certain unless something really terrible happens on the infra side of things, which is unlikely. Um Okay, so let's zoom in on the latter point. Let's zoom in on inclusion preconfirmation transaction pipeline for a proposer. Um yeah, I just kind of sketched it out a little bit there. There's of course a lot of nuance here, but I think to understand the general concept, it's enough to to understand the general transaction flow. And then I think we can dive deeper into into more granular detail. Um the generalized proposing inclusion preconfirmation transaction pipeline, you basically have a transaction originator. It would be, you know, it maybe it's a base roll up, maybe it's a user. And that transaction originator would send the transaction to some kind of transaction aggregator, right? Uh you do not want transactions to be sent to the validator directly because then what what functionally happens is it can be you know it opens up a DDoS attack vector and that would very badly reflect for example on home stakers. It also generally wouldn't be the way that people are are set up and if you're betting on Solana you you are proposals expect a certain amount of traffic on Ethereum that's really not the case. So there would need to be some kind of proxy in the middle. You can conceptualize a little bit like a relay. And this proxy can do two further tasks, right? Either it just takes the transactions and then forwards a set of transactions to the proposer for the proposer to choose, pick and choose, or it does pricing itself. And when it does pricing itself you have frequently the lingo that's being used is we are talking about a a gateway here. Um so really that's kind of where the the path diverges, okay? Either this type of proxy does pricing or it doesn't do pricing. And then for the proposer, if you want to optimize, you have to be opinionated about two things. First, you must source transactions optimally. This basically how do you interface with the relay gateway proxy, whatever you want to call it, in an optimal way. And then B, yeah there's a there's another scenario where this is like a subset of scenarios where you can engage in pricing. And then and then three, you know, there's also maybe another game where you can strategically play inclusion and exclusion. And we've actually published about this, right? But this is more relevant for for execution pre-con. So if you're interested in that, you can find it on EthResearch. Uh it's uh it's by Umberto who's a colleague of mine and maybe I just want to mention here this is a co-op with two other team members, Umberto and Benoit, who are uh A um very active um uh this type of of more quantitative research. Um Okay, really let's take it back, right? Either transactions will be sent to your turn out will be sent to a proxy or transaction pricing can be delegated to a third party. Um and then and then to kind of close the slide, I want to just yeah, like structure out these two optimization axes. Optimal transaction sourcing, what that would mean in practice, there may be something like a timing game, but in actuality we would argue that it's a reverse type timing game. And uh yeah, and uh And then there's a subgame where, you know, some transaction types you might want to strategically include or exclude, but I won't talk about this today. And then secondly, for pricing, yes, if there's no gateway design and the validator does pricing, then you need to have an in-house an in-house opinion on that, right? I think in general it's important to say that all of these things always exist on a risk-reverse axis. For example, even in normal PBS timing games, if you push them really far, what you do is you simply you simply delay into a flat curve and you're actually you're actually on a very bad point on the risk-reverse axis, right? So, I think it's important to always frame that in terms of expected returns. Okay, let's talk a little bit about optimal is sourcing transactions. Yeah, so this is a busy slide. Um therefore, I'll take it step by step. You'll see two two kind of axes of graphs here. There's two graphs at the top and then there's two graphs at the bottom. And I think the the way to read this best is the two graphs at the top correspond to the first large point on the slide and then the two graphs to the bottom correspond to the second large point on the slide. I will explain. Um I think the first thing to notice here to set up kind of the timing game is that gas use is dynamical, right? I mean, it varies a lot between blocks, but then it also varies a lot within blocks. And if you look at the the graph there at the top right, that's basically, you know, the gas per transaction distribution, and it's of course extremely skewed. And then if you look at the gas usage versus position, which is on the top left here, you will notice that, you know, like the the higher a transaction position is in the block, the more gas it consumes. Okay? So, that's let's just keep that in mind. The earlier transaction is in the block, the more gas it tends to consume with, you know, some edge cases around background specifically, and the gas per transaction is is distributed in a in a manner which is which is super skewed. Um and then I think and then the second information we need to set up our case here is that PBS timing games capture value by soliciting the block very late, right? So, you you send a get header request really late. You give the builder a lot of time to gather transactions to kind of combine them, right? For six decks arbitrage to come in. And this is this is what you see at the bottom here, right? This is the the way it works in in PBS. So, the the bottom the bottom left graph is the number of transactions, and you know, kind of when they come in. And I think here the point to take away is just the longer you wait, the more transactions are available, so the combinatorial space is higher. And then the the second the second graph at the bottom, which is on the right, is you know, like the longer you wait, the higher the the ratio of the bid to the max bid is, right? So, basically the way you would read this is simply the expected value of a block goes up over time. Okay? And now and now let's let's look at let's look at the game kind of that we can deduce from these two categories of information. Um So, conclusion one here is PBS timing games benefit from expected transaction gas use going up over slot time. And PBS timing games also profit from winning over transactions with Mayland in the next block, right? Now, for pre-confirmations, I would expect this to be to be quite different. And the reason for that is because the the premium that you're willing for to pay for a pre-confirmation, it corresponds to the service level you're getting, right? And let's say let's say you can land anywhere between, you know, like within a 12-second time frame. If you land it like 11 seconds, then you're getting a certain service level. But then if you land it 1 second to the next block, do you really need a pre-confirmation, right? So, there's definitely some like an effect here where instead of instead of the expected value going up over time, you know, it might go down over time simply because the service level that you provide where a pre-confirmation, this is earlier this is better the earlier in the block, right? You're just doing more. And and and what the and what this would mean to us is that the the pre-con- Okay, we can say the pre-confirmation inclusion premium scales with the expected wait time, right? And what this what this would mean to us is on the one hand, we would expect pre-confirmation value to cluster early. Okay? So, if you look at the PBS graph here, we wouldn't expect it to look like that for pre-confirmations. In actuality, the highest expected value per transaction, that would happen that would happen a lot earlier. And then and then you really probably wouldn't want to wait super long. Instead, what you want to do is you want to you want to wrap the pre-confirmation auction up, and you want to give the builder more optimization time. And then and then if you take it really practical, we think there's an optimal early end to the auction, that is, you know, that's a function of the the transaction arrival and distribution and and the and the price decay, right? And we we have some we have some very specific thoughts on this, but unfortunately, that there's no time, right? So, we'll need to dive into into the next game. And this is pricing and and optimal inclusion. So, previously I mentioned that either gateway can price it or you know, potentially a validator can price it, right? Um if you ask me for hypothesis, I would say it's probably more likely for the gateway to price it because I think node operators on the whole, as I mentioned earlier, are more set up to run good infrastructure, right? Pricing is not is not something that typically comes up. Um but yeah, that being said, let's go ahead and and sketch out sketch out a quick model, right? Um I think I think the the first thing to consider here is earlier I mentioned that the transaction, the gas usage of a transaction, that varies depending on where the transaction is in the block, okay? And and so and let's let's approach this heuristically and say there are kind of three tiers of transactions in the block, right? There's like tier one, which is super early, which is top of block, which is typically your sex decks arbitrage. There's tier two, which is kind of, you know, like mid block. And then there's tier three, which is anywhere else in the block, right? Can say like mid block to bottom of block. And and then and then okay, so we have this heuristic, is it valid? Well, we ran the statistics on it and and we, you know, like this is P value, which is which is pretty pretty small. If I if I read that out now, that would take the end of my presentation time. So, these tiers are not are not, you know, the same in terms of transaction usage, right? As I in terms of gas usage. So, it's a heuristic which is kind of, you know, like if you rigorously look at it from a statistical POV, it's fair. And then and then one conclusion we can draw from that is that validators compete for a tier two and tier three transactions because tier one transactions, they are just super tight to being at the top of the block, right? The sex decks arbitrage, you know, like there is no there's no really real discretion about maybe including in the the later point of time. It has to happen at that point of time because it is tied to a certain to a certain price delta between a centralized a centralized exchange and the DEX. Okay. Um yeah, uh that being said, uh again, takeaway one, there can be you know, we can separate all transactions in the block into three tiers in a statistically valid manner. Uh takeaway two, uh tier one transactions we are really aren't aren't you know, as as useful for our pricing model because we are talking about inclusion pre-confirmations which don't really touch contentious state in this way. Um that being said, let's let's sketch out the model, right? Um So, the first statement that we can make is well, what what do we need to build a model here, right? Can we even do that? Yeah, I think we can do it, right? Because inclusion pre-confirmations do not touch contentious state. Uh you can you can build a model uh solely on on on public flow. Okay, so the model can be built. That's premise A. Um two, um how how would the model look like if we if we if we dig in a little bit deeper? Well, okay, so we have a base component and we have a priority fee priority fee estimation. Um let's let's look at kind of some of the the attributes of these two, all right? Um the base fee is easier to estimate because it's discrete. And then the priority fee is a lot harder to estimate because it it is it is continuous, right? So, just there's a there's a much much larger space. Um the base fee we can generally frame as the the opportunity cost of pre-confirming transactions, right? Because if you if you do not pre-confirm a transaction, you can always get the future transaction which which you know, has a minimum incurred the base fee. And and then the priority fee can be seen as something that's more akin to like a premium, right? Which it is in actuality even in a spot market, the priority fee would basically correspond correspond to to a premium. Okay, so how can we schedule the toy model? Well, first of all, we need a way to forecast the base fee, which is which is, you know, like something that can be reasonably done. And then and then we we we finalize the distribution of the priority fee over tier two and tier three transactions because again, tier one transactions not as relevant for inclusion pre-confirmations. Um and then and then what what we think is a good first way of approaching it is you take the base fee, you take the base fee baseline, and then you add a percentile of the priority fee distribution as the pre-confirmation premium to it. And actually, which percentile you add to it, I think this is largely this is largely a function of you know, it can kind of you can see this a confidence interval of how well you understand transaction transaction pricing in the future slot. Right? Um I think this is a good way. It's a good way of approaching it. We hope to to publish a little bit more on it. Okay, I think for both the the last game with timing and for this, it's important to look at things empirically. For that reason, this is something that will mature over time, but in general, I think this is an approach that that is valid, you know, for either an old operator pre-confirmation protocol or whoever else is interested in that. Yeah, so I think I'm I think I'm ahead of time. Thanks for Thanks for attending and this is it. Yeah, thank you a lot. We have two questions. I will um give you a chance to choose which one you want to answer first. Sure, sure. So, I'll answer the question with with the one vote first. Between besides base roll-ups and MEV searchers, who else might be using pre-confirmations? Okay, let's let's take the taxonomy that I mentioned earlier in the presentation between inclusion and execution pre-confirmations. I think for inclusion pre-confirmations, like it's going to be two cases. One is based roll-ups, and then the the second case would be UX, right? Okay, so you can look at that and you can say, "Well, you know, waiting 12 seconds, is that really so bad?" But then if you frame it differently and you say, you know, speed that's comparable to Solana, then that actually that actually sounds a lot better, right? So for inclusion, I think it's UX, let's say wallets and based roll-ups. And then for execution pre-confirmations, I think that's kind of a searchers that come again, right? And and not only like atomic searchers, but then there's a point where it gets relevant for sex decks arbitrage as well. Um yeah. Thank you. Uh we still have a bit time. If you have any questions, we have microphones available. Okay, uh thank you. I think it was a very interesting talk. I also not a person