Wormhole bridge transfers can take seconds or more than 20 minutes. A standard transfer may wait around 19 minutes for Ethereum finality, then wait again for a destination transaction. For a Wormhole cross-chain transfer from your own wallet, use Wormhole bridge to move tokens between connected chains.
Why does a Wormhole bridge transfer wait at the destination?
The destination chain must process a transaction before your tokens arrive. Confirmation on the sending chain is only the first stage. This differs from moving funds within a centralised exchange, where the exchange can update its own records.
Think of the transfer as a stamped claim ticket reaching a crowded counter. The ticket proves what you can collect, but someone still has to serve it. Wormhole’s Guardian Network creates that proof after it observes the source transaction. The proof is called a VAA, or Verified Action Approval.
Next, your wallet or a relayer submits the VAA on the destination chain. A relayer is a service that sends this final transaction for you. When the chain is busy, that transaction competes with others for space. Its gas fee, the payment for using the chain, affects when it gets processed.
A ready VAA therefore does not mean the receiving wallet has the tokens. For example, a transfer from Solana to Ethereum may clear Solana in roughly 14 seconds, then wait for an Ethereum transaction. Going the other way, Ethereum’s roughly 19-minute finality wait may dominate before the Solana transaction can begin. These are reference times, not delivery promises.
If a destination transaction is pending, check its status before acting. For a manual transfer, your wallet may let you raise its fee. For an automatic transfer, the relayer handles submission. Do not send the source transfer again merely because the destination is slow; that would start another transfer.
How do the tokens reach the other chain?
Wormhole sends a signed message between chains; the token itself does not travel through a network cable. In a common method called Wrapped Token Transfers, the source contract holds the original token. The destination contract then issues a wrapped token backed by it. The Wormhole token bridge uses this method for many assets.
That distinction matters when choosing an asset. Send ETH from Ethereum to Solana through a wrapped route, for example, and you receive a version of ETH on Solana, not SOL. Check the exact receiving token and its chain before signing. An exchange deposit may accept one version while rejecting another.
Some tokens use Native Token Transfers instead. Their issuer has set up the token on both chains, so the destination receives that chain’s native version. Availability depends on the particular token and pair of chains. A network being connected to Wormhole does not make every asset available on every route.
The usual wallet sequence is to choose the sending chain, receiving chain, asset, amount, and receiving address. Check the quoted output and route, then sign the source transaction. Wait for its confirmation and the Guardian proof. If you chose manual delivery, submit that proof on the destination chain to claim the tokens.
Automatic delivery adds a relayer to perform that last step. Either way, keep the source transaction record until the destination transaction confirms. A first transfer of a token to a new chain may also need its wrapped version registered there. That extra step can add time before the token appears.
What do the routes cost, and which should you choose?
The cost comes from network transactions and, on an automatic route, a possible relayer charge. Manual delivery usually means paying gas on both chains yourself. Automatic delivery includes the cost of the destination work in its quote. Gas rises when a chain is busy, so a price seen earlier may no longer apply.
As an illustration, $3 to send, $6 to complete on Ethereum, and $1 for a relayer would total $10. Actual costs can run from cents on lower-fee chains to tens of dollars or more when Ethereum is busy. Compare the amount you will receive, rather than one fee in isolation.
For a Wormhole bridge between Solana and Ethereum, I would usually pick automatic delivery if its quote is reasonable. It saves a second wallet action and avoids needing ETH in the receiving wallet just to claim. I would choose manual delivery when I already hold destination gas and want to control that transaction’s fee.
A faster route may use funds already available on the destination chain while the underlying transfer settles later. That can cut the wait to seconds when the route has capacity. Compare its final asset and quoted output with the standard route. Speed alone is a poor trade if you need a specific token version.
Before sending a large amount, check the receiving address, asset version, estimated time, and total quote. A small first transfer can confirm that your destination wallet receives the token you expect. Then track the destination transaction: that confirmation, rather than the source confirmation, marks delivery.
Questions to settle before you send
How does a completed source transaction become spendable tokens?
The Guardian Network signs proof of the source event. That proof must be submitted and accepted on the destination chain, which then issues or releases the receiving tokens. You can spend them after that destination transaction confirms. If the proof is ready but no destination transaction has confirmed, the transfer is still in progress.
How long should I wait, and what will I pay?
Allow for source finality, proof creation, and destination processing. Ethereum finality alone is around 19 minutes on a standard route; a busy destination can add more time. A fast route may take seconds when available. Your cost depends on both chains’ gas and any quoted delivery charge, so check the live quote before signing.
What decides whether a route is available?
The sending and receiving chains must support the route, and the chosen token must have a valid receiving form. Automatic delivery also needs relayer support; a fast route needs available destination funds. I would choose the route that delivers the token version I need, then compare its full cost and expected wait.