The Sequencer Problem: Why Bitcoin Rollups Have a Centralization Bottleneck

Every rollup needs someone to decide which transactions go first. That role belongs to the sequencer: the single node (or small set of nodes) responsible for ordering user transactions, assembling them into batches, and posting the results to the base layer. On Ethereum, the sequencer problem has been debated for years. On Bitcoin, it is arguably worse: the base layer lacks the programmability needed for the escape hatches that Ethereum rollups take for granted.

This article breaks down what sequencers do, how leading Bitcoin Layer 2 projects handle transaction ordering today, and why decentralizing this component is harder than it sounds.

What Does a Sequencer Actually Do?

A sequencer performs three jobs in a rollup architecture. First, it accepts incoming transactions from users and decides the order in which they execute. Second, it batches hundreds or thousands of ordered transactions into a single compressed payload. Third, it posts that payload, along with a state commitment (and optionally a validity proof or fraud proof commitment), to the settlement layer.

Batching is what makes rollups cheap: the fixed cost of an L1 transaction is amortized across every transaction in the batch. A single Bitcoin transaction carrying a compressed batch of 1,000 L2 transactions costs each user roughly 1/1,000th of the on-chain fee.

Why centralization is the default

Running a single sequencer is operationally simple. One node can provide near-instant soft confirmations (milliseconds of latency), straightforward fee accounting, and deterministic ordering. For a rollup team shipping a product, a centralized sequencer is the fastest path to mainnet: decentralization can come later.

The problem is that "later" rarely arrives. Sequencer fees and MEV revenue are the primary income source for most rollup operators. Decentralizing the sequencer means sharing or redistributing that revenue, creating a structural disincentive to follow through.

The trust you inherit: When you use a rollup with a centralized sequencer, you trust that single operator not to censor your transactions, not to front-run your trades, and not to go offline. These are the same trust assumptions Bitcoin was designed to eliminate.

The Three Risks of a Centralized Sequencer

Censorship

A sequencer that controls transaction ordering can selectively exclude specific users or transaction types. Under regulatory pressure, a sequencer operator could be compelled to block transactions involving sanctioned addresses, effectively turning an L2 into a permissioned system. Under frameworks like the U.S. Bank Secrecy Act, sequencer operators may face classification as money transmitters, creating compliance obligations that double as censorship vectors.

Liveness failure

If the single sequencer node goes offline due to a technical fault, legal action, or operational error, the entire rollup halts. No new transactions can be processed until the sequencer recovers. Most rollups mitigate this with forced inclusion mechanisms (escape hatches) that let users submit transactions directly to L1, but these fallbacks operate on a delay of hours to days, not the milliseconds users expect.

MEV extraction

The sequencer decides transaction order, which means it can insert, reorder, or exclude transactions to capture MEV. Front-running and sandwich attacks are the most common forms. Research published in early 2025 documented $5.27 million in cross-chain MEV profits over just two months, where actors used L1-emitted transaction data to sandwich L2 trades.

How Bitcoin L2s Handle Sequencing Today

The Bitcoin L2 ecosystem has taken divergent approaches to transaction ordering. Some projects run a single centralized sequencer. Others distribute the role across a validator set. None has fully solved the problem.

Citrea: centralized sequencer with decentralization on the roadmap

Citrea, the first ZK-rollup on Bitcoin (mainnet launched January 2026), currently relies on a single sequencer operated by the Citrea team. The sequencer receives transactions, provides soft confirmations, produces blocks, and submits ZK proofs to Bitcoin.

Sequencer decentralization is on Citrea's post-mainnet roadmap. The team has published research outlining the open questions: whether the sequencer set should be permissioned or permissionless, which consensus mechanism to use (candidates include CometBFT, HotStuff, and MonadBFT), and how to manage latency introduced by multi-node communication. The team has discussed a governance token as a potential mechanism for decentralized sequencer and prover selection. For now, users must trust the Citrea team to operate the sequencer honestly.

Botanix: BFT consensus with rotating proposers

Botanix takes a different approach by avoiding a single sequencer entirely. Its EVM-compatible L2 uses CometBFT (formerly Tendermint) for consensus, with round-robin proposer selection among Orchestrator nodes. Currently 16 Orchestrators participate, with Botanix Labs running one of them. Anyone can join by staking BTC.

