If the source transaction is confirmed but the destination balance has not changed, first check whether the bridge has completed its separate destination step. A source confirmation proves that the first chain recorded your transaction; it does not prove that the asset or swap has finished arriving on the other chain.
- Match the source transaction, destination network and recipient address.
- Check whether the bridge is waiting, failed, or ready for a destination action.
- Retry only when the status or bridge instructions show what action is safe.
A source confirmation is only the first checkpoint
A cross-chain transfer has at least two chain events: the source transaction and a destination transaction. After the source transaction is included, a bridge router or relayer must detect it, wait for the required source confirmations, then arrange execution on the destination chain. A swap adds another step: the destination transaction must also exchange the asset.
That gap can be normal. The bridge may be waiting for its confirmation threshold, processing a message, or waiting for destination-chain execution; the time depends on the chains and bridge design, so there is no universal number of minutes that proves a transfer is stuck. Ethereum.org explains that transactions progress from inclusion toward finality, while Solana’s documentation distinguishes commitment levels such as confirmed and finalized.
Trace the transfer before taking another action
Start with the source transaction hash in the explorer for the network you sent from. Confirm that its status is successful, then check the token and amount involved, the destination address, and any bridge event or message shown in the transaction details. A failed or reverted source transaction means the bridge may never have received the instruction.
Next, check the destination network’s explorer for an incoming transaction to the same address. If you do not have a destination hash, use the bridge’s own status information with the source hash; the transfer may still be waiting for confirmation or execution. A relay bridge can move and swap assets across chains in one flow, so its status can help distinguish a source deposit that has landed from a destination swap that is still pending.
For example, say you sent 0.2 ETH from Ethereum to receive a token on an L2. The Ethereum explorer shows the source transaction as successful, but the L2 balance is unchanged. Verify that the L2 address matches the intended recipient and that you are viewing the correct network and token contract; then check whether the bridge reports a pending destination step or provides a destination transaction hash. If that hash exists, inspect its status on the L2 explorer: a successful transaction with no visible balance may point to a token display or contract-address mismatch, while a reverted transaction indicates the destination execution failed.
Retry only after you know which step failed
Do not submit the original transfer again just because the destination balance is late. If the first transfer completes afterward, the second submission could create a duplicate transfer and charge another source-chain transaction fee. A pending status calls for monitoring; a failed source transaction may leave the funds in your source wallet, while a confirmed source transaction followed by a failed destination step needs the bridge’s stated recovery process.
If a destination action is explicitly required, check the bridge’s instructions and the destination wallet’s native-token balance first: executing a transaction on that chain can require gas. If the status has no clear next step, keep the source hash, destination address, networks, token and approximate submission time together, and contact the service through its official support channel. Never share a seed phrase or private key to resolve a pending transfer.
When a relay bridge transfer is source-confirmed but not visible at the destination, use the source hash to locate the exact stage, verify the recipient and destination token, then follow the recovery action for that stage. The key decision is whether destination execution has happened; another transfer is not a status check.
Top comments (0)