What happens to a transaction I've already submitted but hasn't been included in a Block yet, during a Sequencer outage?
A transaction in this "pending" state typically ends up in one of two ways: once the outage resolves and the Sequencer resumes normal operation, it continues processing according to its original logic, and your transaction gets included as normal; or, if the outage drags on too long, you could choose to submit your transaction into the system yourself via a force-inclusion mechanism, bypassing the failed sequencer to complete the transaction. Either way, whether your transaction ultimately succeeds depends on whether the transaction's own logic is valid (whether your account balance is sufficient, for instance), unrelated to the sequencer outage itself.
The more realistic risk is time cost — if your transaction involves something time-sensitive (Liquidation protection, a time-limited Arbitrage opportunity), the delay caused by an outage could make that opportunity disappear. That's an opportunity-cost loss, not an asset-theft loss.
Force inclusion sounds like a safety net — why don't all rollups just default to that channel and skip the Sequencer entirely?
Force inclusion is designed as a last resort, not a routine channel, mainly due to the substantial gap in performance and cost. Submitting a transaction through the Sequencer gets you instant soft confirmation at extremely low fees, since the sequencer handles a large amount of off-chain ordering and Batch Processing. Force inclusion, on the other hand, requires directly interacting with the main chain, effectively bypassing the core value proposition a Rollup exists to provide (moving transactions off-chain to lower costs) — making it slow and considerably more expensive.
If routine operations all went through force inclusion by default, that would mean giving up the performance advantage a rollup offers, which is why most rollups design force inclusion as an emergency exit for when the sequencer fails or misbehaves, not as a routine mechanism replacing the sequencer — its value lies in making sure this escape route genuinely exists and works, not in being expected to see everyday use.
What caused these three real outages, and can they be completely avoided going forward?
The direct causes of these incidents varied — a sudden traffic surge exceeding original capacity planning is one common trigger, and this kind of incident, to some extent, reflects a single-Sequencer architecture's capacity bottleneck under extreme load. Fully guaranteeing that this kind of incident never happens is difficult, because as long as infrastructure is run by a single entity, there's always some possibility of operational error, hardware failure, or insufficient capacity planning — which is also why shared sequencers and decentralized ordering mechanisms are viewed as the long-term structural solution, rather than something purely improved capacity planning for an existing Sequencer could resolve entirely.
For users, rather than expecting that "similar incidents won't happen again in the future," a more practical mindset is understanding that this kind of incident won't have zero probability for as long as a single-sequencer architecture exists — what matters is making sure you understand the actual risk to your assets when an incident occurs (as explained above, typically affecting liveness rather than asset security) and adjusting your usage habits accordingly, rather than mistakenly assuming that using a well-known Rollup means this kind of incident absolutely won't happen.
Beyond checking official announcements, is there any other way to catch a potential Sequencer problem early?
You can make good use of third-party monitoring tools, such as L2Beat, a platform dedicated to tracking Rollup risk and operational status, which typically shows each rollup's Sequencer status, whether decentralization mechanisms have been adopted, and historical incident records in near-real time. Some Block explorers also display the time interval between the latest blocks — if you notice this interval stretching abnormally long, that could be an early sign of a sequencer problem.
For users who heavily rely on a specific Rollup, subscribing to that project's official community channels (its official Discord, or its X account's announcement channel) is usually the fastest way to get firsthand incident information — most teams issue an announcement within minutes to tens of minutes of detecting a sequencer anomaly, letting you catch the situation earlier than passively waiting until your own operation fails to realize something's wrong.
If you're using a Rollup and run into a transaction stuck without moving, or an interface showing you can't submit anything, your first instinct might be panic — was this chain hacked? Are my assets still there? But breaking down several real Sequencer outage incidents shows that "transaction stuck" and "assets stolen" are two entirely different kinds of problems. Understanding this distinction can help you stay calmer and think more clearly the next time something like this happens.
Arbitrum's Sequencer got overwhelmed by a traffic surge in December 2023, triggering a multi-hour service outage; Linea suffered an outage in June 2024; Base also had a service disruption in February 2025. These three incidents happened on different rollups, at different times, with somewhat different causes — but they share one clear pattern: users couldn't submit new transactions during the outage, the interface got stuck, and the experience was significantly disrupted, but none of them resulted in stolen user assets, and none resulted in incorrectly altered on-chain state.
To understand why, you need to go back to the rollup architecture's core design: the sequencer is responsible for receiving transactions, deciding execution order, and providing instant soft confirmations — but determining what the correct asset state is after a transaction executes relies on an entirely separate mechanism. Optimistic rollups rely on fraud proofs plus a challenge window; ZK rollups rely on cryptographic validity proofs. Neither system is controlled by the sequencer, and anyone can independently verify them.
This means that even if the sequencer stops working entirely, or is even maliciously manipulated, the most it can do is refuse to process new transactions or process them in a dishonest order — but it cannot get a transaction that steals user assets past the verification system's check, because the verification system exists precisely to prevent that scenario, and it operates entirely independently of whether the sequencer itself is honest. In other words, a sequencer failure affects a chain's liveness (whether it can process new transactions normally), not its asset security (whether the already-recorded asset state can be tampered with).
This is another common worry: if the company operating a sequencer goes bankrupt or permanently ceases operations, would users' assets end up permanently locked? The answer depends on that Rollup's architecture, but most major rollups have some kind of "force inclusion" mechanism built in — even if the sequencer becomes completely non-functional, users can still directly interact with the main chain to force their withdrawal transaction into the system, bypassing the failed sequencer. This mechanism's existence is a concrete implementation of the design principle that "a rollup's security is inherited from the main chain": the sequencer is purely an efficiency-layer role, not the last line of defense for asset security.
This doesn't mean withdrawing through a force-inclusion mechanism feels as smooth as normal — this channel is typically slower and more complex to operate — but the important point is that this escape route genuinely exists; users aren't completely trapped with assets permanently unrecoverable.
Next time you're using a rollup and run into a stuck transaction or an abnormal interface, a more effective first step than panicking is to first confirm whether this is a sequencer-layer problem or a more fundamental protocol security problem — check official announcements, community discussions, or that rollup's real-time status on a third-party monitoring platform like L2Beat. In most cases, this kind of incident falls into the former category, meaning your assets themselves aren't at immediate risk, just temporarily unable to be operated on. If you handle larger amounts or are particularly sensitive to liveness disruptions in your use case, understanding ahead of time whether a given rollup has a force-inclusion mechanism, and how long it actually takes to work, is more helpful than trying to figure it out for the first time in the middle of an incident.