Move Tokens Before a Sequencer Outage: Plan the Exit

Move tokens off a rollup before its sequencer goes down if you need them available on another chain or in a wallet you control there. A sequencer orders ordinary transactions, so an outage can stall swaps, withdrawals and bridge deposits that depend on it. The fallback depends on the chain: some rollups provide a route through their parent chain, but it can involve a wait, extra gas and more steps than a normal transaction.

That makes preparation a matter of choosing the right destination and route while the chain is working. Across’s documentation describes one alternative to waiting for a canonical bridge: relayers can fill a cross-chain transfer on the destination chain using their own funds, then seek repayment through settlement. For a plain-language explanation of what AcrossBridge does in transfers, see this overview. A relayer may speed up the destination credit, but it does not remove the need to submit the initial transaction on the source chain.

What does a sequencer outage stop?

A sequencer outage usually stops the normal path for submitting transactions to that rollup; it does not by itself mean that the chain’s parent layer has also stopped. The sequencer orders transactions and sends batches onward, while the rollup’s contracts and other nodes provide the underlying record and execution rules. Users should check the specific chain’s documented fallback rather than assume that an outage has one universal remedy.

Arbitrum’s documentation offers a concrete example. A user can send a message through the parent chain’s Delayed Inbox; the sequencer may include it when operating, or anyone may force inclusion after the applicable window. That route can carry a signed transaction, including a call to withdraw ETH. On Arbitrum One and Nova, the documented maximum window is 7,200 Ethereum blocks, while a delay buffer can shorten it under some conditions. The deadline is block-based and can change, so the documentation advises checking the current deadline before attempting force inclusion.

This fallback is a liveness path, not a fast exit. It requires a parent-chain transaction, sufficient gas, and patience; a forced message can also affect soft-confirmed blocks that were not yet posted to the parent chain. The details differ across networks. Treat any claim that a chain has “forced transactions” as a prompt to find its own instructions, eligible message types, timing and restrictions—not as assurance that every token transfer or application action is available during an outage.

Which route should you prepare?

For most people, the better preparation is to move only the funds they expect to need soon, using a route they have already checked. A direct, canonical withdrawal follows the rollup’s native exit process and is easier to reason about, but may require waiting for its security and finalization steps. A liquidity-based bridge can deliver funds on the destination chain sooner when a relayer fills the transfer, though fees, supported assets and route availability matter.

These routes solve different problems. A canonical withdrawal prioritizes the protocol’s native exit mechanism, while an intent-based route trades some of that directness for speed provided by a relayer and its capital. Neither route can make an unsubmitted source-chain transaction happen during a sequencer outage. A centralized exchange is another possible route when it supports deposits and withdrawals on the relevant networks, but it adds account, processing and custody dependencies. It is not a substitute for checking the actual asset and network supported.

Before moving funds, check the chain and token contract on both sides, the destination address, the minimum amount, quoted output and fees, and the route’s current status. Send a small test only when the extra cost is reasonable; otherwise, verify the details carefully before sending. Keep enough of the chain’s native gas token for the transfer and any follow-up action. Do not submit a second transfer simply because the first one is pending: check its status and transaction record first.

What should you do before the sequencer goes down?

Make a short plan while normal transactions still work. Start with the funds that would be difficult to access if the chain stopped accepting ordinary transactions, and decide where they need to be usable. Avoid moving everything just in case: each transfer can cost gas, bridge quotes can change, and moving tokens to a chain where you cannot pay gas may leave them stranded from practical use.

• Identify the source chain, token contract and destination chain; confirm the destination accepts that exact asset.
• Compare the native withdrawal route with a bridge route, including fees, expected timing and any stated limits.
• Leave enough native gas on the source chain to submit the transfer and on the destination chain to use the funds.
• Save the transaction hash and check the transfer’s source and destination status before retrying.

Once the transfer is submitted, distinguish a source-chain confirmation from destination-chain delivery. With a relayer route, Across’s documentation separates the user’s intent, the relayer’s destination fill and later settlement; those stages are not the same event. Keep the receipt and check the destination balance or transaction record before treating the funds as available.

The useful signals to watch are the sequencer’s transaction acceptance, the chain’s official outage updates, the documented fallback deadline, and whether the chosen bridge is still quoting and filling transfers. If the sequencer stops, first establish whether your transaction reached the chain; then follow that chain’s documented recovery path instead of submitting a duplicate.