Preconfirmations emerge as a transformative concept within decentralized systems and can be considered a fast game to allow users to quantify and attain certainty against transaction execution risk in the context of mev. A fast game “can be played in the time between two blocks of a chain, for which the chain has no access by construction” (Barnabe, ethresear.ch). Preconfirmations, or preconfs, which we define in the next section, aim to reduce execution risk related to blockspace contention, transaction ordering, and differences in execution compared to other domains ranging from different blockchains to CeFi. Preconfs can be played as a fast game to serve as a proxy for cross-domain price equilibriums, to hedge against gas volatility as well as rights or locks towards a given transaction, state, block, or slot. While preconfs can also be used to power consumer experiences, the economically dominant use cases are likely to be trading related, arbitraging the price differences created by different execution profiles across domains. We focus on transaction preconfirmations in this document, which by nature are in near real-time.

We draw from supply chain and logistics and introduce the fulfillment and delivery terminology referring to the preparation of orders and packaging for fulfillment and taking custody of the package and transportation for delivery. A common example could be Amazon as the fulfiller of an order (e.g. a pack of gummies) and USPS can be the deliverer. Under a preconfirmation setting, the fulfiller can demonstrate the sophistication required to provide a preconfirmation, and a deliverer can ensure it gets confirmed on-chain according to the current network dynamics.

Building on some of PBS’ strengths, which introduced the separation of block proposal and builder roles, we position block builders as fulfillers of preconfs and proposers as deliverers. Relays may take on a spectrum of roles ranging from these duties on each end, which may have different requirements for the types of preconfs. By leveraging this paradigm we can continue to increase decentralization of the validator set with low compromise for solo stakers, while better equipped fulfillers, such as a block builder, can provide real-time preconfirmation commitments to transactors. Existing entities within Ethereum and some of the latest proposals in Ethereum Research follow this paradigm, and the introduction of domains such as mev-commit, where fast games can be played, represents a new frontier for the preconfirmation design space to bring it closer to Ethereum mainnet.

Fulfillment is the biggest piece of the puzzle, but it is a low signal on its own from a single node in a network compared to delivery. However, if a network is able to gather real-time commitments from a credible threshold of fulfillers, it can provide similar guarantees without the need for special delivery actors.

We point this out as a fulfiller “consortium” that can be achieved with commitment networks, which can be groups of block builders, rollups, relays, or sequencers that can provide a set of commitments to represent a credible threshold of the network up or down the mev pipeline.

Ultimately a delivery enforceable or at the very least compatible fulfillment protocol would be more desirable. With a stronger builder identity in the Ethereum protocol, which is out of protocol with PBS today, we will unlock a design space to have better enforcement guarantees. Alternatively, this can be achieved through out-of-protocol means such as validators using staking and restaking, AVS, and potentially sidecar software to enforce these rules upon relays they connect to. However, even specialized software at the validator level, which would take a very delivery-focused approach, will benefit from leveraging a free marketplace of fulfillers like block builders, who are already providing similar services.

We break down a definition of a preconfirmation in the following section, pose a series of observations, and consider potential issues as the ecosystem evolves.

What is a preconfirmation?

In the context of Ethereum and blockchains, a preconfirmation can be defined as:

A credible heads-up before a confirmation happens.

Let’s break this definition down:

