Based Preconfirmations

Taiko Alethia is implementing based preconfirmations to enhance transaction finality, reducing the current 12-second block time to potentially sub-second finality. This significantly improves UX, particularly for applications requiring fast transaction execution. Based preconfirmations allow transactions to receive early inclusion guarantees from preconfirmers, providing users with immediate execution assurance.

What Are Based Preconfirmations?

A preconfirmation (preconf) is a cryptographic commitment from a preconfirmer that a transaction will be included in a block. A preconfirmer will sequence blocks offchain, and gossip them to other nodes, and the nodes will treat them as canonical blocks. At the end of their turn to preconf, they will propose them onchain to Layer 1, exactly as a typical non-preconfed block would be proposed.

To achieve this, there is a two-stage rollout of how this will operate.

Stage 1: Whitelisted Preconfirmers

• Our three partners Nethermind, Chainbound, and Gattaca will each run a preconfirmer using their own custom solution and be whitelisted in the protocol onchain. This provides us client diversity from day one. Each custom solution adheres to the onchain protocol and offchain spec, allowing us to focus on delivering fast, reliable preconfirmations.

Stage 2: Secured by Stake Preconfirmers

• L1 validators will opt in to being a preconfirmer, and either run their own preconfirmer, or delegate their preconfirming rights to a separate entity running one of the above solutions.

Rolling out in two distinct stages lets us not only test the software without potential bugs impacting validators, but lets us find the ideal configurable parameters, such as block time, that provide the ideal mix of profitability and user experience.

Execution vs. Inclusion Preconfirmations

There are two primary types of preconfirmations:

• Inclusion Preconfirmations:

  • Guarantees that the transaction will be eventually included in L1.
  • No strict guarantee on when it will execute or in what order.
  • Often used in systems that rely on external MEV solutions.

• Execution Preconfirmations:

  • Ensures a transaction’s exact execution ordering and state before L1 inclusion.
  • Provides a stronger guarantee for applications like DeFi, high-frequency trading, and gaming.
  • Transactions are executed immediately in L2 based on the preconfirmed state.

Execution preconfirmations remove uncertainty, making applications feel as responsive as centralized systems while preserving Ethereum’s security model.

Taiko’s Preconfirmation Implementation

Taiko’s partners have provided three independent preconfirmation solutions that all offer execution preconfirmations. The preconfirmation solutions run alongside a regular Taiko node as a sidecar: this means that the preconfirmers read transactions from the mempool, just like in Ethereum.

The End-User Experience

Our offchain spec is designed to be as invisible to the user as possible. That is to say, no changes are necessary at all for the user. This is done in the interest of making the user experience as smooth as possible.

The general flow will be as follows:

• The user sends a transaction to the same RPC they do now. The transaction enters the mempool, a preconfirmer fetches said transactions, and creates a block. They then gossip this block to the other nodes on the network, but do not propose it to the TaikoInbox contract on L1 yet.

Note

We term this “sequencing” - when a preconfirmer is creating and gossiping blocks but have not proposed on L1 yet. The user receives a transaction receipt, and all node states are updated when a block is sequenced. Blocks can be sequenced on top of other sequenced blocks.

With this design, a preconfirmer can sequence hundreds of blocks, before proposing them onchain in what we call a “batch”. Read more about batches here

• Each preconfirmer gets a 32 slot epoch in which to sequence and propose. It is up to the preconfirmer to determine when to propose their sequenced blocks on chain. This will be completely irrelevant to the end-user - they will have had their transaction receipt as soon as the block including their transaction is sequenced. Proposing onchain just confirms that sequenced state, allowing us to stay a based rollup.

• Block time on Taiko Alethia thus becomes configurable - if a preconfirmer chooses to set their target block time to 500ms, we could see 500-600ms transaction executions. However, if a preconfirmer determines that blocks made at this speed are not profitable to both propose onchain and prove, they can raise (or lower) the target block time.

This will create the best possible mix of profitability and user experience for L1 validators, preconfirmers, and users.

The Preconfirmer Experience

The preconfirmer’s process follows seven key steps:

1. Registration

   L1 validators opt-in to become preconfirmers by staking collateral and registering with the PreconfServiceManager contract.

2. Election

   A single preconfirmer is elected from the registered validators for each slot. If the current proposer is registered as a preconfirmer, they will be chosen. Otherwise, a fallback preconfirmer will be chosen, who can still submit their on-chain proposals via the L1 mempool.

3. Request Submission

   Users submit transactions to the Taiko public mempool. Transactions with higher L2 priority fees have a better chance of being preconfirmed, as the fee goes to the preconfirmer.

4. Preconfirmation Publication

   The elected preconfirmer collects transactions from the L2 mempool, builds an L2 block, and propagates this block to the Taiko network. This propagation serves as the preconfirmation.

5. State Sync

   Taiko full nodes verify the preconfirmed block’s signature, execute the L2 transactions, and provide users with the latest preconfirmed state without waiting for L1 inclusion.

6. L1 Inclusion

   The preconfirmer must submit preconfirmed L2 blocks to the L1 Taiko inbox contract. This is done either through forced inclusion lists in MEV-Boost (if the preconfirmer is the current slot’s proposer) or via the L1 mempool.

7. Slashing

   If a preconfirmer fails to honor their commitments—either by not including preconfirmed transactions or by submitting an incorrect lookahead—they face slashing penalties.

Benefits of Based Preconfirmations

• Faster Transaction Finality: Preconfirmations enable transactions to be confirmed as fast as the configured block time, which could be realistically between 500ms to 2 seconds, depending on the solution and configuration options.

• Stronger Economic Security: Preconfirmers stake collateralized ETH and face slashing penalties for dishonesty, reducing reliance on centralized sequencers while maintaining Ethereum’s security guarantees.

• Censorship Resistance & Trust-Minimization: Based preconfirmations leverage Ethereum validators to sequence transactions, ensuring decentralized sequencing with resistance to censorship by MEV players.

  • With the addition of the ForcedInclusionStore smart contract which allows users to submit transactions and force their inclusion irregardless of the preconfirmers, the protocol can remain censorship-resistant even while preconfirmers are permissioned (Stage 1).

Summary

Based preconfirmations enable much faster transaction finality by allowing Ethereum L1 validators to issue cryptographic guarantees on transaction inclusion and execution before block finalization. In our implementation, transactions are prioritized based on execution preconfirmations (strict order + execution guarantee). Preconfirmers stake collateral, ensuring economic security via forced inclusion and slashing penalties for misbehavior.