One cross-chain transfer can need several destination transactions because a blockchain message may have to be verified, prepared and redeemed in separate steps. Think of it like a parcel: the source chain dispatches it, a signed message proves what was sent, and the destination chain completes delivery. Those steps can happen off-chain or in separate on-chain transactions.
What happens between sending and receiving?
A transfer starts with a transaction on the source chain. The bridge’s contract locks or burns the tokens and publishes a message describing the transfer; Wormhole Guardians observe that message and sign a proof called a VAA. The VAA is evidence for the destination chain, not the destination transaction itself. Wormhole’s VAA documentation describes how the proof is created and delivered.
If your route uses wormhole bridge to move tokens to a chain such as Solana, the destination may need one transaction to verify and post the VAA, then another to redeem it and mint or release the tokens. A Solana wallet may also need an associated token account for the incoming asset. Creating that account takes space and rent-exempt SOL, so an absent account can add setup work and cost.
That is why one transfer ID can correspond to several transaction hashes. They record stages in one transfer flow, not necessarily several transfers. The Wormhole SDK returns destination transaction IDs as a list, and its Solana Core flow separates VAA posting from the receiving application’s action. Wormhole’s Core Contracts documentation explains that sequence.
Why split the work across transactions?
Chains impose different limits on what a transaction can do. On Solana, verifying Guardian signatures, storing the VAA and executing the token program can require different instructions and accounts; putting everything into one transaction may exceed compute or transaction-size limits. On other chains, a single redemption call may be enough. The chain, token route and recipient’s account state decide the count.
For example, say you send a wrapped token to a Solana wallet that has never held it. The destination flow may first create the token account, then post the VAA, then redeem the transfer. If the account already exists, the setup step may disappear; if the app or relayer bundles compatible instructions, some steps may share a transaction. There is no fixed “three transactions per bridge” rule.
What do extra transactions cost, and what should you check?
Each destination transaction can incur that chain’s network fee, and account creation may require rent-exempt SOL. Manual completion also means you may need SOL in the destination wallet to pay those fees. An automated route can submit the destination steps for you, but its quote may include a relay fee; compare the quoted amount with the time and extra wallet actions you save.
When reviewing a transfer, match the destination hashes to the same transfer record and check their status in order. A posted VAA means the proof reached the chain; it does not by itself mean the tokens were redeemed. If the first destination transaction succeeds and the next fails, resume the pending completion step rather than sending the source transfer again.
For frequent transfers, the useful measure is total time and cost to a spendable balance, not the number of hashes: multiple destination transactions are often the chain’s way of finishing one delivery safely.
Top comments (0)