When Base's Sequencer Goes Down in 2026: What Happens to Your Money

Twenty-three minutes that looked exactly like a hack

I was halfway through a swap on Base when the wallet went quiet. The confirmation spinner never resolved, my balance stopped changing, and the block height in the corner of the screen froze dead. Within thirty seconds a group chat I am in lit up with "Base is down" and, inevitably, "exploit." My first instinct matched everyone else's: something is draining, get the funds out.

Nothing was draining. Twenty-three minutes later the sequencer came back, the frozen height resumed climbing, and my pending swap confirmed at the exact price I had signed. No reorg, no loss, no drama beyond an anxious half hour. That was the day I stopped treating a sequencing stall like a security incident.

Outages on single-sequencer rollups are rare, short, and almost always a pause in writing rather than a threat to what you own. But the symptoms are engineered to scare you: pending forever, strange errors, a balance that will not move. Start with what the network actually is, because the architecture explains everything downstream — the Base network explainer is the two-minute version, and this is the rest of it.

The sequencer is one machine, and that is the entire design

Every rollup needs something to order transactions and bundle them. On Base that job belongs to a single sequencer operated by Coinbase; on Arbitrum One it belongs to a single sequencer operated by Offchain Labs. The sequencer receives your signed transaction, decides its position in the queue, executes it, produces the next block, and periodically compresses the batch and posts it to Ethereum.

Two consequences fall straight out of that design. First, ordering is first-come, first-served: your transaction lands in the order the sequencer received it, not in an auction. Second, and more relevant to outages, there is no public memory pool. On Ethereum mainnet, pending transactions wait in a visible queue anyone can inspect. On Base there is nothing to inspect, because the queue lives inside one company's infrastructure. That is exactly why the classic mempool sandwich attack mostly does not apply here — and it is also why, when that one machine hiccups, the whole writing path stops at once. There is no backup sequencer quietly taking over. The chain has not died; the only entity permitted to add blocks simply stopped adding them.

Base mainnet is chain ID 8453 and uses ETH for gas, same as Arbitrum One at 42161. Both inherit the sequencing model, so both share the same style of failure — which is why the lessons here transfer directly between them.

The exact symptoms a Base stall produces

• Your wallet shows "internal JSON-RPC error," a generic unknown error, or a swap that never leaves the confirm screen.
• The transaction sits pending indefinitely while the explorer either has no record of it or marks it pending with a timestamp that stops advancing.
• Balances appear frozen — a transfer you sent never reduces your total, a deposit never raises it, because no new block exists in which the change could happen.
• The "last block" age on the explorer climbs into minutes and keeps going, updating once per reload and then stalling again.
• Bridges hang at "confirming," DEX quotes refuse to refresh, and mints simply do nothing.

Here is the trap: every bullet above is also what a broken RPC endpoint looks like. The difference is testable in about ten seconds. During a real outage the explorer's block height is frozen for everyone; during an RPC problem the chain advances normally and only your wallet is behind. Switching endpoints fixes the RPC case and changes nothing during an outage — the drill lives in the RPC troubleshooting guide. Reading a reverted transaction is a third, separate skill, covered in failed transactions on Base and Arbitrum.

There is one more distinction worth internalizing: a stalled transaction is not a failed one. During an outage your transaction is not reverting, it is waiting — it has no reason to fail, because it has not executed. It keeps its nonce and its place in the queue. A revert, by contrast, cost gas and moved nothing, and it produces a specific error you can look up. Keeping "waiting" and "failed" separate in your head is what stops an outage from snowballing into a pile of desperate resends.

The tell I trust most is the block timestamp. If the newest block on Basescan was mined ninety seconds ago and the next one never arrives, that is a chain-level stall, not your wallet being dramatic.

Why your funds are safe even when writes stop

This is the sentence to hold onto: an offline sequencer is a writer that stopped writing, not a vault that swung open. Your ETH and USDC on Base are not sitting "inside" the sequencer. They are held by the bridge contract and tracked in the rollup state, and the state that already exists is committed to Ethereum. When the sequencer pauses, that committed state does not change — it simply does not grow. Nobody can move, spend, or seize your assets during the stall, because moving assets requires precisely the block production that is currently unavailable.

