Introduction

Ethereum’s rollup-centric roadmap has spurred various L2 designs to scale the network. Two emerging paradigms are based rollups and booster rollups, which aim to maximize scalability while preserving Ethereum’s security and decentralization. This report dives into the technical architecture of each, compares their design goals and trade-offs, and examines their pros and cons in terms of decentralization, latency, censorship resistance, and capital efficiency. We also highlight Taiko’s recent preconfirmation implementation – a new feature to speed up based rollups – explaining how it works, the problems it solves, and its integration into rollup architecture. 

Based Rollups

A based rollup is an L2 that relies on Ethereum for transaction sequencing, using Ethereum validators as a decentralized sequencer set instead of a dedicated centralized one. Any L1 validator can sequence L2 transactions for a given block, eliminating the need for additional consensus layers, custom validator sets, or offchain infrastructure. This approach simplifies the architecture, reduces attack surfaces, and inherits Ethereum’s decentralization and permissionlessness. All L2 data is posted to L1, enabling trustless state reconstruction and censorship resistance. Even MEV flows naturally to Ethereum block builders, aligning incentives across layers and reinforcing the rollup’s integration with the broader Ethereum ecosystem.

Taiko is a leading implementation of a based rollup. As a Type-1 Ethereum-equivalent ZK-Rollup, it retains full EVM compatibility while leveraging Ethereum for sequencing. On Taiko’s Alethia chain, anyone can propose L2 blocks. These proposals compete for inclusion on L1, creating a fully permissionless and decentralized block production environment. However, this open competition leads to trade-offs. In early versions, blob utilization was low (~10%), and redundant submissions increased costs. Taiko initially subsidized proposers to maintain throughput, and is now launching preconfirmation mechanisms to reduce latency and improve UX (discussed later).

Advantages

• Maximal Ethereum-alignment: Inherits L1's decentralization, neutrality, security, and liveness.
• Simplified architecture: Reduced protocol complexity accelerates development.
• Synchronous composability: Enables atomic interactions between L1 and L2 within the same block (needs real-time proving).

Trade-offs

• L1-constrained performance: Throughput and latency are bounded by Ethereum’s block time (~12s).
• Redundant submissions: Decentralized competition can reduce data efficiency and increase costs.
• Higher proposer costs: PGA-like dynamics may lead to higher fees and lower margins for proposers.
• Harder UX features: Functions like soft confirmations or deterministic ordering require additional infrastructure.
• Lost fees: MEV is competed for at the Ethereum level, leaving less value capture for the based rollup. 

Gwyneth: Booster Rollups

The current L2 ecosystem is vast but also fragmented. Each rollup is like a silo, as apps deployed to one may not exist on another. User balances and smart wallets are isolated, and bridging between rollups is slow, costly, and often relies on centralized liquidity providers. Gwyneth aims to flip that model. Instead of launching empty rollups that developers have to redeploy on, a booster rollup comes pre-wired to mirror state from Ethereum L1 (or a parent chain), such as reading token balances, smart contract state, or wallet configurations directly, without needing to reimplement anything.

Gwyneth acts as execution (and storage) “shards” of Ethereum, expanding the network’s throughput without requiring new smart contract deployments. In this architecture, applications are deployed once on Ethereum L1 and are instantly available on all participating L2s, thanks to mirrored contract code and synchronized execution environments. Each booster rollup shares Ethereum’s base state and contract code, but maintains its own transaction history and local state. All contracts exist at the same addresses across L1 and L2s, enabling users to interact with applications from any L2 using the same Ethereum account. Booster rollups thus provide horizontal scalability, adding more L2s is akin to adding more CPU cores or servers, increasing aggregate throughput for the network.

To function, booster rollups require builders to support an additional XCALLOPTIONS precompile,  allowing L2 contracts to directly interact with L1 state but also with other L2s, allowing cross chain reads and writes. 

From a developer’s perspective, the benefits are substantial: a single deployment on Ethereum makes the application universally accessible across all booster L2s, eliminating the need for custom bridges or multi-chain codebases. For users, their Ethereum address remains constant across L1 and all booster rollups, enabling seamless access to funds and applications without switching networks. Booster rollups would unlock synchronous composability across shards, making it feasible to construct transactions that span multiple L2s and L1 in a single operation. Combined with based sequencing (known as Based Booster Rollups or BBRs), this design could enable synchronous, cross-rollup execution with the UX of a monolithic chain. The security model remains robust as each booster rollup posts data to L1 and uses either validity or fraud proofs. Because all contracts and assets originate from L1, there's no need for wrapped tokens or third-party bridges, reducing attack surfaces and increasing security through code and state uniformity. 

Furthermore, the L1 global state can become a bottleneck for non-parallelizable contracts, such as AMMs with centralized liquidity. Developers will need to architect their contracts with parallel execution in mind. Additionally, maintaining synchronization between L1 and multiple L2s increases node complexity and operational overhead. Atomic cross-rollup execution also depends on new coordination mechanisms at the L1 level, an area still under active research. 

As of mid-2025, no live network has fully implemented the booster rollup model, but projects like Taiko are building toward this vision. If successful, booster rollups could provide Ethereum with native, seamless scalability, without fragmenting liquidity, contracts, or users.

Preconfirmations

