Preconfirmation

What Is a Preconfirmation?

A preconfirmation is an early, binding commitment from a block proposer (or other authorized party) that a user's transaction will be included and optionally executed in a specific upcoming block. Instead of waiting 12 seconds for the next Ethereum slot or minutes for full finality, users receive a signed message within roughly 100 to 250 milliseconds confirming that their transaction will land on-chain as promised.

The concept addresses a fundamental tension in blockchain design. Ethereum's 12-second slot time provides strong consensus guarantees, but that latency creates a poor user experience for applications that need rapid feedback. Centralized sequencers on optimistic rollups and ZK rollups solve this by offering near-instant soft confirmations, but they introduce a single point of failure and trust dependency. Preconfirmations offer a middle path: near-instant assurance backed by cryptographic signatures and economic penalties, without sacrificing decentralization.

The term was formalized by Justin Drake of the Ethereum Foundation in November 2023, though the underlying idea of pre-block transaction commitments existed earlier in academic research and MEV supply chain discussions.

How It Works

A preconfirmation system follows a six-stage lifecycle: registration, election, request, response, fulfillment, and enforcement.

1. Registration: a validator or proposer deposits slashable collateral into a registry smart contract (such as the Universal Registry Contract) and opts into issuing preconfirmations
2. Election: the protocol identifies which proposer is next in the validator set schedule, since only the upcoming proposer has authority to guarantee inclusion in their block
3. Request: a user submits a preconf request containing their transaction data, a tip (fee), and desired guarantee type (inclusion or execution)
4. Response: the preconfer evaluates the request and returns a digitally signed preconfirmation message committing to include or execute the transaction
5. Fulfillment: when the preconfer's slot arrives, they include the preconfirmed transaction in the proposed block
6. Enforcement: if the preconfer fails to honor their commitment, their posted collateral is slashed according to the severity of the fault

Communication between user and preconfer happens via direct API calls (point-to-point), not through the gossip protocol. This enables latencies as low as 100 milliseconds.

Inclusion vs. Execution Preconfirmations

There are two types of preconfirmation, each with different strength of guarantee:

Inclusion preconfs are simpler because the proposer only promises the transaction will be in the block. The transaction could still revert. Execution preconfs are stronger: the proposer commits to a specific post-execution state, requiring them to simulate the transaction and account for ordering effects. This makes execution preconfs harder to issue at scale, since the proposer must process requests sequentially to avoid conflicting state commitments.

Interaction with Proposer-Builder Separation

Most Ethereum blocks today are built by specialized block builders under proposer-builder separation (PBS), not by the proposer directly. This creates a challenge: how does a proposer enforce preconf commitments when a builder constructs the block?

Several mechanisms address this. Inclusion lists (EIP-7547) let proposers mandate that certain transactions must appear in the block for it to be valid. The Constraints API extends the builder auction to express preconf constraints. And MEV-Boost-compatible sidecars like Commit-Boost allow validators to participate in preconf protocols without disrupting the existing block auction.

Based Preconfirmations

Based preconfirmations are a specific application of preconfs designed for based rollups: layer-2 networks that use Ethereum L1 validators for transaction sequencing rather than running their own centralized sequencer.

In a based rollup, L1 validators handle sequencing, which means the rollup inherits Ethereum's full security. The tradeoff is speed: transactions must wait for an L1 slot (12 seconds) before they are sequenced. Centralized sequencers on competing rollups offer sub-second soft confirmations, making based rollups appear slower despite their stronger trust model.

Based preconfirmations solve this by having L1 validators voluntarily opt into a preconf protocol. They post additional restaked collateral (via protocols like EigenLayer) and accept extra slashing conditions. In return, when they are the upcoming proposer, they can issue signed preconfs for rollup transactions, providing the same sub-second assurance that centralized sequencers offer.

This approach gives based rollups the best of both worlds: the economic security and censorship resistance of L1 sequencing, combined with the speed users expect from modern execution layers.

Enabling Infrastructure

Several infrastructure components support based preconfirmations:

