One of Ethereum’s fundamental UX problems: even with L2 rollups, users often wait 2-5 seconds to see their transaction “confirmed,” and then potentially 7 days to fully exit back to Ethereum in optimistic rollups. Preconfirmations are the solution being developed for the base layer: validators commit, before producing a block, to include specific transactions in their next block. This commitment is cryptographically binding — the validator stakes something valuable on keeping their promise. If a transaction has a preconfirmation, the user can treat it as confirmed immediately, before the block is even proposed. The concept emerged from the “based rollup” and “proposer-builder separation” research ecosystem and is one of Ethereum’s most active areas of protocol development as of 2024-2025.
The Problem Preconfs Solve
Current user experience on Ethereum:
- User submits transaction
- Transaction sits in mempool for ~12 seconds (one slot) waiting for a validator to include it
- After 1 block: user sees transaction in a block (not fully finalized)
- After 2 more blocks (~24 seconds): high confidence transaction won’t be reorged
- After 64 blocks (~768 seconds / ~13 minutes): economic finality (very expensive to revert)
Current user experience on L2 rollups:
- Optimistic rollups: fast soft confirmation from centralized sequencer, but 7-day challenge period for full withdrawal
- ZK rollups: fast soft confirmation, 1-4 hours for ZK proof generation and Ethereum settlement
The preconf UX:
- User submits transaction
- A preconfirmer (validator or sequencer) commits: “I will include this tx in block N”
- User sees confirmation within 100-500ms
- Actual block produced includes the tx as promised
- If the preconfirmer failed to include it → they get slashed (lose staked ETH)
How Preconfirmations Work
The following sections cover this in detail.
The Commitment Mechanism
Proposer-based preconfs (Ethereum L1):
- An Ethereum validator who is about to be the next block proposer (known ~32 slots = ~6 minutes in advance via the beacon chain’s lookahead)
- Commits to a user: “I, validator X, commit to including your transaction in block N, signed by my validator key”
- The commitment is signed with the validator’s BLS key (same key used to sign blocks)
- If the validator then produces block N WITHOUT including the tx (or fails to produce the block at all), they can be slashed
Slashing conditions for broken preconfs:
- Two conflicting commitments (double commit)
- Failure to include a committed tx
- Must be enforced via a slashing mechanism — either in-protocol (requiring Ethereum EIP) or out-of-protocol (smart contract-based execution tickets)
Timing
The beacon chain’s lookahead means validators know far in advance when they’ll propose. A validator with a slot 2 minutes away can start accepting preconfirmations immediately, providing 2 minutes of runway.
Latency for user:
~100-500ms (time for commitment to be signed and returned) — effectively near-instant.
Based Rollups and Preconfs
“Based rollups” are a specific L2 design where the rollup uses Ethereum validators (not a dedicated sequencer) to sequence transactions — the rollup is “based” on Ethereum L1 sequencing:
Based rollup + preconfs:
- The L1 proposer for the upcoming slot becomes the based rollup’s sequencer
- The same L1 validator can offer preconfs for both L1 Ethereum transactions AND the based rollup’s transactions
- Single party provides unified preconf service for L1 + rollup
Key based rollup project: Taiko — positions itself as the first “based rollup,” using Ethereum proposers for sequencing.
Preconf Infrastructure Projects
Primev / mev-commit:
- mev-commit is a sidecar protocol where validators signal commitments to execute transactions
- Validators opt into a network and can offer binding “execution commitments”
- Validators who break commitments are penalized via a commitment tracking contract
Ethereum Attestation Service (EAS) + preconfs:
Some approaches use EAS to issue signed attestations as the commitment mechanism
Based Sequencing Research (Ethereum Foundation):
Justin Drake (EF researcher) is the most prominent advocate for based rollups + preconfs as the correct long-run Ethereum architecture.
Preconf Economics
Who wants to offer preconfs?
Validators can earn “preconf fees” — a premium paid by users or dApps for fast confirmation. If a user pays 0.01 ETH for a preconfirmation commitment, that’s validator revenue on top of base block rewards.
Who pays for preconfs?
- High-frequency traders who need confirmation of a buy/sell immediately
- DeFi protocols that want to guarantee state transitions in real-time
- Exchange withdrawals where users want instant confirmation
Market structure:
An emerging market where validators with upcoming slots auction preconfirmation capacity. Competitive dynamics similar to MEV auction but for confirmation rights rather than ordering.
Risks and Challenges
Equivocation risk:
A validator that provides preconfs could sell conflicting commitments (accept payment from two users for conflicting transactions). Slashing must be designed to make this unprofitable.
Reorg risk:
Even with preconfs, if the base chain reorgs (chain reorganization), the preconfirmed block may be replaced. This is a known risk that preconf designs must account for.
Censorship:
If a validator can preconfirm and then censor certain transactions, the mechanism could be used for targeted censorship of specific users.
Protocol complexity:
Adding preconf infrastructure requires either in-protocol changes (hard fork) or out-of-protocol credibility guarantees (smart contracts). In-protocol is cleaner but slower to implement.
Preconfs in the Ethereum Roadmap
Ethereum’s roadmap includes preconfs as part of the “Scourge” and later phases:
Ethereum roadmap relevance:
- Part of PBS (Proposer-Builder Separation) evolution
- Compatible with attester-proposer separation future
- Likely requires EIP for in-protocol slashing guarantees
- Justin Drake’s proposed “BRAID” mechanism integrates preconfs with based rollup sequencing
How Preconfs Affect Users
For most users, preconfs will work invisibly:
- Your wallet or dApp submits to a preconf-enabled infrastructure
- You see “confirmed” within ~500ms
- The actual on-chain transaction confirms in the background on its normal schedule
- If there was a preconf failure, the wallet retries automatically
Direct way to interact with preconf-enabled L1:
- Get ETH via
- Use wallets that integrate preconf providers (as they become available)
- Store ETH for Ethereum DeFi access:
Social Media Sentiment
Preconfirmations are among the most technically discussed topics in Ethereum research in 2024-2025. Justin Drake (EF) and the based rollup community are the primary proponents. The concept is well-received because it addresses a genuine UX problem (slow confirmation) without sacrificing Ethereum’s decentralization. Skeptics raise valid concerns about the complexity of slashing conditions, the possibility of validator collusion, and whether the economic incentives are sufficient to attract validator participation. The contrast with optimistic rollup centralized sequencers is often noted: current L2 “instant confirmations” are centralized promises with no slashing — preconfs would be cryptographically enforced promises with clear slashing conditions, a genuine improvement. Implementation timelines are uncertain; this remains primarily in research/prototype phase as of mid-2025.
Last updated: 2026-04
Related Terms
Sources
Drake, J. (2024). Based Preconfirmations. ethresear.ch.
Weintraub, B., Torres, C. F., Nita-Rotaru, C., & Gervais, A. (2022). A Flash(bot) in the Pan: Measuring Maximal Extractable Value in Private Pools. Proceedings of ACM IMC.
Buterin, V. (2021). PBS (Proposer-Builder Separation). ethresear.ch.
Wahrstätter, A., Ohlidat, J., Boros, A., Rath, A., Heimbach, L., Rennelmann, A., Kiayias, A., & Roscoe, W. A. (2023). Time Is Money: Strategic Timing Games in Proof-of-Work Protocols. Financial Cryptography and Data Security.
Roughgarden, T. (2021). Transaction Fee Mechanism Design. ACM SIGecom Exchanges.