Core Definitions and Origins
Justin Drake defined based rollups as L1-sequenced designs in which the next Ethereum proposer can, together with searchers and builders, permissionlessly include the next rollup block inside the next L1 block. This approach delegates transaction ordering and inclusion directly to the base layer rather than to a dedicated sequencer controlled by the rollup team.
Optimistic rollups, by contrast, post compressed transaction batches to Ethereum and assume those batches are valid unless challenged. A fraud-proof window allows any participant to dispute an incorrect state transition; if the challenge succeeds, the batch is reverted and the operator is penalized. Both systems still require data availability on L1, typically through calldata or blobs.
Sequencing and validity verification remain separate design choices. A based rollup can adopt either fraud proofs or validity proofs. The “based” label refers solely to who orders transactions, leaving execution verification, data availability, and other parameters open to independent decisions.
Taiko’s implementation illustrates the model: L1 proposers interact with an Inbox contract, while forced-inclusion paths preserve the permissionless property even when faster preconfirmation routes are used. This separation of concerns allows based sequencing to coexist with either optimistic or zero-knowledge verification schemes.
How Sequencing Differs in Practice
Based rollups hand transaction sequencing directly to Ethereum L1 proposers and validators. The next L1 proposer can permissionlessly include the following rollup block as part of its own L1 block, working with searchers and builders through standard Ethereum consensus.
Optimistic rollups instead rely on a dedicated sequencer, usually run by the rollup operator, to order transactions and post compressed batches to L1. This centralised operator controls inclusion and ordering until a challenge period passes.
Taiko illustrates the based approach through its Inbox contract on L1. Normal operation routes proposals via a preconfirmation whitelist for speed, while forced-inclusion paths remain open to any L1 participant, preserving the permissionless property even if the whitelist is unavailable.
Preconfirmations on Taiko address the 12-second L1 block-time bound, delivering sub-second user experience while the forced-inclusion mechanism ensures the rollup stays based. Without preconfirmations, finality simply waits for the next L1 block.
The distinction therefore sits entirely in who decides order and inclusion: L1 consensus participants for based designs versus a single operator for conventional optimistic rollups.
Key Trade-offs Side-by-Side
| Aspect | Based Rollups | Optimistic Rollups (Centralized Sequencer) |
|---|---|---|
| Sequencing Control | Delegates to L1 proposers and validators via permissionless inclusion on Ethereum | Operated by dedicated rollup team sequencer |
| Confirmation Latency | Bounded by 12-second L1 block time without preconfirmations; preconfirmations enable sub-second UX | Typically faster due to centralized batching before L1 posting |
| MEV Routing | Routed to L1 validators for economic alignment | Captured at L2 level by the sequencer operator |
| Operator Revenue | Trade-off may reduce rollup operator revenue models | Retains MEV and sequencing fees at L2 |
| Liveness Guarantees | Preserves L1 liveness and neutrality with forced-inclusion fallback | Dependent on sequencer uptime; no direct L1 fallback for ordering |
Optimistic designs post compressed data as calldata or blobs and rely on a seven-day challenge window in standard implementations, delivering 10-100x scalability over mainnet. Based sequencing remains independent of fraud or validity proofs, as seen in Taiko’s Unzen architecture with preconfirmation whitelisting. The shift of MEV to L1 validators strengthens neutrality but requires preconfirmation stacks to match centralized UX, creating ongoing design tension between alignment and performance.
Current Implementations and 2026 Developments
Taiko runs as a based rollup on Ethereum under its Shasta/Unzen architecture. Proposers interact with an Inbox contract on L1, where normal proposals use a preconfirmation whitelist while forced inclusions supply a permissionless fallback that keeps the design based. Transaction ordering stays with the proposer, yet inclusion follows Ethereum consensus. The Unzen rollout pairs preconfirmation whitelisting for speed with the forced-inclusion path, addressing the 12-second L1 block-time bound noted in Taiko documentation as of September 2026.
Base announced in February 2026 that it will move away from the OP Stack. The plan centers on a unified, Base-operated client with a planned hardfork that adds Fusaka support and replaces optimistic proofs with Base-specific TEE/ZK proofs while remaining a Stage 1 rollup. Wavect’s September 2, 2026 review confirms that based sequencing implementations such as Taiko are already in production, with preconfirmation stacks mitigating latency while preserving L1 liveness advantages over centralized sequencers.
Latency, MEV, and Scalability Implications
Based rollups tie final transaction confirmations to Ethereum’s 12-second L1 block time when preconfirmations are absent. This creates a hard latency floor that centralized sequencers in optimistic rollups avoid, forcing based designs to rely on additional preconfirmation stacks for sub-second user experience.
Competing L1 proposers can also drive gas competition when multiple parties attempt to include the same rollup block, raising the risk of wasted fees on the base layer. Taiko documentation highlights this inefficiency as a direct consequence of permissionless inclusion rights.
MEV flows differ sharply. Based sequencing routes MEV to L1 validators and builders, aligning economic incentives with Ethereum but reducing revenue available to the rollup operator. Optimistic rollups with dedicated sequencers instead capture MEV at the L2 level, preserving that value for the rollup team while introducing centralization trade-offs.
Optimistic designs still deliver the 10-100x scalability gains over mainnet through off-chain execution and data compression, regardless of sequencing model. Based rollups inherit these execution benefits yet must manage the added overhead of L1 sequencing and potential gas contention, which can limit effective throughput under sustained load.
Preconfirmation layers mitigate latency without sacrificing L1 liveness, but they add operational complexity that teams must weigh against the neutrality advantages of based sequencing.
FAQ
How do preconfirmations change the user experience on based rollups?
Without preconfirmations, based rollups like Taiko tie final confirmation to the 12-second Ethereum L1 block time. Preconfirmations from a whitelist of proposers deliver faster feedback while the permissionless forced-inclusion path remains available as a fallback.
Do based rollups still support fraud proofs?
Yes. Based sequencing only changes who orders blocks; it works with either fraud proofs or validity proofs. A based rollup can therefore remain optimistic in its verification layer.
What are forced inclusions and why do they matter?
Forced inclusions let any user submit a transaction directly to the L1 Inbox contract when the preconfirmation whitelist is unavailable. This mechanism preserves the permissionless, L1-sequenced property even if the fast path stalls.
Can a based rollup capture MEV the way centralized-sequencer optimistic rollups do?
No. Based designs route MEV to L1 validators and builders. The rollup itself forgoes this revenue stream in exchange for stronger economic alignment with Ethereum.
Are preconfirmation whitelists a centralization risk?
They introduce a temporary permissioned fast path, yet the forced-inclusion fallback keeps the system based. If the whitelist fails, users can still post transactions permissionlessly on L1.
How does latency compare when preconfirmations are unavailable?
Confirmations fall back to the full L1 block interval of 12 seconds, which some analyses note can produce gas competition among proposers and slower UX than centralized sequencers.
Can existing optimistic rollups adopt based sequencing later?
The sequencing choice is independent of the proof system, so an optimistic rollup could transition to based sequencing without changing its fraud-proof mechanism.