A stuck cross-chain message is an instruction sent from one blockchain that has not yet completed its intended action on another. What matters most is whether the source transaction is final and whether the destination action is pending, failed, or already complete.
What happens to a cross-chain message?
A cross-chain message carries data or an instruction between networks. For example, a token transfer may lock or burn tokens on the source chain, then ask a destination-chain contract to release or mint the matching amount.
Think of it like a parcel with a tracking number: the sender’s receipt proves it was handed over, but it does not prove the recipient accepted it. In blockchain terms, the source transaction can succeed while message verification, delivery, or the destination contract’s action is still waiting.
In an omnichain application, messages can coordinate state or token supply across chains. That coordination depends on the message reaching the destination and being accepted there; a source-chain confirmation alone is not proof that the whole operation finished.
How do you tell where it is stuck?
Start with the source transaction hash, the unique identifier shown by the wallet or application. Open it in the source chain’s block explorer and check that it succeeded and has enough confirmations for the application’s stated finality requirement.
Then find the message record in the application or messaging protocol’s own tracker, using the source hash or message ID. Look for separate source and destination statuses: a source event may be confirmed while the destination message is still pending, retryable, or marked failed.
If the destination transaction exists, inspect its result. A successful destination transaction usually means the message was delivered; a reverted transaction means the destination contract ran but rejected the action, perhaps because a condition such as a balance or allowance was not met. No destination transaction usually points to a message that has not yet been executed.
What should you do before retrying?
Retry only after you identify the message’s current state. These steps help avoid sending a second application transaction when the first one is still processing.
- Save the source hash. Copy it from the original transaction record so you can track the same operation throughout.
- Confirm source success and finality. If the source transaction failed, the message was not created; follow the application’s normal process for starting again.
- Check the message tracker. Match the source hash or message ID, then note whether delivery is pending, failed, or complete.
- Inspect any destination transaction. If it reverted, read the explorer’s error details and the application’s recovery instructions before changing balances, permissions, or other inputs.
- Use the protocol’s retry action only when eligible. Some systems allow a failed destination call to be retried with the same message; others require a different recovery path. Check that the message is not already complete before submitting anything.
What does a retry cost, and what can go wrong?
A retry may require a new transaction on the destination chain, so you need that chain’s native token to pay its network fee. The amount varies with network congestion and the work the transaction performs. Some systems also involve a relayer or executor, a service that submits destination transactions, but who pays and what recovery options exist depend on the application.
The main edge case is a delayed status update: a message can be delivered even if the application’s display has not refreshed. Retrying it should not create duplicate effects when the receiving contract safely rejects a message ID it has already processed, but do not assume every application handles retries identically.
When should you start over?
Start a new operation only when the original source transaction failed or the application’s instructions explicitly say the message cannot be recovered. If the source transaction succeeded and the destination remains unresolved, keep the original hash and use the application’s stated recovery path; a second transfer could lock or spend funds again.
For future transfers, save the source hash before closing the confirmation screen; it is the simplest way to trace the same message from source to destination.