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.

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.

     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.

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.

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.

     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.