Compare that to the thing people actually fear: a bridge exploit or a contract bug, where funds leave your address inside a normal, fully functioning block. An outage is the mirror image. The mechanism that could drain anything is the very mechanism that has stopped. There is a real trust question underneath all of this — you are relying on one operator to keep sequencing honestly, which is the same concern raised in the broader Layer 2 security risks overview. But that question is about censorship and liveness, not custody. A short stall does not hand your balance to anyone, and the safety assumptions worth comparing across rollup designs are unpacked in optimistic versus ZK rollups.

You can verify the safety claim yourself during the next stall. Open the bridge contract on Ethereum and check that the locked balance backing Base still matches what the rollup reports — nothing about a paused sequencer changes that number. What a pause removes is only the newest slice of history, the last block or three that never got produced, and those arrive the moment production resumes. There is no version of a sequencer outage in which the reserve is silently emptied, because emptying it would require a valid transaction, and a valid transaction needs a working sequencer to be ordered and included at all.

What still works while the chain is frozen

More than you would expect, if you stay read-only.

• The explorer keeps serving the last committed state. Balances, history, and every past transaction remain visible on Basescan — only the most recent block is missing.
• You can prepare and sign a transaction in advance; most wallets queue it and broadcast the instant the chain resumes.
• Deposits sent from Ethereum through the L1 bridge contract are processed in order and cannot be selectively skipped, so a deposit is the one write you can still initiate from outside the sequencer. Arbitrum offers a similar force-inclusion path through its L1 delayed inbox, though it can take roughly a day.
• Any withdrawal you had already proven on Ethereum can still be finalized there, because that step does not need the sequencer at all.

The one thing to resist is panic-resending. Hammering the same swap with a higher fee does nothing to a stalled sequencer, and once service returns you may end up with several copies of the same trade executing. If you have a genuinely stuck transaction, the correct move after service resumes is the retry logic in the cancel and speed-up guide, not a spray of duplicates fired into the blackout.

How long these stalls have actually lasted

Public postmortems across the single-sequencer chains tell a consistent story: short, bounded, and self-healing once a fix ships or load drops.

Treat those minutes as approximate — the shape is what matters. Outages on these chains have been measured in tens of minutes, not days, and I cannot recall a single one where a user lost principal because the sequencer went dark. When it returns, queued transactions replay and the chain catches up within a couple of blocks. If you are ever staring at a stall far longer than expected, the reliable signal is the operator's own status page, not a wallet error string.

It is worth separating an outage from a slowdown. A congested sequencer that is slow but still producing blocks is not the same as one that has stopped entirely, and the response differs: during congestion a higher fee can genuinely matter, because transactions are still being ordered; during a full stall no fee does anything at all. The explorer's block age tells you which world you are in within seconds, and that single number decides if you should wait, bump the fee, or simply walk away for ten minutes and come back.

Sequencing is going decentralized, and that changes the failure mode

The single sequencer is a phase, not the destination. Base has been explicit that its sequencer decentralizes over time, through ideas like based sequencing — where ordering rights rotate or get shared rather than belonging to one operator — and a shared Superchain sequencing layer. Arbitrum has its own decentralized-sequencer work in progress, plus BoLD, which widens who can post the L1 state that outages and disputes depend on. The direction of travel is a network of sequencers, not one, so a single failure stops being a full stop.

Even a decentralized set will not make stalls impossible — consensus itself can fail to make progress — but it removes the single point where one company's bug freezes everyone. Until then, the honest read on Base and Arbitrum is: fast, cheap, and robust to, but not immune from, momentary pauses. That trade-off is part of what makes them attractive to build on, and it is why teams building genuinely resilient systems bake in fallbacks instead of assuming a chain is always available. For where the next layer of that architecture is heading, the Layer 3 explainer picks up the thread.

The outage checklist I keep pinned

• Confirm it is an outage, not your RPC. Open the explorer; if the latest block age is climbing chain-wide, the chain is stalled. If only your wallet is stale, switch endpoints per the RPC guide.
• Do not resend or gas-bump. Your pending transaction will be handled when writing resumes. Duplicates are how people accidentally trade twice.
• Go read-only. Verify balances on the explorer, note the transaction hashes, and stop signing until block height moves again.
• If something is genuinely urgent, route around it. Move stablecoins over a bridge that is up, or use an L1 deposit, rather than waiting on a stalled sequencer. The Base-to-Arbitrum move is my usual escape when I cannot wait.
• Log the timestamp. If a transaction later fails or double-processes, that incident window is what support and postmortems reference.

A stalled sequencer is an inconvenience with a countdown, not an emergency with a thief. Watch the block height, keep your hands off the resend button, and the chain will do the rest the moment it wakes up.