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 implementation is achieved through cryptographic commitments from preconfers, secured by stake to encourage commitment fulfillment. This significantly improves UX, particularly for applications requiring fast transaction execution. Based preconfirmations allow users to receive a commitment of early inclusion from preconfers, providing users with a certain degree of assurance of immediate execution.

What Are Based Preconfirmations?

A preconfirmation (preconf) is a cryptographic commitment from a preconfer that a transaction will be included in a block. A preconfer 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 Preconfers

• Our three partners Nethermind, Chainbound, and Gattaca will each run a preconfer 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 Preconfers

• L1 validators will opt in to being a preconfer, and either run their own preconfer, 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 preconfers 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 preconfer 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 preconfer 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 preconfer can sequence hundreds of blocks, before proposing them onchain in what we call a “batch”. Read more about batches here

• Each preconfer gets a 32 slot epoch in which to sequence and propose. It is up to the preconfer 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 preconfer chooses to set their target block time to 500ms, we could see 500-600ms transaction executions. However, if a preconfer 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, preconfers, and users.

The Preconfer Experience

The preconfer’s process follows seven key steps:

1. Registration

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

2. Election

   A single preconfer is elected from the registered validators for each slot. If the current proposer is registered as a preconfer, they will be chosen. Otherwise, a fallback preconfer 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 preconfer.

4. Preconfirmation Publication

   The elected preconfer 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 preconfer must submit preconfirmed L2 blocks to the L1 Taiko inbox contract. This is done either through forced inclusion lists in MEV-Boost (if the preconfer is the current slot’s proposer) or via the L1 mempool.

7. Slashing

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

Note

Although slashing penalties will motivate a preconfer to honour its commitments, the user does not receive a share of the penalty to compensate for the failed inclusion.

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: Preconfers 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 preconfers, the protocol can remain censorship-resistant even while preconfers are permissioned (Stage 1).

Summary

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