Pre-confirmations

Pre-confirmations (pre-confs) are commitments — made by a sequencer, validator, or block proposer — guaranteeing that a transaction will be included in a future block and executed as specified. They give users near-instant feedback without waiting for full on-chain finality.

They don’t replace finality; they provide credible, fast soft-finality ahead of it.


The Finality Problem

Ethereum L1 finality takes ~13 minutes (two epochs). L2 rollups typically achieve sequencer confirmation in seconds but full L1 settlement in minutes to days.

For many applications, waiting even a few seconds for a sequencer confirmation feels slow compared to Web2:

  • Visa card transactions: <1 second perceived
  • CEX order fills: <100ms
  • Ethereum sequencer confirmation: 1–3 seconds
  • L1 finality: ~13 minutes

Pre-confs push the user experience closer to CEX speed while retaining decentralized infrastructure.


How Pre-Confirmations Work

  1. User submits transaction
  2. Sequencer or validator evaluates it — checks fee, validity, conflicting transactions
  3. Sequencer issues a signed commitment — “I will include this tx in block N at position X”
  4. User receives the commitment — near-instant response
  5. Block is built — the sequencer follows through; if not, they can be slashed

The commitment is only as trustworthy as the slashing condition backing it. That’s what separates pre-confs from raw sequencer promises.


Slashing and Credibility

For pre-confs to be credible, sequencers must have skin in the game:

  • Optimistic pre-confs: Trust the sequencer; disputes resolved after the fact
  • Preconf with restaking: Sequencers restake ETH via EigenLayer; breaking a pre-conf commitment → slashing
  • EspressoSystems, Bolt: Building restaking-backed pre-conf infrastructure

Without slashing, a pre-conf is just a “best effort” signal — useful but not credible.


Based Pre-confirmations

A specific design where L1 validators (not just L2 sequencers) issue pre-confs. This is part of the based rollup architecture where Ethereum validators sequence L2 transactions:

  1. The L1 block proposer who will propose the next block issues pre-confs for transactions they intend to include
  2. Users get guaranteed L1 inclusion at near-L1 speed
  3. Eliminates centralized sequencer reliance

This is being actively researched as part of Ethereum’s roadmap.


Use Cases

Use Case Why Pre-Confs Help
Trading / DEX Near-instant fill confirmation
Payments Real-time confirmation for merchants
Gaming Actions confirmed without lag
Intent settlement Solvers need fast confirmation their fill is accepted

Key Projects

  • Espresso Systems — Shared sequencing + pre-confirmation network
  • Bolt (Chainbound) — Pre-confirmation for Ethereum validators
  • Primev — MEV-aware block building with pre-conf infrastructure

Sources

  • Ethereum Research: “Based preconfirmations” by Justin Drake
  • EspressoSystems documentation
  • Bolt by Chainbound: preconf protocol specification