What a Sequencer Outage Means for Treasury Swaps

A sequencer outage can stop or delay treasury swaps on a layer 2 network, so check whether a transaction reached the chain before sending it again. A sequencer orders transactions and publishes them into the network’s blocks. If it stops accepting transactions, a wallet may show a pending transaction even though the swap has not executed. The exact fallback options depend on the network.

A swap trades one token for another, often through a liquidity pool, a pool of tokens used to make trades. For a fuller explanation of the trading mechanics, see this guide to base swap. During downtime, the practical question is whether the signed transaction was included and what terms it will use if it executes later.

What happens to a swap during sequencer downtime?

If the sequencer is unavailable, a swap may wait in a wallet or service queue, fail to reach the network, or become eligible for inclusion after service returns. A wallet’s “pending” label describes what it knows about the transaction; it does not prove that the chain has accepted it. Some networks offer a way to submit transactions through their underlying layer 1 during an outage, but the process, delay and fees vary. Do not assume that route exists or that it will work for a particular transaction.

A transaction that is included later may face different conditions from those shown when it was prepared. Token prices can move, a quote can expire, and a swap may revert if its minimum-output condition is no longer met. A revert means the swap did not complete, though network fees may still be charged. Check the transaction details and the application’s terms before treating the trade as settled.

How can a treasury check whether a swap went through?

Use the transaction hash, the unique identifier for a submitted transaction, to check its status on the relevant network’s explorer or through a trusted node provider. Confirm whether it is pending, included, failed or replaced. Then check the treasury wallet’s token balances and transaction history. A success notice from a wallet or trading interface is useful, but the recorded chain result is the better basis for reconciliation.

Before retrying, check:

• Whether the original transaction has a hash and appears on the correct network.
• Whether its status is pending, confirmed, failed or replaced.
• Whether the wallet’s nonce, a number that orders its transactions, is still tied up by the pending transaction.
• Whether the quote, minimum output and deadline remain acceptable.

Sending a second transaction without checking the first can create confusion. If both remain valid, both could execute. Replacing a pending transaction usually involves the same wallet and nonce, but the exact controls and requirements depend on the wallet and network. Follow treasury approval rules before making that change.

What should a treasury do before sending again?

Pause new swaps on the affected network until its status is clear. Check the network’s official status channel and confirm that the treasury’s wallet, RPC provider (the service that connects an app to the blockchain) and trading interface are all responding. A single failed interface does not establish that the sequencer is down.

For a material trade, have another authorised operator verify the transaction state and proposed retry. Record the original hash, intended amount, quote terms and any replacement transaction for later reconciliation. Resume when the network is processing transactions and the treasury can verify execution. The useful rule is simple: establish what happened to the first transaction before authorising a second.