A delayed Wormhole transfer may still need destination redemption

A delayed Wormhole transfer may be waiting for an attestation, or it may already be ready for redemption on the destination chain. That distinction changes what to do next: waiting helps with an unfinished proof, while a ready transfer may need a separate transaction to release or mint the tokens. The source transaction confirms the send began; it does not always mean the recipient has received the asset.

How do I find a delayed Wormhole transfer?

Start with the source transaction hash and check it in Wormholescan, then confirm that it succeeded on the source chain. A failed or reverted transaction did not complete the send, so there is no transfer to redeem. If it succeeded, compare the source and destination chains, token, amount and recipient shown in the transfer details with what you intended.

The tracker helps separate a source-chain problem from a message or destination-chain delay. For treasury teams comparing routes and their handoff steps, this Wormhole Bridge route overview for treasury transfers gives the broader context. For a single pending transfer, the source hash is the practical starting point; save it alongside any destination transaction hash once redemption is attempted.

What does “waiting for attestation” mean?

It means the destination chain has not yet received the signed proof it needs to process the source-chain message. In a Wrapped Token Transfer, the source-side asset is locked or burned, then Wormhole Guardians verify the message and produce a VAA, or Verified Action Approval. The destination contract uses that proof to mint or release the corresponding token. The attestation is evidence of the source event, not the destination transaction itself.

This is why a transfer can look complete in the source wallet while remaining unfinished at the other end. Check the tracker again before resubmitting anything from the source chain: repeating the send could create a second transfer rather than finish the first. If no attestation is available yet, waiting for the message to become ready is different from paying destination gas to redeem it.

How do I finish a transfer that is ready?

When the tracker shows the message as ready but the destination transaction is missing, use the original transfer flow’s completion or redeem action. Connect the wallet that can receive the asset on the destination chain, check the network and recipient, and approve the destination-chain transaction. Manual flows require this separate redemption step; some routes arrange execution automatically, but their status still needs checking.

• Keep the source hash and identify the exact transfer in Wormholescan.
• Confirm the attestation is available before trying to redeem.
• Check the destination network, recipient address and token representation.
• After redemption, verify the destination transaction and token balance on that chain.

Redemption uses destination-chain gas, and a connected wallet may not be the intended recipient if the original transfer specified another address. Verify the address and chain in the transaction details before signing. A successful source transaction alone is not a reason to approve an unfamiliar transaction or share a recovery phrase.

Why might the normal redeem option fail?

The route and app that initiated the transfer can determine who is allowed to complete it. Some transfers use an app-specific contract or relayer, so a generic bridge screen may not have permission to redeem them. Wormhole’s Portal documentation says certain CCTP transfers can only be finalized by the original app when that app reserved the right to do so; in that case, return to the sending app and look for its claim or completion step.

There are trade-offs between manual and automatic completion. Manual redemption gives the user a visible final transaction and can work across a broader range of supported flows, but requires destination gas and an extra action. Automatic routes reduce that work, while adding reliance on the route’s relaying or solver process and its own status reporting. A delay alone does not tell you which case applies: the tracker’s message state and the original app’s route are the useful clues.

The practical takeaway is to diagnose before retrying: confirm the source send, check whether the attestation is ready, then redeem through the route that initiated the transfer. Watch for the tracker changing to attestation available, the appearance of a destination transaction, and any claim or completion instruction in the original app. If those signals do not line up, the source hash and route name are the details to take to that app’s support channel.