Why Your Crypto Left One Chain but Hasn’t Arrived

A confirmed transaction on the source chain does not prove that your crypto has arrived on the destination chain. It proves that the source network included the transaction and that its contract call completed there; the bridge may still need to relay a message, fill an intent, or complete a separate destination transaction.

Start with the transaction hash from the wallet or exchange that sent the funds. Open it in an explorer for the source chain and check the execution result, destination chain, recipient, token, and amount. If the call reverted, the bridge did not accept the transfer, even if the transaction itself is visible on-chain. For context on the route and swap side, see this fuller guide to moving crypto across chains with ParaSwap; tracking begins with the source transaction and the bridge’s own record.

Why does a confirmed source transaction not mean the transfer is complete?

A bridge transfer is a sequence of transactions and off-chain work, not one transaction spanning two chains. The source transaction can lock or escrow tokens, burn them, or publish a message that another system must observe. The destination chain then needs its own transaction to release, mint, or deliver the corresponding asset.

Those steps have separate hashes and separate execution results. The source explorer cannot show a destination transaction that has not happened yet. A successful source receipt means the source-chain call did not revert. It does not attest that a relayer saw the event, that a validator set approved a message, or that destination execution succeeded.

The route determines what to track next. A liquidity-based bridge may have a relayer fulfill an intent on the destination chain and later settle its accounting. A message-passing bridge waits for the message to be verified and executed. A canonical rollup bridge follows the rollup’s deposit or withdrawal rules. These designs expose different status names and recovery steps, so a generic “bridge pending” label is not enough to diagnose the transfer.

How do you track a cross-chain transfer step by step?

Use the bridge’s tracker or status endpoint with the source transaction hash and source chain, if those are the supported lookup fields. Some systems instead require a deposit ID from a source event. A transaction hash alone may be ambiguous across chains, and an address or amount search can return other transfers.

• Confirm the source call. Check that the transaction succeeded and interacted with the expected bridge contract. A reverted transaction needs a new submission; waiting will not complete it.
• Find the bridge record. Match the source hash or deposit ID to the bridge’s transfer record. Check the recorded destination chain, recipient, token, and amount before relying on its status.
• Read the exact state. “Pending” can mean the bridge has not filled or executed the transfer. “Filled” or “executed” should identify a destination transaction; open that hash on the destination chain.
• Verify delivery on the destination chain. Confirm the destination transaction succeeded and the expected recipient received the intended asset. Check the token contract address as well as its displayed symbol.

Indexers and status pages can lag behind the chain. A tracker may temporarily show no record after the source transaction confirms because it has not indexed the event yet. That is different from a record that says the message failed or the deposit expired. Refresh after a short interval, and use the bridge’s documented lookup key rather than repeatedly submitting the transfer.

What does a stalled or failed bridge status mean?

Read the last completed stage, then identify which component owns the next action. If the bridge has not indexed the source event, verify the source hash and chain first. If it has recorded the deposit but no destination transaction exists, the relay, fill, or message-execution stage is still outstanding. If a destination transaction exists and reverted, inspect that transaction’s execution result; the transfer can require a bridge-specific recovery path.

Canonical rollup withdrawals show why “pending” has no universal duration or meaning. In the Optimism withdrawal flow, a user initiates a withdrawal on the L2, proves it on L1 through OptimismPortal.proveWithdrawalTransaction, then finalizes it on L1 through OptimismPortal.finalizeWithdrawalTransaction after the required finalization period. Seeing the L2 initiation transaction alone does not mean the L1 withdrawal is ready to finalize. Other bridges use different contracts and stages, so do not apply this sequence to an unrelated route.

If the status is expired, refunded, or failed, follow the bridge’s stated recovery instructions and verify the destination chain and recipient before taking action. Never share a seed phrase or sign an unrelated transaction to “release” a pending transfer. A legitimate status check needs transaction identifiers, not wallet secrets.

How can you tell the crypto has arrived?

Arrival means the destination chain contains a successful transaction that delivers the intended asset to the intended address. Check its receipt, recipient, token contract, and amount. A token symbol alone is not proof: different contracts can use the same symbol, and a wallet may hide a token until it is added to the display.

Keep both transaction hashes with the route details. The source hash proves what was submitted; the destination hash proves what executed there. When the destination hash is absent, the transfer has not yet reached a verifiable on-chain delivery, regardless of how quickly the source balance changed.