Wormhole Transfer Tracking by Transaction Hash

2026.10.10 · last updated

Wormhole transfer tracking uses the source transaction hash in Wormholescan to locate the cross-chain record. Choose Mainnet or Testnet to match the transfer, then inspect the source details and message status. For a token transfer, confirmation on the sending chain establishes only the source action. A signed message still needs the appropriate destination execution. The receiving transaction and its token movement show whether the transfer reached the intended recipient.

The destination transaction sender may be a relayer, so identify receipt through the recipient and token transfer details.

From source hash to cross-chain record

The source transaction hash connects a sending-chain transaction with any cross-chain message that Wormholescan has indexed. An associated operation can bring the message, source activity, and destination activity into one record. The protocol that produced the message determines how to interpret its payload and what destination action should follow.

If the application created a separate token-approval transaction, its hash identifies that authorization. That record alone cannot establish publication of a transfer message. The transfer call's emitted message supplies the cross-chain connection.

Which identifiers belong to the same transfer?

The source hash identifies the sending-chain transaction, the VAA ID identifies an emitted message, and an associated destination hash identifies a receiving-chain transaction. A missing destination hash leaves the receiving action unresolved in that record, even when source and message identifiers already appear.

Message coordinates

A VAA is a Verified Action Approval containing the message and Guardian signatures. Its identifying fields describe message publication, while its payload carries instructions that the receiving application interprets.

Emitter chain and address

The emitter chain identifies where the message originated. The emitter address identifies the contract that published it through the Core Contract. Neither field necessarily names the wallet that initiated the transaction. The emitting contract and its protocol determine which payload interpretation applies.

Sequence and payload

The sequence distinguishes messages from that emitter. A finalized message's VAA ID combines the emitter chain, emitter address, and sequence number. A token-transfer payload describes the intended token movement and recipient. Those instructions establish what the receiving contract should process; destination execution establishes what actually happened.

Attestation and destination execution

A source-chain success establishes that the source transaction executed. For a Guardian-attested route, an available VAA establishes that the message has signatures. Neither observation alone demonstrates redemption at the destination.

Wrapped Token Transfers (WTT), also called Token Bridge in contracts and SDKs, requires its signed VAA at the destination before minting or releasing tokens. Automatic WTT delivery uses a relayer on supported routes. Manual delivery requires the user or application to submit the message through the appropriate destination interface. A submitted destination transaction also needs successful execution for redemption to complete. Its receipt and token movements supply more useful detail than the mere existence of an identifier.

The destination transaction can include delivery through an intermediary contract. Check how that contract distributed the tokens before treating a successful call as proof of receipt. An automatic WTT relayer, for instance, distributes the remaining tokens after applicable relay fees. Any native tokens supplied for destination gas require separate accounting. The message amount and final recipient amount can therefore describe different quantities. Compare amounts only after accounting for their units and the selected route's deductions.

How can I confirm receipt at the destination?

Receipt requires successful destination execution that delivers the expected token representation to the recorded recipient, with any route-specific deductions reflected in the received amount. For an indexed Guardian-attested token transfer, the submitted source hash and expected recipient provide the starting information. Use the following conditions to reconcile the request with the receiving-chain record.

If the source hash matches the submitted transfer, confirm its source chain and Mainnet or Testnet environment before interpreting the message.
If the record contains a token-transfer message, match its destination, recipient, and token identity to the transfer request.
If redemption requires token registration or a configured receiving contract, confirm that prerequisite before attempting the destination action.
Once the signed message is available, distinguish awaiting submission from a destination transaction that still awaits successful execution.
When the receiving transaction succeeds, check the actual token movement and credited recipient. Close the check when those details match the requested transfer and its applicable deductions.

Network and route compatibility

A tracking tool needs the correct network environment and support for the transfer's protocol. Messaging availability alone does not establish token compatibility or automatic delivery. WTT's automatic mode depends on relayer support for the relevant chains. Changing a wallet's displayed network cannot change the destination encoded in an existing transfer. Another bridge interface may expose different protocols or redemption capabilities, so an available button does not establish compatibility with the recorded transfer.