1. How Credible?

   A credible heads-up for an order implies access to some capability of fulfillment or delivery. Let’s consider the real-world supply chain example from above; Amazon’s word of guarantee on an order is credible enough that when you place it and Amazon gives you an estimate, you don’t think too much about delivery. A host of events can happen during delivery, but the system ensures that orders are delivered correctly by delivering entities most of the time. Vertical integration is also being observed in this space, but the way it emerges may not be as relevant to blockchain systems since the real world has a physical supply related constraint model.

   Similarly, centralized payment networks such as Visa provide credible payment preconfirmations to consumers and settle them daily via wire transfers to merchant bank accounts, which are abstracted by intra-bank transfers that range to settle from daily to every few days in batches, which are abstracted by the entire industry through a series of money market funds, rolling bond renewals and rehypothecation. When it comes to payments, delivery relies on faulty systems with older technology, but the transaction experience is made seamless through applications whose commitments are credible through reputation or other centralized means.

   How can this analogy be ported to a decentralized setting? Trusted entities on the mev pipeline in Ethereum already present some of the characteristics for this, however even a top block builder doesn’t build at least more than half the blocks on Ethereum. Therefore, one must source preconfirmation guarantees from a network of actors, such as block builders in a decentralized setting, whose varying levels of credibility for preconfirmation commitments can be gathered to quantify execution risk.

   Notably, this model can extend beyond Ethereum to rollups and other chains as the ecosystem decentralizes. We dive into how this can also be combined with proposer commitments to reach the highest levels of credibility for the fulfillment and delivery of commitments in “The Confirmation” section below.

2. The Heads-Up

   The issued message that alerts or prepares the transaction has to be “timely.” In mev this can mean that it’s fast enough to closely mimic real-world price ticks, such that the information loss between the domain’s state update or preconf heads-up and a CeFi price tick is minimal. By convention, most blockchains can't meet this criteria, particularly ones with block times of 1s or above; if your goal is to reduce execution risk, taking another 1000ms of execution risk before reducing it is suboptimal. Under the fulfillment-delivery paradigm, a blockchain can enable fulfillers to provide a real-time heads-up while focusing on delivery.

   Actors in Ethereum aren’t currently incentivized to preconfirm transactions, and while a bid amount reflecting the demand and economics powering this service will be needed to entice a commitment, a time-related mechanism will be needed to incentivize timeliness otherwise, actors can wait until a slot’s end, and provide a JIT preconf to game the system. Actors’ incentives can be aligned by rewarding for providing preconfs that experience the least information decay, as this will pose economic gains for the bidder. Information decay should follow some level of economic decay to truly settle a price for a preconf bid, but there can be cases where order flow exclusivity or other financial mediums like auctions can be used to deliver a timely heads-up experiencing the least information decay.

   On Blobs

   The heads-up case is different for blob transactions introduced with EIP-4844 , where a combination of L1 inclusion as a proxy for state security and L1 price for inclusion as a proxy for transaction price on an L2 are at play. Rather than using timeliness as a parallel for information recency, L2s will use blob preconfirmation timeliness on L1 for security and cost control. We note that blob txs can also be for an NFT or other data blob, which may have time-related urgencies for inclusion information.

   Blob inclusion is ultimately dependent on the block builder under the Deneb scope of EIP-4844, where a blob preconfirmation can be fulfilled and delivered by a block builder under most cases due to the KZG proof payload nature of a blob transaction in EIP-4844 and the persistence of blobs outside the chain with an execution payload reference. This is an example where different actors become deliverers under emerging cases, stressing the importance of providing preconfirmations with decentralized systems like mev-commit that are agnostic to these cases. If the fulfillment-delivery bundling of blobs is changed in future releases, relays may take on some of the emerging roles and duties, with the potential of having a piece of the pie from the emerging economics. Validators trying to take on this role can create a large burden for themself due to blob size-related bandwidth issues on top of running software and increasing their costs.

   Nonetheless, we define the heads-up using timeliness as a measure to reflect information decay and note the differences between what that could mean for new types of transactions.

