A Cross-Chain Transfer Is Pending. What Should You Do?

A cross-chain transfer can remain pending while the source chain confirms it, a bridge verifies it, or the destination chain processes it. First, the wallet signs a transaction and sends it to the source chain. Validators include that transaction in a block. Depending on the bridge, a contract may lock tokens, burn them, or send a message to another chain. A bridge relayer or validator set then carries proof or a message to the destination, where a contract checks it and releases, mints, or routes the assets. Each step can have its own status, so “pending” alone does not tell you where the transfer is stuck.

Some bridges use liquidity pools instead of locking assets and minting a matching token. The details differ, but the useful question is the same: has the source transaction completed, and what step comes next? For the broader model of how omnichain wallets use apps across chains, see the separate explainer. Here, the immediate task is to locate the transfer in the chain of steps.

How can you tell which step is pending?

Check the source transaction hash in an explorer for the chain you sent from. If it is still waiting to be included, the bridge may not have received anything yet. If it is confirmed, check the bridge’s own transfer page or message status, then look for a destination transaction hash. A confirmed source transaction does not always mean the destination transaction has been submitted.

Use the transaction hash and the exact network shown in your wallet. A token with the same name can exist on several chains, and each chain has a separate record. The chain’s explorer shows source activity; the bridge interface may show whether a message is verified, relayed, or ready to claim. These labels vary, so follow the sequence rather than assuming one status word means the same thing everywhere.

When should you wait?

Wait when the source transaction is confirmed and the bridge is still verifying or relaying it, unless the bridge gives a specific action to take. Confirmation and message delivery are separate jobs. A bridge may wait for enough source-chain blocks before accepting a transaction, then need a relayer or validator to submit the message on the destination chain. Network congestion or a bridge’s own processing rules can extend that interval.

A useful analogy is a parcel with two tracking systems: one records pickup, the other records delivery. A pickup scan does not mean the parcel has reached the destination. Check the bridge’s stated processing guidance, and avoid submitting a second transfer just because the first one has not appeared yet.

When is it time to act?

Act when the records show a failed step or the bridge explicitly asks for an action. Start by matching the source hash, destination network, token, and recipient address. Then use the official interface for the bridge you chose. Depending on the failure, the available next step may be a retry, a claim, or support with the transaction details.

• Source transaction is pending: Check the wallet’s transaction controls and the chain’s guidance before replacing or speeding it up.
• Source transaction failed or reverted: The bridge operation did not complete; check the wallet and bridge records before trying again.
• Source is confirmed, destination is missing: Check the bridge status and whether a claim or relay action is offered.
• Destination transaction failed: Follow the bridge’s recovery instructions; do not assume the source transfer should be sent again.

Before any manual action, confirm the site and network from the bridge’s established entry point. Never share a recovery phrase or approve an unrelated transaction to “unstick” a transfer. For most readers, the better choice is to wait while a confirmed transfer is moving through a documented bridge step, and act only when the transaction records or the bridge’s instructions identify a failed or claimable step.