Based Rollups: L1 Sequencing Explained

Based rollups are a Layer 2 design that moves transaction sequencing back to the base blockchain. Instead of asking a dedicated operator or a sequencing committee to decide the order of every rollup transaction, the rollup lets Ethereum’s next proposer and block-building market include its next block. This can simplify the trust model and align the rollup with Ethereum, but it also gives up some control over latency, ordering, and sequencer revenue. This guide explains how based rollups work, where they fit among other sequencing models, and what developers should verify before treating a rollup as based.

What Are Based Rollups?

A based rollup, also called an L1-sequenced rollup, is a rollup whose transaction ordering is driven by the base Layer 1. The L1 proposer, working with searchers and block builders, can permissionlessly include the next rollup block in an L1 block. The definition comes from the Based Rollups research proposal, which distinguishes the design from rollups that operate a separate centralized or proof-of-stake sequencer.

The word based refers to the rollup being based on the sequencing of its underlying chain; it is not a claim that every project using the word “base” has this architecture. A normal rollup still executes transactions in its own environment and maintains its own state. What changes is the path by which an ordered batch is selected and made available for execution.

Ethereum’s scaling documentation describes the wider rollup pattern: transactions execute outside the main chain while data, commitments, and settlement use the base layer. Based sequencing changes one component of that pattern. It does not remove the need for an execution engine, a bridge, data availability, or a validity or fault-proof system.

The Problem Based Sequencing Solves

Most rollups begin with a single sequencer because it is operationally straightforward. The sequencer accepts transactions, orders them, produces an L2 block, and later publishes data or commitments to Ethereum. This makes confirmations fast, but it creates an important trust and availability dependency:

• The operator can temporarily censor transactions or reorder them.
• An outage can prevent normal inclusion even when Ethereum itself is healthy.
• The rollup needs a forced-inclusion or escape-hatch path for users who cannot reach the sequencer.
• A decentralized sequencer set needs its own consensus, membership, incentives, and failure handling.

These mechanisms can be engineered well, but each adds code and operational surface area. A centralized sequencer may also capture maximal extractable value (MEV) generated by ordering rollup transactions, while the base layer supplies much of the security and data availability that make the rollup useful.

Based sequencing addresses the specific sequencing dependency by reusing the L1’s proposer and builder infrastructure. A rollup does not need a separate sequencer signature scheme or a second consensus network to decide which candidate block is next. The trade-off is that the rollup must accept the base layer’s block time, inclusion rules, and ordering environment. Based sequencing is therefore a change in who controls ordering, not a universal solution to every rollup problem.

How Based Rollups Work

The core flow connects an L2 execution engine to Ethereum’s normal block-production pipeline:

1. Users submit L2 transactions. Wallets and applications send transactions to the rollup’s node or transaction ingress service.
2. The rollup forms a candidate block. The execution layer validates transactions and computes the next L2 state transition. Depending on the design, this candidate may be assembled by an L2 proposer or by infrastructure working with L1 builders.
3. An L1 builder includes the candidate. Searchers and builders can place the rollup block or its required data in a bundle for an Ethereum block.
4. The L1 proposer selects the block. The next Ethereum proposer chooses an L1 block that may contain the next rollup block. The L1 consensus process determines the resulting ordering.
5. The rollup derives and executes the result. Rollup nodes read the L1 record, derive the canonical sequence, and execute the included transactions.
6. Proof or challenge logic confirms correctness. A validity proof, fault-proof system, or other rollup settlement mechanism checks that the state transition follows the protocol rules.

Proposer-builder separation is important to this design. Early descriptions of L1 sequencing raised the possibility that several actors could submit competing rollup blocks at once. Modern builder workflows can coordinate candidate construction and inclusion so that the L1 block carries a single next rollup block rather than requiring an independent rollup consensus round for every attempt. The Ethereum Research explanation discusses this relationship and the resulting liveness and simplicity properties.

The sequence can be summarized as:

User transaction
      |
      v
Rollup execution -> candidate L2 block -> L1 builder bundle
                                             |
                                             v
                              Ethereum proposer includes it
                                             |
                                             v
                         L1 data -> canonical L2 derivation
                                             |
                                             v
                              proof or fault-proof settlement

The roles should not be conflated. The L1 proposer chooses an Ethereum block, the builder assembles a candidate block, and the rollup execution engine determines the state transition. Based sequencing makes the L1 responsible for the ordering path, but it does not make Ethereum execute every L2 instruction.

Comparing Sequencing Models

This comparison does not make one model universally better. A trading application may value fast preconfirmations and custom ordering, while a general-purpose rollup may prefer inherited liveness and a smaller trusted computing base.

Key Components and Design Choices

L1 proposer and builder path

The proposer and builder are the actors that turn transactions and rollup candidates into an Ethereum block. A based rollup needs a reliable way for builders to recognize, validate, and include the next rollup block. This can involve rollup-specific payload rules, contracts, or builder integrations. If the inclusion path is ambiguous, multiple candidates may compete or users may wait for a later L1 block.

Rollup derivation and execution