3. The Confirmation

   As the preconf is handled in real-time or on a layer that supports fast games, the fulfillment portion is done and it’s time for delivery. In Ethereum, the proposer monopoly deems proposers the ultimate deliverers of execution payloads today. For a mev-boost enabled proposer, one would need all block builders using relays connected to the proposer to provide a preconf commitment for fulfillment-only commitments to be sufficiently credible to soft enforce inclusion through mev-boost dynamics. While fulfiller commitments are a useful piece of information to quantify execution risk (e.g. block builder with 20% market share gave me a commitment), delivery can be ensured through a proposer commitment in the current Ethereum setting. This can be achieved through active approaches like sidecar software, which may tradeoff benefits for capable validator groups for centralization risks, or through passive means like staking, restaking, AVS or eventually something like PEPC.

   Delivery focused preconf systems will not only need to deal with changing settings under different chains, they will also lead to centralization as those with better latency (software+hardware+geolocation) will be able to provide it with the least amount of information (and thus economic) decay. Therefore it’s in a given decentralized system’s best interest to design base layer features and encourage abstraction gained by the fulfillment-delivery paradigm.

   As systems decentralize more with proposals for collaborative block building, multiplicity, and multi-slot architectures, delivery focused models will struggle or need to evolve to serve users’ needs. The fulfillment-delivery paradigm is future facing in that it creates a role agnostic model for preconf providers while the Ethereum protocol can focus on decentralization and security. This fulfillment-delivery paradigm can unlock a design space for Ethereum with longer block times, while open and out of protocol solutions entangled with Ethereum can supplement execution experience goals, leveraging minimum viable enshrinement as needed.

     For delivering a confirmation on other chains, many different settings will need to be      considered, including settings where the paradigm collapses to a set of centralized      entities for delivery like Solana, but also settings where the paradigm considers      meta environments like shared sequencers or multi chain builders like SUAVE. A      fulfillment-delivery focused paradigm can consider these domains’ own settings to      position specialized fulfillers to source delivery per each setting. These systems can      use an additional credible commitment network like mev-commit and provide      preconfirmations to their users that are delivered at the chain’s speed, but are      fulfilled in real time. Actors on these networks can provide execution services      outside of these networks or play fast games for their networks in real-time and      fulfill real-time preconfirmation bids. This creates a domain agnostic real-time      system for preconfirmations that is abstracted from delivery, as delivery can be      specific for each domain.

Application to emerging Ethereum Proposals

The execution tickets concept introduced by the Ethereum Foundation inherently leverages the fulfillment-delivery paradigm and notes this separation as a key design distinction. Holders of execution tickets will be able to provide more credible commitments for preconfirmations as they promise protocol supported delivery. The proposal’s split of the slot into a beacon round and execution round can provide hybrid preconfirmation ratios for fulfillers and deliverers. Beacon round commitments can be made by proposers or be outsourced to fulfillers, while execution round commitments can be seamlessly made by block builders, or combinations of these can be employed for mev actors using specialized software and new Ethereum client features. We observe this design to be highly compatible with fast game domains that holders of execution tickets are likely to engage in. We further note similar thinking has been proposed from researchers at the EF prior to execution tickets for how preconfirmations and other blockspace derivates can be achieved under PBS.

The based preconfirmations proposal for L2 transactions leverages this paradigm between the L2 sequencer and the L1 proposer, but can be improved by using a network like mev-commit to coordinate fulfillment by block builders and set proposers for delivery. We understand this proposal has particular considerations for based rollups and preconfirmations on domains like mev-commit would have to take on a more fluid definition for “based”, however this can be an opportunity to collaborate to find a minimum viable enshrinement method such that the Ethereum protocol can efficiently gain the benefits of the fulfillment-delivery paradigm and have a based rollup model that considers the cross-domain centralizing forces of mev.

We also consider Inclusion Lists to be an interesting topic when it comes to preconfs, as they can be leveraged to position validators to be fulfillers and deliverers of preconfs if there’s an active method to manage the list. While promising, more research is needed in this area to ensure ordering is efficient and reversion related issues do not proliferate in appending inclusion lists, areas we think fast games domains like mev-commit can prove useful.

Conclusion

All in all, we laid down a formal definition for a preconfirmation, outlined how they’re relevant in the context of decentralized systems and mev, and analyzed considerations to enable them efficiently under current settings. We hope to invite the community to consider this definition and the related considerations when thinking about preconfirmations, and encourage exploration of this paradigm to consider emerging roles and games for mev actors. We emphasize mev-commit’s real time commitment capabilities as a fast games network for Ethereum and similar domains that can enable actors to bid for and receive commitments for preconfirmations, and invite thinkers and builders to explore this frontier with us.