Preconfirmations

Preconfirmations, often shortened to preconfs, are commitments made by a party with influence over block production that a user's transaction will be included in a coming block, and sometimes that it will produce a specific result. The promise arrives within milliseconds, long before the block itself is finalised, so wallets and applications can show users a near-instant response instead of making them wait for the chain's normal block time.

The idea is discussed mainly in the Ethereum ecosystem, where blocks are produced every 12 seconds, and in rollup designs. Many layer 2 networks already give users quick "soft confirmations" from a central sequencer. Preconfirmation research aims to provide similar speed on the base layer and on based rollups, which hand transaction ordering to Ethereum's own block proposers, while making the promise enforceable through financial penalties.

Think of a busy restaurant where food comes out of the kitchen only every few minutes. A waiter takes an order and immediately says, "That's confirmed, it will be in the next batch." The diner does not have the meal yet, but can relax knowing it is coming. If the waiter breaks the promise, the restaurant pays a penalty.

A preconfirmation is that waiter's promise. The block, like the meal, still arrives on its usual schedule. What changes is how quickly the user knows their transaction is safely in the queue, and the fact that someone has money at stake if it is not.

1. Request. A user or application sends a transaction to a preconfirmation provider, often paying a small tip for the service.
2. Commitment. The provider, typically a block proposer or a delegate acting for one, signs a promise that the transaction will appear in a particular upcoming block.
3. Collateral. The provider has posted collateral, for example through restaking or a dedicated deposit, which can be taken away if the promise is broken.
4. Fulfilment. When the provider's turn comes, it includes the transaction as promised. Anyone can then check the block against the signed commitment and, if it was broken, submit proof to trigger the penalty.

Because a proposer only knows its turn a short time in advance, many designs rely on "gateways", specialised operators that issue preconfirmations on behalf of upcoming proposers and handle the technical work.

The process differs by setting. On Ethereum's base layer, the providers are validators who have opted in to a preconfirmation protocol, and the commitment must be honoured in their own block. On a based rollup, the same proposers also order the rollup's transactions, so one promise can cover activity on both layers. On rollups with their own sequencer, such as many optimistic rollups, the sequencer can issue preconfirmations directly, and the open question is mainly how to make those promises enforceable. In every case, the user experience depends on low network latency between the user, the provider and the rest of the network.

• Inclusion preconfirmations. A promise that the transaction will be included in a given block, without guaranteeing the exact outcome.
• Execution preconfirmations. A stronger promise that the transaction will run at a specific position or with a specific resulting state, such as an exact trade price. These are more useful for trading but harder to provide.

Slow confirmation is a recurring complaint about public blockchains, particularly for payments and trading. Centralised sequencers on rollups offer speed but concentrate power in one operator, and their soft confirmations are usually backed only by reputation. Preconfirmations try to combine speed with decentralisation by spreading the role across many proposers and attaching slashing penalties. They are also seen as a way to improve user experience on based rollups and to reduce some forms of front-running, since a transaction's place in the queue is locked in early. Related ideas existed earlier, such as accepting zero-confirmation transactions on Bitcoin for small payments, but those relied on trust rather than collateral.

Preconfirmations add complexity to block production and depend on proposers opting in. If only a small share of validators participate, preconfirmations may be available only some of the time. Concentrating the role in a few gateways could recreate the centralisation the approach aims to avoid. The size of the collateral limits how much a promise is worth: a provider could break a commitment if the profit from doing so exceeded the penalty, a concern linked to maximal extractable value. Network delays, chain reorganisations and software faults can also cause honest providers to miss commitments. Standards were still being developed as of November 2026, and different teams have proposed competing designs, so wallets and applications should explain to users what a preconfirmation does and does not guarantee, especially compared with full confirmations and finality.