Bridge maintenance windows pause new token transfers

A bridge maintenance window temporarily stops some or all new token transfers while operators update contracts, relayers or other parts of the cross-chain route. Existing transfers may still be awaiting source-chain confirmation, verification or execution on the destination, so a pause does not by itself show that a transfer has failed.

What happens during a bridge maintenance window?

During a window, the operator may disable new deposits, destination execution, or both; the exact scope depends on the bridge. Chainlink’s CCIP documentation describes transfers as a sequence of source-chain sending, off-chain verification and destination-chain execution, any of which can affect when tokens arrive.

That sequence explains why “sent” and “received” are different states. A source transaction can be confirmed while the message still waits for verification or destination execution. For a closer look at how a swap route handles costs and settlement, see Fermi Swap’s route, fee and settlement mechanics.

Should you send tokens just before a planned pause?

Usually, wait until the window ends if the transfer is not time-sensitive. A transaction submitted shortly before the cutoff can be recorded on the source chain but reach the destination while execution is paused, leaving it pending until service resumes.

Before sending, check the bridge’s own status notice and the transfer page for the route and token you intend to use. Look for the start time, time zone, affected directions, whether new deposits are disabled, and what the operator says will happen to transfers already in progress.

• Confirm the source and destination networks and token address.
• Check whether the pause affects deposits, withdrawals or both directions.
• Save the source transaction hash or bridge message ID.
• After the window, check the transfer’s destination status before submitting it again.

That last step matters because a pending transfer and a failed transfer are not the same. The ERC-7786 cross-chain messaging standard describes message delivery as tied to a source transaction and guards against successful delivery more than once; a second send can therefore create a separate transfer rather than resolve the first.

How can you tell whether a transfer is stuck?

Track the transfer using its transaction hash or message ID, then compare its recorded stage with the bridge’s maintenance notice. A source-confirmed message that has not reached destination execution may be delayed by the pause; a failed execution can require a retry, depending on the bridge’s design.

Chainlink’s CCIP documentation says destination execution failures can be retried, but that behavior should not be assumed for every bridge. Use the bridge’s stated recovery process and keep the original transaction details available. Avoid resubmitting solely because the destination balance has not changed yet.

When the window closes, operators may reopen transfers and resume eligible pending messages, but timing and recovery steps are bridge-specific. The operator’s notice should confirm reopening and explain how in-flight transfers will be handled; until then, the status of any individual pending transfer may remain unconfirmed.