The Spiderchain, Botanix's custody layer, adds an additional decentralization mechanism: with every Bitcoin block, a new multisig wallet is created and the Orchestrators who guard it are randomly selected. Orchestrators use FROST threshold signatures with distributed key generation, meaning no complete private key ever exists in one place.

Bitlayer: rotating PoS validators

Bitlayer uses a PoS validator set with rotating block production. Built as a fork of geth, Bitlayer's architecture distributes sequencing across stake-weighted validators rather than relying on a single operator. Block production rotates among validators, and any attempt to exclude valid transactions can be bypassed by the next validator in the rotation. The V2 architecture adds redundancy for batch submission: if one rollup operator fails to submit, others assume responsibility.

Merlin Chain: sequencer with oracle verification

Merlin Chain uses multiple sequencer nodes built on the Polygon CDK. Sequencers collect and batch-process transactions, generating compressed data and ZK state roots. These are then passed to a Decentralized Oracle Network (DON) that functions as a data availability committee. Oracle nodes confirm the data handling and upload it to Bitcoin via Taproot.

Access to the oracle network is permissionless through staking (BTC, MERL, or BRC-20 tokens), and users can challenge the validity of ZK proofs. If a challenge succeeds, the confirming oracle node is slashed. This distributes verification, but the initial sequencing step itself remains less clearly decentralized in practice.

Comparing Bitcoin L2 Sequencer Models

Lessons from Ethereum: Shared Sequencers

Ethereum's rollup ecosystem has been grappling with sequencer centralization for longer. Two notable approaches have emerged: shared sequencers and based rollups.

Espresso Systems: the surviving shared sequencer

Espresso builds a shared sequencer network that replaces individual rollup sequencers with a distributed validator set running the HotShot BFT consensus protocol. Espresso does not execute transactions or process state updates: it only establishes consensus on ordering and data availability. Multiple rollups can share the same ordering layer, enabling cross-rollup composability.

Espresso's Mainnet 1 launched in February 2026, publishing sequencing confirmations for chains including ApeChain and Celo, with integrations in progress for Arbitrum, Polygon, and Optimism. Current throughput exceeds 5 MB/s, with a planned upgrade to 25 MB/s. A fully permissionless mainnet is targeted for late 2026.

Astria: a cautionary tale

Not every shared sequencer project survives. Astria, a Celestia-based shared sequencer that raised $18 million, ceased all operations in December 2025. Block 15,360,577 was its last. The shutdown was attributed to limited adoption and development challenges, with the team having already shut down its Celestia validator months earlier.

Astria's failure illustrates a core bootstrapping problem: shared sequencers need rollups to adopt them, but rollups have little incentive to integrate an external dependency when their own centralized sequencer works fine and generates revenue.

Based rollups: sequencing by L1 validators

A based rollup delegates sequencing entirely to L1 validators. Proposed by Ethereum Foundation researcher Justin Drake in 2023, the concept lets the next L1 block proposer permissionlessly include the next rollup block. The rollup inherits the full decentralization and censorship resistance of the base layer.

The tradeoff is latency: a based rollup on Ethereum inherits Ethereum's ~12-second block time as its minimum confirmation time. Preconfirmations (where validators commit to including specific rollup transactions ahead of finalization) are being developed to address this.

Why based rollups are impractical on Bitcoin: Bitcoin lacks the programmability needed for L1-sequenced rollups. There is no smart contract layer for on-chain proof verification, no proposer-builder separation infrastructure, and no defined validator set that can make binding preconfirmation commitments. Bitcoin's anonymous proof-of-work miners cannot serve the same role as Ethereum's PoS validators. Adding the necessary opcodes would require a soft fork, which Bitcoin's conservative governance process makes extremely uncertain.

Ethereum vs Bitcoin: Sequencer Decentralization Compared

Why Sequencer Decentralization Is Harder Than It Sounds

Multiple technical and economic factors conspire to keep sequencers centralized.

The latency penalty