• EIP-7917 (Deterministic Proposer Lookahead): ensures the upcoming proposer schedule is fully predictable so preconf requests can be routed to the correct validator
• EIP-7547 (Inclusion Lists): lets proposers force-include preconfirmed transactions even when block building is outsourced to builders
• Universal Registry Contract (URC): a minimal, governance-free smart contract that standardizes preconfer registration and collateral management across protocols
• Commit-Boost: an open-source validator sidecar (developed by 70+ teams) that standardizes how validators opt into preconf protocols while maintaining MEV-Boost compatibility

Use Cases

Fast Rollup Transactions

The primary use case is making based rollups competitive on user experience. Without preconfs, a based rollup transaction waits 12 seconds for the next L1 slot. With preconfs, users receive sub-second confirmation that their transaction will be included. Taiko, the first based rollup to deploy preconfirmations on Ethereum mainnet (August 2025), demonstrated roughly 2-second transaction latency in its initial rollout, with targets of sub-1 second in subsequent phases.

MEV Supply Chain Commitments

Searchers, builders, and validators in the MEV supply chain can use preconfirmations to make credible commitments about transaction ordering and inclusion. A builder might issue a preconf guaranteeing a searcher's bundle will be included if the builder wins the block auction, reducing uncertainty in MEV extraction strategies.

Cross-Chain Operations

Preconfirmations can accelerate cross-chain bridges and atomic swaps by providing early assurance that the source-chain transaction will be included. A bridge relayer receiving a preconf from the source chain's proposer can release funds on the destination chain earlier, reducing the wait time from minutes to seconds.

DeFi and Trading

Execution preconfs are valuable for DeFi operations where the execution outcome matters, not just inclusion. A trader receiving an execution preconf for a swap knows not only that the trade will be included but also the exact price they will receive, reducing slippage uncertainty.

Current State of Development

Preconfirmations are not yet part of the Ethereum core protocol. They operate as an out-of-protocol mechanism relying on voluntary validator opt-in, restaking for enforcement, and sidecar infrastructure. As of mid-2026, several projects are actively building and deploying preconf systems:

• Primev (mev-commit): live on Ethereum mainnet with over 18,000 preconfs settled and approximately 1% of Ethereum validators opted in
• Taiko: launched Phase 1 mainnet preconfirmations in August 2025 with a permissioned set of preconfers (Chainbound, Gattaca, Nethermind)
• Chainbound (Bolt): building permissionless proposer commitments compatible with PBS and MEV-Boost
• Puffer Finance (UniFi): preconf AVS backed by over 3 million ETH in restaked security via EigenLayer
• Espresso Systems: shared sequencer marketplace offering approximately 250ms sequencer-backed preconfirmations

For a broader view of how rollup scaling and sequencer design compare across approaches, see the rollup vs. state channel scaling tradeoffs and L2 sequencer decentralization research articles.

Risks and Considerations

Centralization Pressure

Issuing execution preconfirmations requires simulating transactions and managing state dependencies, which favors large, well-capitalized operators with sophisticated infrastructure. If only a few entities can profitably offer preconfs, the system could concentrate power among a small set of preconfers, undermining the decentralization that preconfs are designed to preserve.

Slashing and Liveness Risk

Preconfers post collateral that can be slashed for safety faults (publishing a block that contradicts a preconf) or liveness faults (missing their slot entirely). Validators who restake across multiple protocols face compounding slashing risk. A missed slot due to network issues or software bugs triggers penalties even though the fault was unintentional.

Economic Sustainability

Research suggests that splitting a single slot into multiple sub-slot auctions for preconfs can reduce expected proposer revenue by 50 to 74% compared to a standard MEV-Boost auction. Preconf tips must be high enough to compensate for this revenue reduction, or validators will not opt in. With only around 1% of validators currently participating, the market is still finding its equilibrium.

Fair Exchange Problem

Pure peer-to-peer fair exchange of preconf requests and responses is mathematically impossible without a trusted intermediary. In practice, preconf protocols rely on gateway services or trusted relays to mediate communication between users and preconfers, introducing additional trust assumptions.

No Protocol-Level Enforcement

Preconfirmations currently rely on smart contract-based slashing and economic incentives rather than consensus rules. If a preconfer breaks a commitment, the penalty is financial (collateral forfeiture), not protocol-enforced invalidity. A future Ethereum upgrade could enshrine preconf enforcement at the consensus layer, but no such proposal has been finalized.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.