# Beyond Spot Transactions: Modeling Dynamic Preconfirmation Auctions **Published by:** [Primev](https://paragraph.com/@preconf/) **Published on:** 2024-04-16 **URL:** https://paragraph.com/@preconf/beyond-spot-transactions-modeling-dynamic-preconfirmation-auctions ## Content Abstract. We investigate a model for an auction for preconfirmations of Ethereum transactions, its relations to existing models modern and classical, and its implications for bidder and provider, in particular block builder, behaviour. TL;DR An Ethereum execution preconfirmation ("preconf") is an advance commitment to include a specified transaction list into a specified block. The mev-commit protocol and chain provides a new platform for peer-to-peer sales of preconfs through customisable private auctions. Block builders and other providers of execution services may wish to sell preconfs because they fetch a higher price than spot, or to solicit early bids that can be used to update forecasts. If selling preconfs increases block revenue, builders must do it to remain competitive in PBS auctions. The advance guarantee provided by a preconf is valuable to transactors who are more sensitive to fee or censorship risk than to execution outcome risk, especially over a short horizon. It may also be valuable to certain risk-neutral transactors pursuing a multi step strategy. Such buyers may be prepared to pay a preconf premium on top of what they would otherwise pay for blockspace at delivery time. To encourage early bids, users need to be convinced that they have some chance to get their bid accepted in a timely manner. The mev-commit protocol addresses this by incentivising early commitments via bids that decay over time. Providers can solicit earlier and higher bids by publicly committing to an auction mechanism to sell off some portion of their blockspace for preconfs. For example, committing to timely accept or reject messages encourages early bidding, while committing to a reservation fee can encourage higher bids. Providers who obtain early bids can also use the resulting price discovery to dynamically adjust their commitment parameters, potentially increasing revenue. In this article we extend the model of Roughgarden (2020) for EIP-1559 gas auctions to study a dynamic preconf auction based on the mev-commit protocol. Introduction Execution preconfirmations on Ethereum are a way of issuing an early promise to arrange for execution of specified transactions or bundles.¹ Such promises can be used to mitigate censorship and fee risk in an adversarial MEV environment. With the advent of smart contract chains focused on intents, execution, and block building, they can also be used as the basis for constructing more sophisticated blockspace products. Definition. A (single transaction/bundle, named block) Ethereum execution preconfirmation is a credible advance commitment to arrange for execution of a specified transaction or bundle in a specified block.² Mev-commit protocol is intended to support more general types of preconfirmations, but this article will focus on the single transaction or bundle, single block case, which for the rest of the article we call simply preconf. Preconfirmations on mev-commit protocol The mev-commit protocol comprises a network protocol and programmable blockchain supporting peer-to-peer sales of preconfirmations for Ethereum transactions, with slashing penalties for liveness and safety failures. Bidders establish direct connections to execution service providers and submit their transactions along with confidential bids for preconfirmation thereof. If a provider decides to accept a bid, they may respond directly with a cryptographic commitment that is then registered in a smart contract for later settlement or slashing. Bids can be accepted at any time before the target block, or simply ignored. Accepted bids settle at a fraction of the bid price that decays linearly as a function of the time delay between bid and accept messages. Settlement occurs after the target block time, regardless of when the bid was accepted. In terms of implementations, all participants run a mev-commit network node.³ Providers typically also run a consensus node for the target chain, or block builder if this role is separated from consensus, which they use to deliver on their commitments.⁴ The blockchain used for registering preconf commitments, slashing, and settlement is called mev-commit chain. At the time of writing, it is running as a POA (Clique) Ethereum testnet sidechain.⁵ Key observations From a theoretical perspective, the key new ingredient in preconf auctions as compared to spot is their dynamic nature: bids can be accepted at any time, and hence bidder and provider behaviour must be considered in the context of private valuations and strategies that evolve over time. The model. We begin by adapting the static Roughgarden (2020) model to the case of a single pay-as-bid preconf auction with a new preconf tip bid parameter. We find that the EIP-1559 bid can be bundled into the preconf tip, so the new model is isomorphic to the old one. If, as in op. cit., we assume that the base fee is known ahead of time, the bid space can be reduced to one dimension.⁶ We then discuss how to construct dynamic variants of the model, where bidders and provider must choose which time to submit their messages. With many types of strategy, the bidder will want to wait until the last moment before bidding to fix their transaction parameters before bidding, which makes the "single-mindedness" assumption less realistic in the dynamic setting. On the other side, providers may take actions multiple times, for example holding periodic auctions; among other things, this gives blockspace a dynamic withholding value that the provider must consider when setting up their auction. Instead of pay-as-bid, payments may be adjusted by a decreasing function of time between bid creation and acceptance. For simplicity, in this article we mostly confine ourselves to the case of trivial decay; however, nontrivial decay is expected to be used in deployments of mev-commit and this affects several conclusions: dimensional reduction of the bid space is no longer possible, bid timing optimisation is significantly complicated, and providers have the incentive to accept bids sooner rather than later. It is up to the provider to choose an auction decision rule to optimise their revenue (or other social objective such as OFAC compliance). Withholding value. The new salient feature of the static preconf model is that the provider's expected payoff for withholding blockspace is nonzero, since it can be reauctioned at a later time closer to the target block. Because preconf bids may be accepted at any time before the block is committed, with pay-as-bid payment rules the expected revenue of deferring and reauctioning later is always at least as much as the revenue from accepting a bid immediately.⁷ This means that a myopic provider would never accept preconf bids until the last moment unless they were otherwise committed to do so. This gives rise to a theoretical issue which we call the deferring problem: if bids are never accepted early, there is no incentive to bid for a preconf, and the preconf premium vanishes! The deferring problem does not arise in practice if would-be bidders believe that the provider will issue early "accept" messages under reasonable circumstances. The mev-commit protocol will address this by modifying the payment rules to include a penalty for deferring that increases linearly with time, known as bid decay. Mechanisms with commitment. A powerful way for a provider to solicit earlier (and in some cases, higher) bids is by making a public commitment — whether backed by smart contract or traditional trust-building — to auctioning off a fixed-size portion of the blockspace at time $$t$$ using a declared credible auction mechanism.⁸ For example, a provider could promise to auction 10% of the block's gas limit with a forward greedy preconf auction in the first 2 seconds of the interblock time. In the context of mev-commit, the mev-commit chain is a natural choice of domain for such smart contract commitments. As well as soliciting early bids, committing to mechanism parameters — for example, a reservation price — can increase auction revenue.⁹ Risk management. The main target customers for preconfirmations of blockspace are risk averse. More precisely, they are more sensitive to gas price and censorship risk than to execution outcome risk, the latter arising because the buyer must make an early commitment to transaction parameters. The preconf premium depends on how the market prices the tradeoff between these risks. Dynamic provider strategies. Apart from capturing risk premia, soliciting early bids holds another potential benefit for providers: they can use the information leaked by the bids of informed users to dynamically update their decision parameters for later preconfs with the same target block. For example, a high bid from a specialist MEV searcher may indicate an imminent fee surge to which the provider may respond by raising reservation fees. Static model To illustrate the basic structure of a preconf auction, we study a static model for a preconf auction held $$t$$ seconds in advance of the target block. Bids and mempools Roughgarden (2020) defines a transaction in terms of three parameters: the gas limit $$g$$, the bidder's private valuation $$v$$ for transaction inclusion, and the effective bid per unit gas $$f=f_\mathrm{eff}$$. In implementations, the bidder actually sets the max gas fee and the priority fee, and $$f$$ is computed from these and the base fee. Following Roughgarden, we assume the base fee is known ahead of time, so the bidder may deduce these parameters from knowledge of $$f$$. We enhance the model by adding a new parameter $$b$$, the preconf bid for the transaction as a whole. In implementations, this field goes into a mev-commit preconfirmation bid message that refers by content hash to the underlying EIP-1559 transaction. A mempool consists of a set $$ M_t = {(g_i,v_i,f_i,b_i)_{i\in I}}$$ of transactions indexed by some auxiliary set $$I$$. Decision problems Following Roughgarden, we assume for simplicity that bidders are single-minded, that is, each participating bidder is trying to secure inclusion of a single transaction or bundle. Both $$g$$ and $$v$$ are considered immutable preferences of the bidder, so their bidding action space consists only of setting $$f$$ and $$b$$. The payoff for execution of a winning bid $$(g,v,f,b)$$ is $$ v - (gf + b).$$ The aggregated fee $$gf+b$$ is the effective total fee paid for the transaction, including preconfirmation. Providers must implement their own decision rules $$\mathbf{x}(M)\subseteq I$$ for determining the set of accepted bids. This rule must satisfy the knapsack capacity constraint $$ g_{\mathbf{x}(M)} :=\sum_{i\in \mathbf{x}(M)} g_i \leq C$$ where $$C$$ is the block capacity. The payment rules are pay-your-bid for winning bidders; more precisely, $$g\cdot f_\mathrm{base}$$ goes to the burn address. $$g\cdot(f-f_\mathrm{base})$$ goes to the "fee recipient" target of the block. $$b$$ goes to the preconf provider. Normally, the preconf provider and the fee recipient are the same entity. The provider's immediate payoff for each auction is therefore $$ \sum_{i\in \mathbf{x}(M)} [b_i + g_i\cdot(f_i-f_\mathrm{base})].$$ The provider's task is to design an optimal mechanism so as to maximise this payoff. Example. (Forward greedy first price mechanism). The "standard" 2-parameter knapsack auction implemented as a default in Bitcoin and Ethereum node software is a forward greedy algorithm with capacity $$C$$ and reserve $$f_\mathrm{res}$$. In a spot auction, $$C=C_0$$ is the block size; in a preconf auction, $$C=C_{-t}\leq C_0$$ is the amount of blockspace the preconf provider allocates to preconfirmations at time $$-t$$. See below for some discussion of how reservation fees will be set in the dynamic context. Dimensional reduction of bid space Since bidders in this static model have only one parameter — their private valuation of inclusion — a winning bidder is indifferent to the breakdown of the transaction fee into its three components except inasmuch as it affects their chance of inclusion. When the preconf provider is also the fee recipient, they are also indifferent. Bidders may therefore make the substitution $$ (g,v,f,b) \mapsto (g,v,f_\mathrm{base},b+g\cdot (f-f_\mathrm{base})),$$ setting the priority fee to zero without affecting any payoffs. This leaves only one degree of freedom to bid with fixed $$g$$ and $$v$$. We find that our static model is trivially isomorphic to Roughgarden's model. In particular, the observations of op. cit. regarding the costliness of including "fake" transactions and OCA-proofness carry over to our setting without modification. Issues relating to ex post efficiency, bidder incentive compatibility, and credibility are isomorphic to the corresponding spot block builder auction. Dynamic models The dynamic rules of mev-commit preconf auctions are as follows: The mempool state is now a point process $${M_t}_{t\leq 0}$$ to which transactions are added as they arrive from bidders and are removed as the provider accepts bids. Bidders choose the time they issue their bid. They may choose their transaction parameters $$\theta$$ at that time. It may be unrealistic to assume that $$\theta$$ is fixed ahead of time. Bidders' expected valuation $$v_{t,\theta}$$ for the execution of a transaction with parameter $$\theta$$ evolves over time as a martingale process. Similarly, each bidder's model for the conditional distributions of the other bidders' types evolves over time. The provider may accept any subset $$\mathbf{x}_t(M_t)$$ of $$M_t$$ at a finite number of times $${t_1,\ldots,t_k}$$, removing those bids from the pool. The provider's payoff at delivery time is the sum of the fees received from each of these $$k$$ selections. The payment amount for an accepted bid $$m_i=(g_i,v_i,f_i,b_i,t_i)$$ may be a decreasing linear function $$\tilde b(\Delta t_i)$$ of the time $$ \Delta t_i=\inf{t|m_i\in\mathbf{x}_t(M_t)}-t_i$$ between bid and acceptance, normalised as $$\tilde{b}(\Delta t_i)=b_i$$. For simplicity, in this article we mostly treat the payment rule as if this function were constant, i.e. pay-as-bid. Bidders may also increment their bids at any time by submitting additional bid messages for the same transaction. The total payment on delivery is then the sum of all the accepted bids. Bid timing Suppose that the bid decay function $$\tilde b$$ is constant in time. Then a single-minded bidder gains the same ex-post payout $$v-(gf+b)$$ from execution of a given transaction, regardless of when the preconfirmation was accepted. Therefore, the expected payout $$\pi(b,t)(v-(gf+b))$$ depends on bid time only via the probability $$\pi(b,t) := \mathbb{P}\left[m_i\in\bigcup_{t>t_i}\mathbf{x}_t(M_t)\mid b=b_i,t=t_i\right]$$ of inclusion. A risk-neutral single-minded bidder will bid $$b$$ at time $$t<0$$ only if $$\frac{\partial}{\partial t}\pi(b,t)<0$$ for some $$t<0$$, that is, if the chances of winning with bid $$b$$ are decreasing as delivery time approaches. Roughly speaking, this means that the smallest bid needed to secure inclusion is increasing with time, that is, the preconf premium is negative. (In mev-commit protocol, bidders can only express a negative preconf premium by bidding below the market rate for priority fees.) If $$\tilde{b}$$ is strictly decreasing, the computation is more complex — the bidder gains more utility if the bid is accepted late, but it is also less likely to be accepted late than early if no new information reaches the provider. It's an open question whether risk-neutral bidders will sometimes bid early with a positive preconf premium in this setting. Provider withholding values The private value of the provider for withholding blockspace in a preconf auction at time $$t$$ is, roughly speaking, the expected revenue of selling that same blockspace in some later preconf auction or equivalent spot auction. Subtleties arise in making sense of this quantity because: Blockspace pricing is not generally uniform; Selling blockspace early reduces capacity in the spot auction, potentially leading to increased congestion and hence per-unit revenue for late-arriving transactions. To put it more precisely, let us suppose that the provider holds preconf auctions for a target block at fixed discrete intervals $$t_0,t_1,\ldots,t_k=0$$. Suppose also that the payment rule is constant over time. A risk neutral provider will not accept a basket of bids $$J\subseteq I$$ at time $$t_0$$ if the revenue $$b_J:=\sum_{j\in J}b_j$$ for accepting them is less than the change $$\delta_J$$ in the expected revenue of the time $$t_1$$ auction under the reduced block capacity $$C - \sum_{j\in J}g_j$$, given knowledge of the preconf mempool $$M_{t_0}$$. Now, since any bid $$(g,v,f,b)\in M_{t_0}$$ not accepted at time $$t_0$$ is still in the mempool and available to accept at time $$t_1$$, the expected revenue from leaving any subset $$J\subseteq M_{t_0}$$ of bids pending until the next stage is at least the revenue for accepting them. That is, $$b_J \leq \delta_J$$ always, and our provider will never accept any bids until the last auction $$t_k$$. We call this the deferring problem. The mev-commit protocol attempts to address the deferring problem by using a strictly decreasing bid decay function $$\tilde b$$. The decaying payment rule means that leaving bids pending leads to lower revenue, all other things being equal, so providers do have some incentive to issue early accept messages. Provider commitments The deferring problem can also be addressed by providers publishing public commitments to additional rules about how they will conduct the auction. For example here are two types of mechanisms: Committing to a particular auction format with reservation price protects bidders from ex-post increases in the provider's withholding value. Committing to timely issuance of credible "reject" messages gives bids a de facto expiry, eliminating the possibility of deferral. For rejection messages to be credible, the provider must be held accountable for equivocation, that is, issuing both accept and reject messages for the same bid. Commitment mechanisms can be naturally implemented as smart contracts on mev-commit chain, or more generally any low-latency blockchain endowed with an oracle yielding a commitment to the latest state of the target chain. Alternatively, providers can pursue traditional methods such as announcing their auction parameters on a website and establishing a reputation that makes such an announcement credible. Provider information As time progresses, the provider has an increasingly informative view of the cumulative preconf mempool $$\bigcup_{t