What Could Go Wrong?

A modular rethink of sequencing risks

Sequencers sit at the heart of almost every Layer 2 and blockchain rollup. They collect, order, and submit transactions from the L2 mempool, decide whether to execute or discard them, and broadcast the information to other nodes.¹ The transaction information then gets batched together, along with proofs, and sent to the base Layer 1 the L2 lives on. The sequencer is what effectively rolls up the transactions to support scaling blockchain networks. 

As is the case with every novel technology, though, sequencers have their own growing pains. Issues like bugs stalling transactions, censorship eroding user trust, and limited ability to scale slow them down. But sequencers are still an essential part of almost every Layer 2. 

So the question becomes: How do we design sequencers in order to minimize the potential setbacks? 

To answer that, we need to look at what might go wrong.  

Some of the risks we will look at have already appeared in the industry and are not limited to any single design. But this exploration isn't about pointing fingers. Instead, it's about stepping back to better understand the unique ways that sequencing architectures can fail in order to design new solutions. Ideally, in a way that lets developers choose how to manage and mitigate the risks most relevant to their needs. 

Risks

Sequencers are vulnerable to risks ranging from mild interruptions to existential threats from bugs. Below, we will cover a few of the ones we have noticed already popping up in many sequencer models, along with a few others that scare us the most. 

Fallback mechanisms

Every rollup design accounts for the possibility of sequencer outages. Fallback mechanisms, or “escape hatches,” are built to ensure users can still include transactions if the sequencer fails. On paper, these mechanisms look simple. In practice, they often fail when needed most.

For example, a rollup may offer a Layer 1 fallback that forcibly includes user transactions during a sequencer failure. In some designs, this only activates after a 24-hour delay or depends entirely on a small set of governance-approved proposers. In a crisis, transactions stall, markets move, and users cannot act until it is too late.

In centralized systems, governance teams may hold exclusive control and can be slow to respond or unreachable during emergencies. In decentralized systems, fallback access may be restricted by protocol keys, high costs, or strict timelocks. In both cases, users face the same problem: no way to act when immediate access matters most.

A slow or restricted fallback fails its purpose. These designs need to be built for urgent, reliable use, not as token safety measures.

Sequencer stalls

Moderate sequencing risks often start with small mistakes but have severe consequences. These risks include stalls caused by software bugs, depleted gas fee balances, or basic operational errors.

In one example, a rollup sequencer batches and posts transactions to Ethereum’s Layer 1 using a single wallet to pay gas fees. If the balance runs out, either from oversight or a sudden spike in gas prices, the sequencer stops, and transaction batches freeze indefinitely.

In centralized systems, this often comes down to manual wallet management and human error. Hours-long outages can occur if the operations team fails to top up the wallet on time. Automation and clear separation of duties can prevent this, but many monolithic designs do not include these safeguards.

Decentralized systems face the same risk in a different form. Multiple validators may share the responsibility of posting batches, but without clear incentives and coordination, no one may step in during a fee spike. The result is the same: stalled transaction processing.

These stalls delay transactions, freeze assets, and erode user trust. Some rollups reduce the impact with fallback logic. In the OP Stack, if a sequencer fails to submit batches within a fixed window, the system inserts an empty Layer 1 block. This triggers a one-block reorg that removes the stalled state and allows the chain to continue. The tradeoff is a brief rollback instead of a complete freeze.

Redundancy, automated economic management, and separation of operational duties turn catastrophic stalls into manageable incidents. Fallback mechanisms like OP Stack’s can limit downtime to a minor disruption.

Transaction censorship

A rollup sequencer with unilateral transaction-ordering power can censor activity without oversight or transparency. It can delay certain transactions indefinitely or discard them entirely. Censorship can result from compliance requirements, operator bias, or internal policy. Users may mistake repeated failures for normal congestion, unaware that the exclusions are deliberate.

In centralized systems, censorship can be explicit or implicit. Users must appeal directly to the operators, who may be slow to respond or unwilling to explain decisions.

Decentralized systems face similar risks. While explicit collusion is generally harder because it requires coordinating a threshold of participants, implicit censorship can still arise from shared incentives or operator overlap and is often more difficult to detect. Without built-in routing alternatives, users have few ways to bypass a censoring sequencer. Whether censorship is more or less likely depends on validator diversity and concentration, MEV dynamics, and whether users have alternate submission routes or forced-inclusion guarantees.

Censorship often appears as delays, missing transactions, or silence. Transparent inclusion rules and proactive monitoring are essential to detect and prevent it.

Emergency halts after hacks

A rollup sequencer suffers a severe security breach, compromising user funds. Operators respond with an emergency halt and block transactions from exploit-linked wallets. This can limit further damage, but also concentrates decision-making power.

In centralized systems, operators have direct control and can act quickly. The trade-off is reduced user autonomy and transparency, with users relying entirely on the operator’s judgment.

In decentralized systems, control is distributed, but governance processes can be slow, divided, or influenced by conflicting incentives. Coordination challenges can delay action and create inconsistent responses, making recovery harder.

