---
layout: default
title: Preconfirmations
---

Preconfirmations
---

Preconfirmations are a proposed mechanism for providing assurance of inclusion and post-execution state for users submitting transactions to blockchains. Since blockchain users are contending for scarce blockspace in a permissionless manner, there is no fundamental guarantee that their transaction wil be included within a desired time interval, or with a specific post-execution state.

## The Setting

When a user submits a transaction to Ethereum, they have an expectation that there will be an interval of time before they can be sure that the transaction has been included in the blockchain.

Beyond inclusion, there is the notion of finalization, which is the point at which the transaction is considered irreversible. In Ethereum, this is considered to occur after 2 epochs, where each epoch contains 32 slots of 12 seconds each.

So from a user's perspective, a transaction goes through the following stages of certainty:

graph LR
    A[Submission] --> B[Inclusion]
    B --> C[Finalization]

## Fast, credible promises

Preconfirmations insert a new stage to this progression of confidence, between submission and inclusion.

It does this by enabling parties involved in the transaction lifecyle to provide a stake-backed promise that the transaction will be included within a stupulated time. We will get to who these parties are, both on the supply/submission and demand/preconfirmation side in due course.

So from a user's perspective, a transaction now goes through the following stages:

graph LR
    A[Submission] --> B[Preconfirmation]
    B --> C[Inclusion]
    C --> D[Finalization]

    style B stroke-width:3px,stroke:#ff0000

These preconfirmations can be provided with very low latency, depending on the specific design of the preconfirmation supply chain.

## Preconfers : Who confirms the preconfirmations?