Yet despite the significant performance gains based booster rollups provide, latency remains a notable challenge for end-users and applications. In particular, the delay between submitting a transaction and receiving a confirmation from the current sequencer undermines the user experience, especially for latency-sensitive use cases such as decentralized finance, gaming, and trading. To address this, preconfirmations are designed to offer soft guarantees of transaction inclusion ahead of actual L1 confirmation. Effectively, this is an offchain signal indicating high confidence that a particular transaction will be included in an upcoming L1 block. These signals do not replace onchain confirmations but serve as a form of anticipatory commitment that enhances user trust and interaction speed. This innovation builds on Ethereum’s existing proposer-builder separation (PBS) architecture while preserving decentralization, trustlessness, and economic alignment among all network participants. There are two primary types of preconfirmations:

Inclusion Preconfirmations:

• Guarantees that the transaction will eventually be included in the 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:

• Provides a stronger guarantee and ensures a transaction’s exact execution ordering and state before L1 inclusion.
• 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.

The only based rollup with this enabled is Taiko, and we discuss their design (execution preconfirmations) in further detail below. It should be noted that the current release is whitelisted. The preconfer workflow unfolds through seven structured stages:

1. Registration

L1 validators volunteer to become preconfers by staking collateral and enrolling through the L1 contract. Notably, preconfirmations can work with **only one **validator, though more would be better. Luckily, Taiko has partnered with SSV (which contains 8-10% of all validators), so the preconfirmation service will be healthy at full launch. 

2. Election

One validator is selected as the preconfer for each slot. If the current slot proposer is a registered preconfer, they are selected. If not, a fallback preconfer is chosen, which can still submit proposals via the L1 mempool.

3. Request Submission

Users send transactions to the Taiko public mempool. Transactions with higher L2 priority fees are more likely to be preconfirmed, as the fee is rewarded to the preconfer.

4. Preconfirmation Publication

The elected preconfer assembles transactions from the L2 mempool into a block and broadcasts this block to the Taiko network, serving as the preconfirmation.

5. State Sync

Taiko full nodes validate the preconfirmation signature, execute the L2 transactions, and offer users access to the most recent preconfirmed state, without needing L1 confirmation.

6. L1 Inclusion

The preconfer is responsible for submitting preconfirmed L2 blocks to the L1 Taiko inbox contract. This can occur through MEV-Boost inclusion (if the preconfer is also the proposer) or via the L1 mempool.

7. Slashing (Very Rare Occurrence)

Preconfers who fail to uphold their responsibilities, such as omitting preconfirmed transactions or, risk being penalized through slashing.

Benefits

Unlike centralized sequencers, Taiko’s model avoids single points of failure by distributing the preconfirmation role across incentivized, permissionless actors (although the first iteration will be a whitelisted group in order to test and improve the implementation). Preconfirmation providers operate independently and compete to issue timely and accurate signals based on mempool observations and their understanding of likely block proposals.

Furthermore, the practical benefit of preconfirmations is improved latency from a user’s perspective. Rather than waiting for full L1 confirmation (which can take several Ethereum blocks), users can receive a soft signal within seconds that their transaction will be included. 

Cheaper transaction fees are a welcome sign for many users. Previously, proposers were competing to create blocks and submit to the L1. This meant they were posting often to avoid getting front-run (many times with blobs half empty) - this is wasteful and drives prices up for users. With preconfirmations, a proposer can be certain that they will be able to batch transactions for a certain number of slots, allowing them to aggregate more before submitting to the L1. Not to mention, better UX should increase activity, allowing costs to be spread among more transactions. As shown below, the data costs to Ethereum have already materially dropped.

Composability is also another big unlock. Under the current architecture, lack of coordination between L1 block proposers and L2 sequencers restricts atomic execution across layers, limiting both user experience and protocol composability. The introduction of opt-in L1 sequencing allows Ethereum validators to explicitly commit to sequencing both L1 and L2 transactions within a single block. This setup grants them control over both L1 and L2 block production within the same slot, unlocking synchronous composability between the layers (with real-time proving)

Conclusion

Taiko’s novel “Based Preconfirmation” model represents a meaningful leap forward in rollup architecture. While it does not increase throughput in terms of transactions per second (TPS), it substantially enhances transaction latency and user responsiveness by decoupling L2 transaction confirmation times from L1 block times. This is achieved without compromising on decentralization, a core design principle for the Ethereum ecosystem.

By reducing latency and improving transaction visibility onchain (reflected immediately on block explorers), Taiko enables rollup-based chains to compete more effectively with high-performance L2s, all while preserving Ethereum-aligned decentralization and neutrality. The protocol integrates preconfirmation logic natively, avoiding dependence on centralized off-chain actors such as reputation-based builders or multisig sequencers. From the user's perspective, the transition to Based Preconfirmation is frictionless. It operates out-of-the-box with common wallets and development environments (e.g., Rabby, Phantom, Hardhat) without requiring any additional configuration. The result is a faster and more seamless application experience, with improved responsiveness and no change in user behavior. 

While the rollout began in a more controlled (whitelisted) environment, this mirrors the iterative development pattern seen in many decentralized protocols. Similar to the previous Taiko launch, the team has demonstrated a clear roadmap to permissionless deployment, one they have executed on before and intend to follow again.

 

 

 

 

The information contained in this report and by Blockworks Inc. and related affiliates is for general informational purposes only and is not intended to provide legal, financial, or investment advice. The report should not be construed as an offer or solicitation to buy or sell any security, token, or financial instrument and does not represent any recommendation or endorsement of any investment or financial product or service. Blockworks Inc. and related affiliates are not registered as a securities broker-dealer or an investment advisor in any jurisdiction or country.