How to Recover a Pending Cross-Chain Transfer
To recover a pending cross-chain transfer, check the source transaction first, then find out whether the destination step has completed. A transfer can be delayed even after the sending network has accepted it, because another system must observe that transaction and deliver or release the tokens on the receiving network. If you want one service to route a future move across networks, an omnichain cross-chain transfers service can handle that task through one interface.
Key points to check first
- Source transaction status
- Destination transaction status
- Route or relay status
- Whether you can retry, claim, or refund
Source transaction status: Open the sending transaction in the explorer for the network you sent from. “Success” means the network recorded the transaction; it does not prove that tokens arrived on the other chain. “Failed” or “reverted” means the transfer did not complete at the source, so check your wallet balance before trying again.
Destination transaction status: If the source transaction succeeded, look for a destination transaction or a transfer status from the service you used. A destination success means the receiving network processed the delivery. If the transaction succeeded but the tokens are not visible, check that your wallet is showing the receiving network and, if needed, add the correct token to its display.
Route or relay status: Some transfers need a relayer or solver to act after the source transaction is confirmed. These systems watch for the source event, then submit a transaction on the destination chain. If that second transaction has not appeared, the transfer may still be waiting for confirmation, route execution, or destination-chain capacity.
Retry, claim, or refund: The available recovery action depends on the route and its rules. A service may retry delivery automatically, let you claim tokens, or return them to the source chain after a timeout. Follow the status and recovery instructions for the route you actually used.
How do I tell a delay from a failure?
A delay has a successful source transaction and no completed destination transaction yet; a failure has a transaction that reverted or a route status that explicitly reports an error. Check the source explorer’s block time and confirmation status, then compare them with the route’s stated waiting period. Block confirmations are the additional blocks added after a transaction; routes often wait for them to reduce the risk of acting on a transaction that could be reorganized.
Times vary by network and route. A fast network may confirm in seconds, while a busier network or a route waiting for more confirmations can take minutes or longer. If the source is successful and the route still says pending within its expected window, record the transaction hash (the transaction’s unique identifier) and wait for the route to update before paying to send again.
What should I do if the transfer is stuck?
Start with the route’s own status, using the source transaction hash or transfer identifier. Check whether it names a destination transaction, a pending confirmation, a retry, or an action available to you. If the status says the destination transaction failed, look for a retry or claim option; those actions may require a small amount of the destination network’s native token to pay its transaction fee.
For example, suppose you send 100 USDC and the source transaction succeeds. The route shows 99.7 USDC expected at the destination, but no destination transaction after 20 minutes. Treat 99.7 as an illustrative estimate, not a guaranteed amount: fees and route terms determine the actual receive amount. Check the expected wait time and route status; if it remains pending, use the route’s recovery method rather than starting a second 100 USDC transfer.
Before retrying, verify the source and destination networks, token, amount, and transaction hash. Do not share your recovery phrase or approve an unrelated transaction to “unstick” funds. An omnichain route can involve several separate transactions, so check that any recovery instruction matches the transfer you made.
When is it safe to try again?
Try again only after the original transfer is marked failed, refunded, or otherwise closed, and confirm where the original tokens ended up. If the source transaction reverted, you can usually start a new transfer once your balance reflects the return. If the route is still pending, a duplicate send can leave you managing two transfers instead of one.
In short, use the source hash to establish whether the send happened, then check the destination and route status to identify the missing step. Retry only when the route’s state makes that action appropriate.