There are many parties who are involved in the flow of a transaction from submission to finalization, including actors in the [MEV supply chain](https://blog.hack.vc/content/images/2024/03/Screenshot-2024-03-06-at-9.29.39-AM.png), who account for [up to 90% of all Ethereum transactions](https://www.theblock.co/data/on-chain-metrics/ethereum/percentage-of-blocks-proposed-by-mev-boost-relay). A high level view of the MEV supply chain is shown below:

(Use the arrows to move through the transaction flow)

<iframe src="https://ramshreyas.github.io/Possible-Futures/viewer.html?data=graphs/mev.json" width="100%" height="700px" frameborder="0" allowfullscreen></iframe>

The parties providing the preconfirmations will henceforth be called **preconfers**. Conceptually, any proposer (or a gateway acting on behalf of the proposer) who has the monopoly on the next slot can provide preconfirmations, and any parties who submit transactions for inclusion in this supply chain may seek preconfirmations.

So, for example, demand for preconfimations can come from private orderflow representing wallet apps, trading firms or other sophisticated participants such as searchers in the MEV pipeline.

**What if the Preconfer misbehaves?**

While the designs vary, the general idea is that the preconfer provides a slashable guarantee of the inclusion of the transaction and/or the post-execution state to the user. If this does not occur, for example if they miss their slot, the proposer's stake can be slashed. The exact slashing mechanism depends on the specific design, but one example could be Eigenlayer-style restaking.

<iframe src="https://ramshreyas.github.io/Possible-Futures/viewer.html?data=graphs/preconfirmations.json" width="100%" height="700px" frameborder="0" allowfullscreen></iframe>

---

## Some Preconfirmation designs

As discused above, any proposer (or gateway) with a monopoly on the next slot can sell preconfirmations to users. There are multiple possible approaches in this design space. In this report we will focus on the common themes emerging rather than the specifics of the many proposals in place.

*Also, considering that Ethereum is in the midst of a significant shift to a rolup-centric roadmap, with [rollup activity increasing dramatically](https://l2beat.com/scaling/activity), most of these designs are intended for rollup transactions also.*

### Independent preconfirmation network/chain

Any party in the transaction pipeline (builders, validators, etc) can run nodes on a fast p2p network such as [mev-commit](https://docs.primev.xyz/concepts/what-is-mev-commit) to enable fast, realtime negotiations between the users and preconfers to get preconfirmations with specific constraints (top-of-block, transaction ordering, etc). If preconfirmations are provided but not honoured, the collateral posted by the preconfer can be slashed. A more detailed description of the primev approach can be seen [here](https://docs.primev.xyz/concepts/rewards-and-slashing).

### Shared sequencers (L2)

In this design space, [(based) rollups](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016), validiums and other entities that use Ethereum for settlement share a common (usually decentralized) sequencer to include, order and propose rollup blocks. [Based Espresso: ad-hoc shared sequencing for all L2s, from based rollups to validiums](/kkVJEfd0THeMYhSD1no0Eg) is an example of this. The decentralized sequencer is a subset of L1 validators who offer re-staking style slashable guarantees to users in return for tips for a range of intents, including cross-rollup intents such as bridging of funds. The L1 validator who has the monopoly on the next block can essentially submit the blobs for all the rollups ensuring that the preconfirmations they have provided are met.

## Other pre-inclusion mechanisms

There are other proposals which are similar in nature to preconfirmations, but complementary, or indeed, orthogonal to them.

### Inclusion Lists

In Ethereum, a psuedo-randomly selected validator has the monopoly on the next block. In addition, many of these validators are also consumers of the [MEV-boost](https://github.com/flashbots/mev-boost) ecosystem, which is able to offer higher-value blocks to proposers aggregated from an increasingly centralized set of block builders. This represents a censorship risk, as the builders have the power to decide which transactions get included. A proposed solution is [Inclusion Lists](https://eips.ethereum.org/EIPS/eip-7547) (ILs), whereby the current block proposer is able to create a 'forward' list of transactions that have to be included in the next block. This introduces a new, [free data availability problem](https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389) which has some proposed solutions and is outside the scope of this report.

Since the proposer of the n^th^ block in this paradigm has a monopoly on an inclusion list for the n+1^th^ block, they now have the ability to specify constraints which can be satisfied in the next block. They include a list of these transactions and a signed summary along with their block proposal. The N+1^th^ block proposer now includes these transaction, and a signed summary. The N+1^th^ attesters confirm the inclusion of these transactions, and validate the block.

<iframe src="https://ramshreyas.github.io/Possible-Futures/viewer.html?data=graphs/IL.json" width="100%" height="400px" frameborder="0" allowfullscreen></iframe>

**Execution Tickets**

Execution tickets were first formally introduced as [Attester-Proposer-Separation](https://www.youtube.com/watch?v=IrJz4GZW-VM). The goal was to avoid the centralization of the entities proposing blocks, which is becoming more and more resource-intensive as the block proposer has to not only include all the transactions for the [beacon chain](https://ethereum.org/en/roadmap/beacon-chain/), but also run all the transactions and produce the post execution state. This favors sophisticated actors with greater resources who can play [timing games](https://ethresear.ch/t/timing-games-implications-and-possible-mitigations/17612), capture greater amounts of MEV, and therefore their share of the total stake incomparison to entities like home-stakers.

To mitigate this, the [execution tickets proposal](https://ethresear.ch/t/execution-tickets/17944):

1. Splits the tasks of transaction ordering and transaction execution into two separate processes
2. The existing beacon chain mechanism (to select the next block validator) would not contain the execution payload, but only have a list of transactions to be included, under the existing Proof-of-Stake system.
3. A new lottery would be introduced for execution block proposers and attestors. The winner wins the 'execution ticket' and gets to propose the block, which the comittee of attesters attests, similar to the current system.
4. Block proposers directly buy 'tickets' for this lottery for each slot from the protocol, unlike the beacon chain validators, whose stake is a permanent ticket for the beacon chain lottery. The ticket fee is burned, which directly transfers the MEV share to all ETH hodlers.
5. The slot is thus split into two rounds, the beacon round and the execution round

<iframe src="https://ramshreyas.github.io/Possible-Futures/viewer.html?data=graphs/ET.json" width="100%" height="600px" frameborder="0" allowfullscreen></iframe>

Execution tickets are in fact orthogonal to inclusion lists and while seperate from preconfirmations, enable some similar characteristics. They are intended to be a mechanism to reduce the computational load on the Beacon chain so that more decentralized participation can become possible. This means more sophisticated payload proposers will handle the execution (as shown in the diagram above), and can make strong guarantees on post-execution state.

---

## Conclusion

Multiple approaches for providing preconfirmations are already emerging, much like the emergence of solutions across the MEV landscape. The results of these experiments will no doubt greatly impact future L1 protocol changes, if any.

Therefore, preconfirmations appear to be inevitable, though [negative externalities](https://ethresear.ch/t/strawmanning-based-preconfirmations/19695) such as the centralization vectors in MEV will have to be carefully avoided by the ecosystem.

The research and development currently underway and the solutions that are emerging will probably unfold rapidly, much like the MEV space. Demand for preconfirmations is likely to be high, since it opens up the design space for many latency-sensitive usecases.

Also, if [(based) preconfirmations can be provided at ~100-second latency](https://ethresear.ch/t/based-preconfirmations/17353), this makes [based rollups](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) more competitive with centralized (or otherwise faster) rollup designs. Ultimately, preconfirmations represent a promising way to improve the Ethereum user experience across L1s and L2s.

---