A cross-chain transfer is pending when its source transaction has not settled or its bridge message has not completed on the destination; it has failed only when an on-chain transaction reverted or the route reports a terminal error. First find the stage that stopped: resending too early can create a second transfer.
Start with the source-chain transaction hash in that chain’s explorer, because a Mantle bridge transfer cannot complete on its destination until the source send has been accepted. Check the status, token amount and destination address before taking another action.
Did the source transaction settle?
A source transaction marked pending has not yet been included in a block, so the bridge may have nothing final to process. Ethereum.org explains that a pending transaction can be included, replaced by another transaction using the same nonce, or dropped; check the explorer again before treating it as complete.
If the transaction succeeded, confirm that the receipt shows success and that it sent the intended asset and amount. If it failed or reverted, the bridge transfer did not start, even though the transaction may have used network gas. Check your wallet’s balance before trying again, and review the destination address carefully.
For example, before checking the explorer, you may see no USDC on the destination and assume the bridge lost it. After finding a successful source transaction, you can look for its matching destination message; after finding a reverted source transaction, you know to investigate that send instead.
Which bridge stage is still waiting?
A successful source transaction does not always mean the destination transfer is finished: many routes pass a message across chains before releasing, minting or swapping the asset. LayerZero describes three useful message states:
- Sent: the source transaction created the cross-chain message.
- Verified: the required checks accepted the message on the destination side.
- Received: the destination transaction executed the message.
A message that is Sent but not Verified may still be waiting for source confirmations or verification. A Verified message that is not Received has cleared that stage but may be waiting for destination execution; execution can also fail if the receiving contract call reverts. These stages are not universal labels, but they show why a source success and a missing destination balance can both be true.
For a Mantle bridge transfer, compare the source and destination transaction records rather than relying on a wallet notification alone. If the destination execution failed, check whether the route offers a safe retry or recovery path; do not submit a fresh transfer until you know whether the original message can still complete.
What should you do before retrying?
Use the source hash to trace the transfer, then act on the last confirmed stage. If the source transaction is still pending, wait or use your wallet’s same-nonce replacement feature if you understand its effect; if it reverted, confirm the funds remain in your wallet before sending again. If the message is verified but execution failed, follow the route’s documented recovery method rather than manually calling an unfamiliar contract.
Retries can require gas on the destination chain, and the amount depends on that network and the operation being retried. Keep enough of its native gas token available, and allow for the route’s configured confirmation and verification requirements; there is no single wait time that applies to every bridge.
If you need to make a replacement move after checking the original, mantlebridge.us lets you arrange a cross-chain transfer and swap in one flow. That can be practical when your intended destination asset differs from what you hold, but it does not resolve an earlier message that remains in progress.
In short, establish whether the source settled, identify the last completed bridge stage, and retry only when the original transfer cannot still deliver. That sequence tells you whether to wait, recover, or start again.