Rollup nodes must deterministically read L1 data and derive the same L2 chain. The derivation pipeline should reject malformed candidates and preserve the rollup’s transaction and state-transition rules. Sequencing on L1 does not replace the rollup’s execution client; it supplies the canonical input order that the client consumes.

Data availability

A rollup still needs users and nodes to obtain the transaction data required to reconstruct state. Ethereum’s blob mechanism provides a data-availability path for rollups, but blobs are not permanent general-purpose storage. EIP-4844 defines blob-carrying transactions and their fee market, which reduce the cost of publishing rollup data without changing the need for a correct derivation and retention strategy.

Proofs and settlement

Validity rollups submit cryptographic proofs that a state transition is correct. Optimistic rollups rely on a dispute process and fault proofs. In both cases, sequencing answers “which transactions came next?” while the settlement mechanism answers “was the resulting state transition valid?” Keeping those responsibilities separate helps avoid overstating what based sequencing guarantees.

Inclusion guarantees and preconfirmations

L1 inclusion is not identical to an instant user confirmation. A rollup may offer a soft preconfirmation before an Ethereum block includes the transaction, but that promise needs an explicit mechanism and security model. Without one, users should treat the L1 inclusion event and the rollup’s finality rules as separate milestones.

Real-World Uses and Trade-Offs

Based rollups are most useful when a protocol values inherited neutrality and liveness more than bespoke sequencing behavior. A rollup closely aligned with Ethereum can let L1 builders compete to include its activity, avoid issuing a sequencing token, and reduce the number of independent parties that must stay online.

The model is also attractive for composability. If related actions are included through the same L1 block-production environment, applications can reason about their relative position against L1 transactions and other rollup activity. This does not magically make cross-rollup transactions atomic, but it can reduce the isolation created by independent sequencer clocks and mempools.

There are meaningful costs:

• Less sequencing control: L1 block intervals and builder policies may not support application-specific first-come-first-served ordering.
• Potentially slower preconfirmations: A centralized sequencer can promise a local response quickly; an L1-driven design needs a safe way to promise anything before inclusion.
• MEV revenue moves away from the rollup: The base-layer builder and proposer market can capture value that a dedicated rollup sequencer might otherwise retain.
• L1 congestion matters: A rollup inherits the availability and inclusion conditions of its base layer.
• Integration still matters: The simpler consensus story does not eliminate bugs in bridges, derivation, proving, or execution.

The Taiko project homepage is a useful starting point for examining a real Ethereum-aligned rollup project, but a homepage is not enough to establish a protocol’s exact sequencing guarantees. Developers should read the project’s architecture and node documentation, inspect its contracts, and identify the fallback behavior before relying on the label “based.”

Getting Started: Inspecting the L1 Sequencing Path

There is no universal “enable based mode” command. The practical work is to verify how a particular rollup derives blocks from L1 data and how its contracts or documentation define inclusion. You can begin by inspecting recent Ethereum blocks through a JSON-RPC endpoint:

export ETH_RPC_URL="https://ethereum-rpc.publicnode.com"

curl -sS "$ETH_RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}' |
  jq '{number: .result.number, hash: .result.hash, timestamp: .result.timestamp, transaction_count: (.result.transactions | length)}'

This confirms that the endpoint is reachable and shows the L1 block that a rollup’s derivation process may be consuming. It does not prove that a rollup is based. For a real project, use its documented L1 contracts and node configuration to answer these questions:

1. Which L1 contract or event identifies an accepted rollup block?
2. How does a node choose the next L2 block when no candidate is included?
3. What is the forced-inclusion or censorship-resistance path?
4. Which data must remain available for independent derivation?
5. When does the rollup consider the block soft-confirmed, proven, and finalized?

For a local integration test, record an L1 block number, fetch the rollup’s derived block for that point, and compare the transaction ordering with the project’s derivation documentation. Repeat across an L1 reorganization simulation or a delayed-inclusion case if the client supports it. A successful RPC request is only an observation tool; correctness comes from the rollup’s node, contracts, and proof or fault-proof rules.

Common Misconceptions

“Based rollups execute everything on Ethereum”

They do not. The rollup still executes its own transactions and maintains an L2 state. Ethereum supplies the sequencing and settlement environment; it does not run every L2 instruction as a native L1 transaction.

“Based sequencing automatically makes a rollup trustless”

It removes or reduces a separate sequencing trust assumption, but security also depends on data availability, the bridge, the execution client, the proof or challenge system, and governance. A bug in any of those components can still threaten users.

“Based means faster in every way”

Based sequencing can improve liveness and simplify consensus, but a dedicated sequencer may provide faster local preconfirmations or custom ordering. The relevant question is which latency users receive, what backs that promise, and when the state becomes economically or cryptographically final.

Related Articles

• Sequencers: How Rollups Order Transactions and Shape Ethereum Scaling
• Shared Sequencers: How Cross-Rollup Ordering Layers Improve Modular Blockchains
• Optimistic vs Zero-Knowledge Rollups: Architecture Guide
• Proto-Danksharding and EIP-4844 Explained
• Layer 2 Scaling Solutions Explained