Jump to content
Crypto Front Page

Crypto networks, markets and policy

When a Sequencer Stops Mid-Bridge

A sequencer outage can pause one leg of a bridge after the source transaction lands; what happens next depends on the bridge design and recovery path.

The Crypto Front Page Desk4 min read

When a Sequencer Stops Mid-Bridge

A bridge can pause mid-transfer when a rollup sequencer stops after a transaction has begun on one chain but before its message or asset is processed on the other. The source transaction may already be recorded, while the destination step waits for a sequencer, relayer or liquidity provider. That gap exists because two blockchains do not share one transaction that can succeed or fail as a unit.

What happens when a bridge transfer starts?

A bridge transfer begins with an instruction on the source chain. In a common rollup deposit, the user sends assets to a bridge contract on Ethereum; that contract locks them and emits a message for the rollup. The sequencer orders transactions on the rollup, where a corresponding step can credit the user with equivalent assets.

Those actions happen in sequence, not all at once. The source chain records its part first. A message then has to reach the destination chain, where the relevant contract executes it. Think of the source transaction as a parcel being accepted at one depot: that receipt does not prove it has arrived at the next depot.

Cross-chain swaps add steps: an application may route a trade through a bridge and arrange for assets to be exchanged on the destination chain. For a fuller account of how ParaSwap moves crypto across chains in one flow, see the linked explainer. The route can involve more than the rollup sequencer, so the point at which progress stops matters.

Which part stops when the sequencer goes offline?

A sequencer orders and publishes rollup transactions; it does not control every bridge or every chain. If it stops before including a deposit message, the source transaction may be visible while the destination credit remains pending. Some rollups provide an onchain queue or forced-inclusion route for transactions that the sequencer has not processed, though the route and delay depend on that rollup.

If the sequencer stops after the destination transaction is included, the transfer may already be complete even if an app has not refreshed its status. For a withdrawal from a rollup to Ethereum, the order is reversed: the rollup records the withdrawal first, then the bridge’s proof, challenge or finalization process must allow the Ethereum-side claim. A sequencer outage can delay the first step; it does not erase a step already recorded onchain.

Third-party bridges may work differently. Some use relayers to carry messages; others use liquidity providers to pay out on the destination chain before settling the source-side transfer later. A rollup sequencer outage can interrupt a route that depends on that rollup, but it does not by itself explain the state of every provider or bridge contract involved.

What should you check before retrying?

Start with the source transaction hash and confirm whether it succeeded on its chain. Then check the bridge’s transfer record or destination-chain explorer for a message, claim or payout. A submitted source transaction, a queued message and a completed destination transfer are different states, even when an app displays them under one progress bar.

  • If the source transaction failed, check whether the assets remain in your wallet before submitting again.
  • If it succeeded but the destination step is pending, check the bridge’s stated recovery or forced-inclusion process.
  • If a relayer or liquidity provider is involved, check whether the bridge shows a claim, refund or settlement action.
  • Before signing a retry, compare its destination, amount and fees with the original transfer.

Do not assume that a stalled display means funds are lost, or that resubmitting is harmless: a second transaction can create a duplicate instruction or cost more in fees. The useful distinction is whether the source action landed and who is responsible for the next step.

When the sequencer stops, the bridge becomes a sequence with a waiting point, not one atomic transfer. What changed is that one leg may be recorded while the next cannot proceed; watch the source transaction, the destination message and the bridge’s recovery path to see which step remains.