Which bridge status matters when your transfer stalls?

Which bridge status tells you whether your funds have arrived? The destination transaction does: a completed source transaction only shows that the first chain accepted your request. Many bridges then need to relay a message, wait for source-chain finality, or execute a separate transaction on the destination chain. Treat the tracker as a sequence of checkpoints, and you can see which part is still pending.

What do bridge tracking states mean?

Bridge tracking states describe steps in a cross-chain transfer, but their labels are not standard across services. A source transaction may lock or burn tokens, or swap them through a liquidity pool; the bridge’s mechanism determines what happens next. After the source transaction is confirmed, a relayer, validator set or proof system may need to make its result available to the destination chain. Only after destination execution does the receiving chain record the transfer or payout.

For a fuller walkthrough of moving treasury funds across chains with Biswap’s cross-chain treasury transfer process, see the linked guide. The same checkpoint distinction helps when reading any tracker: “source confirmed” is evidence about the source chain, not proof that the destination transaction succeeded. Look for a destination transaction hash or receipt before treating the transfer as complete.

Why can a transfer be confirmed but still pending?

“Confirmed” can mean the source transaction has a receipt, while the bridge still waits for enough finality to act on it. That delay can reflect the source chain’s confirmation policy, a proof or attestation step, relayer processing, or destination-chain congestion. The tracker may group several of these steps into a single “processing” label, so compare its status with the source and destination explorers when the wait matters.

Use the hashes and status details to locate the stalled stage:

• No source transaction hash: check whether the wallet submitted the request.
• Source hash with a failed receipt: the source action reverted; don’t assume a bridge message exists.
• Successful source receipt but no destination hash: check the bridge’s message or relay status.
• Destination hash with a failed receipt: inspect the destination execution result before retrying.

When should you retry a bridge transfer?

Retry only after you identify what the tracker says happened to the first request. Submitting again while the original message is still in flight can create a second transfer or duplicate action, depending on the bridge and its protections. If the source transaction failed, check whether the wallet actually spent the tokens; if destination execution failed, check the bridge’s documented recovery path rather than repeating the source step.

For occasional transfers, save the source hash and keep the tracker open until you have destination evidence. The next thing to watch is whether a destination transaction hash appears and ends with a successful receipt.