Super bridge routes: how to recover a stuck transfer

A stuck transfer on a super bridge route is recovered by completing or resolving the protocol step that already owns it; switching routes does not move that in-flight state. A wallet can show “pending” while the bridge waits for a rollup state update, a challenge period, an attestation, or a provider’s delivery. The route label and transaction history identify which mechanism applies. The distinction is useful when reading a super bridge transfer: a status describes a step in its route, not a universal bridge queue.

How does a super bridge native withdrawal work?

A native withdrawal uses the rollup’s own bridge contracts to return assets to the chain where the rollup settles. The contracts enforce the rollup’s withdrawal process. In common optimistic rollup flows, that process includes a delay so a withdrawal can be challenged before the destination releases funds.

On OP Stack routes, the withdrawal starts on the rollup. The system then waits for the rollup’s state to be posted to the settlement chain. Activity may show “Waiting for state root” or “Waiting for dispute game.” Once the relevant state is available, the sender must prove the withdrawal on the settlement chain. After the challenge period, the sender finalizes it there. Both the prove and finalize transactions need settlement-chain gas.

Arbitrum withdrawals have a different sequence: they start on the rollup and finalize on the settlement chain after the assertion confirmation wait; there is no separate prove step in the documented flow. Other native bridges use their own contracts and steps. Read the route’s displayed estimate and its Activity steps rather than assuming every withdrawal follows the OP Stack sequence.

A native withdrawal that has reached “Action needed” is waiting for a wallet transaction, not more background processing. Select the ready Prove or Finalize step and confirm it. A chain upgrade or dispute can reset a withdrawal’s wait or require a new proof, so inspect the step details if its state changes. A submitted native withdrawal cannot be cancelled or accelerated through another bridge.

Can a third-party route rescue a pending transfer?

No. A third-party route cannot take over the tokens or state of a transfer already submitted to a native bridge. It creates a separate transfer, with its own source transaction, provider contracts, fees, and settlement path. If the original transfer is still in progress, starting a second route means funding a second transaction; it does not cancel the first.

Third-party routes differ from one another. Some fast bridges use provider liquidity to deliver assets on the destination chain before the source-side process has fully settled. If that provider cannot fill the transfer by its deadline, the route may refund the source wallet automatically. Messaging routes instead rely on a message being relayed and generally continue toward destination delivery. These recovery rules are properties of the selected provider, not a guarantee shared by all third-party bridges.

Use the transfer’s route name and step history to identify the mechanism. A refund-capable route may show “Refund in progress” before the source-side return completes. Check the source wallet for the returned asset: if the route performed a swap before bridging, the refund can be in the swapped token. A native bridge, by contrast, does not offer a provider-style refund; the remaining on-chain steps must complete.

Before starting a new transfer, compare the route’s settlement path, expected wait, destination amount, fees, and any action required later. For most users moving a substantial amount between a rollup and its settlement chain, the native route is the clearer choice when matching the rollup’s security assumptions matters more than speed. A third-party route can suit a time-sensitive transfer when its provider model and refund conditions are acceptable. Neither choice removes the need to track the actual transaction.

What should you check when a bridge transfer stalls?

Start with Activity and the source-chain transaction hash. The hash shows whether the initiating transaction confirmed; Activity shows whether the route has another step to execute. A failed start transaction did not transfer the tokens, though the failed attempt can still cost network gas. If the start confirmed, use the route’s current state to decide what to do:

• Action needed: Open the transfer and complete the named Prove or Finalize step. Confirm that the wallet has gas on the chain where that step executes.
• A waiting label: Check what the route is waiting for. A state root, dispute period, or attestation is a protocol milestone; sending another bridge transaction does not advance it.
• Third-party route in progress: Allow for provider delivery and network congestion. If the route has a refund path, track its status and check the source wallet for the refund.
• Complete, but no visible balance: Check the recipient address, destination network, and token contract. A wallet may not display a token it has not added.

If a Prove or Finalize transaction itself fails, or a third-party transfer remains in progress well beyond its estimate, preserve the initiating hash and route name. Those details let support or an explorer trace the actual contract events and identify the step that remains. Do not treat a second route as a recovery action unless the first route has completed or returned its funds. The practical rule is simple: recover the transfer through the mechanism that received the original transaction.