In any model, a crisis places operator judgment under intense scrutiny. Users have little ability to bypass such halts. Clearly defined and transparent emergency governance policies are essential.

Silent bugs and accidental exclusion

A subtle software bug prevents certain users or addresses, potentially millions, from submitting transactions. The sequencer appears operational, and transactions seem normal, but a large group of users is quietly locked out.

Centralized sequencers are especially vulnerable to these silent failures because a single point of control magnifies the impact. Users often remain unaware until patterns of exclusion emerge, by which time trust may be irreparably damaged.

Decentralized designs can sometimes catch such bugs earlier through redundancy and validator oversight, but they are not immune. Added complexity creates more points of failure, communication challenges, and greater opacity, which can make silent exclusions harder to detect.

Operator trust depends on competence, oversight, and transparency. Users who cannot bypass a faulty sequencer remain exposed. Rigorous testing, clear monitoring, and transparent processes are essential.

Latency sinkholes

All rollups, whether centralized or decentralized, face latency tradeoffs. Users expect near-instant finality, but delivering it under load is challenging.

A single centralized sequencer node can handle transactions efficiently in normal conditions. However, when network activity spikes, from market volatility or a popular NFT mint, it can become a bottleneck. This causes delays, stalled transactions, and degraded performance because the sequencer cannot scale quickly enough.

Decentralized sequencing distributes transaction ordering across multiple nodes to reduce bottlenecks. Under heavy load, validator coordination, ordering agreements, and prover consensus add latency and communication overhead. In modular or highly composable decentralized designs, the complexity can grow further, leading to “cross-rollup clashes” where rollups compete for shared resources and slow each other down.

Every architecture trades between speed, cost, simplicity, fairness, and scalability. Defining and prioritizing these tradeoffs early is essential for delivering consistent, predictable performance.

Consensus stalls

Decentralization can increase resilience, but it also adds complexity that creates coordination risks.

In a consensus-based sequencing design, using protocols like Byzantine Fault Tolerance, Proof-of-Stake, or DAG-based models, multiple validators share responsibility for ordering transactions. This approach removes single points of failure but introduces new risks. Validators must maintain accurate, timely communication, which becomes difficult during network partitions, software bugs, or validator churn.

When validators disagree on the network state, they trigger view-change events or halts while reconciling differences. Even small issues, like latency, software incompatibility, or an overloaded network, can lead to prolonged stalls and delayed consensus. Transactions remain in limbo, frustrating users.

Centralized sequencing does not face this type of coordination failure because a single node makes all ordering decisions, but it is more exposed to downtime from outages or attacks, and users must trust the operator not to censor or delay transactions.

Decentralization improves trust minimization and resilience, but it increases complexity and potential downtime. Builders must choose the balance of uptime and trust minimization that best fits their network’s priorities.

Sequencer risks are a design choice

Sequencer failures have already occurred and, in some cases, caused major disruptions. They are directly linked to design decisions made early in a rollup’s architecture.

Centralized systems tend to fail in visible ways. A single node under stress becomes a bottleneck, and the system stops. The source of the problem is clear and easier to address. Decentralized systems can fail more quietly, often due to coordination issues or fragility at the network’s edges. These vulnerabilities are harder to detect and can cause widespread disruption before they are noticed.

Many rollups still adopt a default sequencer stack without evaluating whether it fits their needs. Sequencing has no universal blueprint. Each design carries different risks, and the right choice depends on the specific trade-offs a network is willing to accept.

Toward modular sequencing

Sequencing should be a framework, not a fixed black box. Developers should be able to configure their own:

• Fallback design for resilience during downtime.
• Ordering logic tailored to their transaction types and use cases.
• Economic guarantees that align incentives and protect network health.
• Decentralization thresholds that define how much trust and coordination is distributed.

The goal is to choose the risks a network is willing to accept and design around them. The right sequencer is the one that fits the network’s needs and trade-offs.

Modular, customizable sequencing will not remove all risks, but it allows more intentional designs that align with the diverse requirements of today’s decentralized ecosystems.

To ground this in practice, here’s a snapshot of how different networks are approaching sequencer risks today. Think of it as a menu of design choices, each with its own strengths and trade-offs, to help guide what might work best for you.

Each project will need to find the mix that fits its users, risk tolerance, and regulatory surface. Think of your configuration like a living threat model, one you revisit as conditions change.

We can keep arguing about the best sequencer. Or we can build sequencers that are the right fit for each network.

Make policy explicit. Make operations explicit. Make each piece replaceable.

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, infrastructure development, co-development and web3-enabled gaming.

Alongside its contributions to major ecosystems such as Ethereum, Polkadot, and Filecoin, ChainSafe creates solutions for developers and teams across web3. 

As part of its mission to build accessible and improved tooling for developers, ChainSafe embodies an open source and community-guided ethos to advance the future of the internet.

Website | Youtube | Twitter | Linkedin | GitHub