A single sequencer provides soft confirmations in milliseconds. Adding consensus among multiple nodes introduces communication overhead: message propagation, vote collection, and finalization rounds. Even optimized BFT protocols add hundreds of milliseconds. For DeFi trading, gaming, and high-frequency applications, this latency increase directly degrades user experience.

The revenue problem

Sequencer fees and MEV revenue fund rollup development. Decentralizing means redistributing that revenue across validators, reducing the rollup team's income. This creates a structural conflict of interest: the entity best positioned to decentralize the sequencer is the one with the most to lose from doing so.

Consensus complexity

Choosing a consensus protocol involves tradeoffs between fault tolerance, latency, and throughput. CometBFT (used by Botanix) provides instant finality but requires 2/3+ honest validators. HotShot (used by Espresso) optimizes for rollup-specific needs. Each choice introduces its own failure modes, attack surfaces, and operational overhead. For small teams building Bitcoin L2s, this complexity is a real barrier.

The honest majority assumption

Decentralized sequencer networks typically require a supermajority (2/3+) of validators to behave honestly. If this assumption fails, the network can lose liveness or, worse, allow invalid state transitions. Achieving a sufficiently large and diverse validator set takes time and genuine economic incentives. Sixteen Orchestrators (Botanix) or a handful of oracle nodes (Merlin) represent progress, but they are far from the thousands of validators that secure Ethereum's L1.

An Alternative: Avoiding the Sequencer Entirely

The sequencer problem is inherent to rollup architecture. But not every Bitcoin L2 is a rollup. Some designs avoid the sequencer role altogether by using fundamentally different mechanisms for transaction processing.

Spark, for example, uses a statechain model rather than a rollup. There is no sequencer ordering transactions into batches, because there are no batches: transfers happen by updating key ownership off-chain, not by executing transactions in a sequenced block. The Spark Entity comprises multiple independent operators using FROST threshold signatures, where no single operator possesses complete key material.

This architecture sidesteps the centralization bottleneck differently. Instead of asking "how do we decentralize the sequencer?" Spark asks "what if there is no sequencer to decentralize?" The tradeoff is a 1-of-n trust assumption during transfers (at least one operator must behave honestly), but this trust is moment-in-time: once a transfer completes and old keys are destroyed, operators cannot affect finalized transactions even if later compromised.

Rollups and statechains represent different points on the design space. Rollups offer smart contract programmability and EVM compatibility. Statechains offer simpler trust models and avoid sequencer-related risks entirely. The right choice depends on what you are building.

What to Watch

Sequencer decentralization across the Bitcoin L2 ecosystem will likely unfold gradually. Several developments are worth tracking.

• Citrea's decentralized sequencer network: the team has published preliminary research, but no timeline for deployment. The choice between permissioned and permissionless sequencer selection will shape the trust model significantly.
• Botanix's Orchestrator expansion: 16 nodes is a start, but the network needs growth to reach meaningful Byzantine fault tolerance. The Spiderchain's forward security properties are compelling if the validator set scales.
• Shared sequencer viability on Bitcoin: Espresso has gained traction on Ethereum, but no equivalent exists for Bitcoin rollups. Whether a shared sequencer can work without Bitcoin L1 smart contracts is an open question.
• Bitcoin soft fork proposals: opcodes like OP_CAT or hypothetical ZK verification opcodes could unlock new escape hatch designs, making forced inclusion mechanisms more practical for Bitcoin rollups.

Conclusion

The sequencer is the most centralized component in most rollup architectures, and Bitcoin's limited scripting language makes the standard mitigation strategies (forced inclusion, based sequencing) harder to implement than on Ethereum. Current Bitcoin L2s range from fully centralized single-operator sequencers to small BFT validator sets, but none has achieved the level of decentralization that Bitcoin's own L1 provides.

For developers evaluating Bitcoin L2s, the sequencer model should be a first-order consideration. Ask who operates the sequencer, what happens if it goes offline, and whether you can force-include a transaction without its cooperation. If you are building on a Bitcoin L2, the Spark developer documentation covers an alternative approach that avoids the sequencer bottleneck entirely. For a broader comparison of Bitcoin scaling approaches, see our Bitcoin Layer 2 comparison and L2 trust model analysis.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.