If a cross-chain transfer seems stuck, first find its transaction on the chain where you sent it, then check the bridge’s status before retrying. A transfer may be waiting for confirmations, or the source payment may have completed while the destination step failed. Those cases need different actions, and sending again can create a second transfer.
What should you check first?
Find the source transaction hash: the unique ID for your send on its original blockchain. Open it in that chain’s block explorer, a website that shows transaction records, and check whether it is pending, failed, or confirmed.
Then check the bridge’s own status page or transaction screen using that hash. This matters for RenBridge: the Ren team’s November 2022 shutdown notice said Ren 1.0 would stop new mints, keep burns open for 30 days, then shut down. On 20 October 2026, treat RenBridge as unavailable for new transfers; old instructions are not proof that a route still works.
Keep both transaction hashes if you have them: one for the source send and one for the destination action. Never share your wallet recovery phrase or sign an unexpected transaction to “unstick” funds.
Where can a transfer stop?
A bridge transfer has at least two steps: the source chain records your deposit, then the bridge arranges a matching action on the destination chain. In a lock-and-mint transfer, the original asset is held and a wrapped token—a token that represents it on another chain—is created. In a burn-and-release transfer, the wrapped token is destroyed and the original asset is sent out.
Ethereum.org’s Bridges documentation describes the lock-and-mint model. RenVM’s gateway documentation describes how its Bitcoin route waited for source-chain confirmations before minting renBTC, its wrapped Bitcoin token. Confirmation requirements vary by chain and service, so don’t use an old wait time as a promise for a current transfer.
For example, say a historical RenVM transfer sent 0.05 BTC toward Ethereum. If the Bitcoin transaction is confirmed but no destination token appears, the source step succeeded; the missing step is the mint. If the source transaction is still pending, the bridge cannot finish the destination step yet.
What should you do for each status?
If the source transaction is pending, check its confirmation count and fee status in the source chain’s explorer. A pending transaction may need more time; avoid sending the same amount again until you know whether the first transaction can still confirm.
If the source transaction failed, check whether the wallet returned the funds and whether a network fee was still charged. Only start again after confirming the balance and checking that the route is active, the destination network is correct, and the receiving address supports that asset.
If the source is confirmed but the destination is missing, use the bridge’s official status screen and follow its stated recovery process. Some bridges provide a claim or retry step; others require support or cannot recover a failed transfer. Check the exact destination network and token address before claiming. A token with the same name can be a different asset.
If the destination transaction says successful but your wallet shows no balance, add the token using its verified contract address for that network. The transaction may have delivered the asset without the wallet displaying it automatically.
When is it safe to try again?
Retry only when the bridge confirms the first transfer failed or gives a specific recovery action for its transaction ID. Before any new send, verify that the bridge currently supports both networks and the exact asset; a working website alone does not prove its validators or release process are operating.
For an old wrapped asset, also check whether its original bridge still supports redemption. A token can remain visible in a wallet after the service that created it has stopped operating.
Retry only after the first transfer’s status is settled and the bridge confirms a live route for that asset and destination.