Open full-size image

Native Token Transfers (NTT) integrations that use Executor provide execution-status queries through their selected relay provider. That delivery information helps explain progress beyond the signed message. Destination chain records establish the resulting token movement. WTT redemption methods do not automatically apply to an NTT transfer merely because both integrations use Wormhole. The receiving protocol determines which contracts and execution conditions matter.

What should I check when a transfer has no matching result?

An empty search result calls for checking the transaction type, source network, and available explorer data before treating the transfer as failed. A source-chain explorer may show a successful transaction while its cross-chain record remains unavailable. An indexing gap and an on-chain failure describe different situations. A missing destination association likewise does not establish that the receiving chain rejected execution.

For Guardian-attested transfers, the selected source finality requirement affects when a signed VAA becomes available. A destination failure can instead arise from unmet token registration or receiving-contract requirements. Refreshing a lookup updates the displayed data; submitting another source transfer initiates another operation. Keep the original hash and message identity when investigating an existing transfer. A successfully initiated WTT transfer can use its original source hash for recovery without starting another deposit.

Redemption authority also limits recovery. Only the designated recipient contract can redeem a WTT transfer with a payload. Its application logic determines how the tokens and attached instructions proceed. For Cross-Chain Transfer Protocol (CCTP), a nonzero destination_caller identifies the only address authorized to redeem the message. A CCTP transfer that assigns this permission to the originating application's contract needs that application's completion path.

Wormhole: frequently asked questions

Can I find a transfer without its source transaction hash?

Wormholescan also supports searches by VAA ID or wallet address. An address search can help locate the relevant transaction among that account's indexed activity. A VAA ID targets a particular message. Both alternatives still need the correct Mainnet or Testnet environment to return the relevant record.

Does looking up a transfer require connecting my wallet?

A transaction-hash lookup uses public explorer data and does not require a wallet connection or signature. Reading a record does not execute its redemption. If a separate completion interface asks for a transaction signature, that request concerns an on-chain action, with different permissions and costs from viewing status.

Is a transfer hash safe to share for troubleshooting?

A transfer hash does not contain a private key, but sharing it can reveal addresses and transaction activity. A cross-chain record may connect the source transaction with its destination details. Share the hash with an understanding that the recipient can inspect those public records and associated account activity.

Must the destination transaction sender match my source wallet?

The destination transaction sender can differ from the source wallet because a relayer or another permitted submitter can complete delivery. For a standard WTT transfer, the signed message specifies the recipient. Identify receipt through the recipient's token movement. The transaction's fee-paying sender may not be the account that receives the tokens.

What format does the Advanced view use for a VAA?

Wormholescan's Advanced view provides the VAA in Base64. A destination interface that expects hexadecimal bytes needs the same VAA decoded from Base64 and represented in hex. That encoding change does not alter its recipient, payload, or signatures. The receiving interface determines the format that its input accepts.

Could a token-attestation record explain why no tokens arrived?

A WTT token-attestation message carries token metadata and does not itself transfer a user's balance. Processing that message at the destination can create the wrapped token representation that later transfers require. The transfer message is a different operation, so an attestation result alone cannot demonstrate delivery of the requested tokens.

How should I interpret the amount inside a decoded WTT message?

A decoded WTT amount is an integer in protocol units, with precision capped at 8 decimal places. Tokens with fewer decimals retain that lower precision. Convert using the applicable precision before comparing it with a displayed balance, and distinguish the message's transferred amount from the recipient's amount after applicable fees.

Can an application monitor transfers through the Wormholescan API?

The Wormholescan API exposes operation and VAA data for programmatic monitoring. An integration should retain the network environment and available transaction and message identifiers. It also needs to distinguish missing data, rate-limit responses, and server errors from an on-chain failure. Inspect the returned operation state independently of the API request's status.