What a Bridge Maintenance Window Means for Your Transfer

A bridge maintenance window is a planned pause or limit on one part of a cross-chain transfer path. A bridge is a sequence of steps: a source-chain transaction is submitted, a contract records or escrows the asset, a message reaches the destination chain, and the destination executes the credit or makes a claim available. Maintenance can affect one step while others keep running, so the word “paused” does not tell you what has stopped.

For a Manta transfer, compare the path before choosing when to send; this guide covers Manta Bridge’s route choices by direction. A route’s components determine which maintenance notice matters. A pause on one network or transfer route does not automatically mean every route involving the same token is unavailable.

What stops during a bridge maintenance window?

The notice should identify the affected component, because a bridge interface, a contract and a message service perform different jobs. If only the interface is offline, the contract may still accept transactions, but users may not be able to start or track them through that interface. If the source contract stops accepting deposits, a new transfer cannot begin through that contract. If a relayer or destination processor pauses, a source transaction may be confirmed while its cross-chain message waits.

That last state is easy to misread. A successful source-chain receipt confirms that the source network included the transaction. It does not by itself prove that the destination has executed the corresponding message or credited the recipient. A bridge can therefore show a transfer in progress even when the source transaction is complete. Maintenance can also affect a withdrawal claim or finalization step, leaving an earlier withdrawal transaction recorded but the destination funds not yet released.

What should I check before sending?

Read the status notice for the route and direction you plan to use. Look for the component named, the operations affected, the expected resumption time if one is given, and any instructions for transfers already submitted. Then check the transfer screen and the source network before signing. The relevant checks are:

• Confirm the source and destination networks and the exact route.
• Check whether the notice blocks new submissions, message processing, withdrawals or claims.
• See whether the bridge reports an existing transfer as submitted, processing, completed or claimable.
• Keep the source transaction hash so you can check its on-chain status if the interface is unavailable.

Do not submit the same transfer again just because the destination balance has not changed. First establish whether the original source transaction was accepted and whether the bridge has a pending message or claim. A duplicate can create a second transfer if the first one is still progressing. If the bridge gives no status for an existing transfer, use its published support or recovery instructions rather than guessing at a retry.

What happens to a transfer already in progress?

Its outcome depends on the step reached and the component under maintenance. A transaction that was never submitted can usually wait until the route reopens. A source transaction already included on-chain remains a record on that network; whether its message can progress during the window depends on the bridge design and the affected service. A destination action that requires a separate claim may remain unfinished until that action is available again.

For most users, the simpler choice is to wait when the notice covers the route they need and the transfer is not time-sensitive. A maintenance window is not itself proof that funds are lost or that a transfer will resume automatically. Check the route’s stated handling of pending messages and claims, then act only on the status of the specific transfer.