Wormhole bridge: How token transfers work across chains

Two token-transfer models shape how the wormhole bridge moves assets across chains: wrapped-token transfers and native-token transfers. The difference determines whether the destination receives a new wrapped version or the project’s own token.

A bridge does not carry a token through a shared tunnel. The source chain records an action, a cross-chain message reports it, and a destination-chain contract acts on that message. If you need to move tokens between Solana, Ethereum or many other blockchains, use the wormhole bridge, a crypto bridge built on the Wormhole cross-chain protocol for moving tokens and messages.

How does a wormhole bridge transfer tokens?

A transfer starts with a transaction on the chain where your tokens currently live. The bridge’s contract handles the source-side token action and emits a message describing what should happen on the destination chain.

Wormhole Guardians validate messages emitted by application contracts. Once a two-thirds supermajority agrees that a message is valid, they sign it; the message and signatures form a proof called a Verified Action Approval, or VAA.

The destination contract checks that proof before completing the transfer. Depending on the token model, it can mint a wrapped token or release or mint the project’s native token there. This separation matters: the message is evidence of an authorized source-chain action, while the destination contract enforces what that action permits.

So a transfer has at least two on-chain steps, with message verification between them. The source transaction can be complete while the destination action is still pending. A displayed source balance alone does not confirm that the recipient has received spendable tokens.

What is the difference between wrapped and native tokens?

A wrapped-token transfer generally locks tokens on the source chain and mints a corresponding wrapped asset on the destination. That asset represents the value held on the source side; it is a separate token contract, even when its name and ticker resemble the original.

This model can make a token available on chains where its native contract does not exist. The trade-off is that users and applications must recognize which version they hold. A familiar ticker is not enough to establish that two tokens are the same asset.

Native Token Transfers, or NTT, let a project move its own token across chains through approaches such as burning on one chain and minting on another, or using a hub-and-spoke arrangement. The destination token remains part of the project’s token system rather than becoming a Wormhole-managed wrapped version.

For a team, the choice is about control and deployment. NTT gives the project more control over token contracts and transfer policies, but requires the team to configure and manage its deployments. Wrapped transfers offer a more managed route, while the wrapped token contract is governed by Wormhole rather than owned and upgradeable by the integrating project.

• Choose a wrapped transfer when the goal is to make an asset available on another chain through a wrapped representation.
• Consider NTT when the project needs to retain control of its token contracts and define transfer policies across chains.
• Check the destination token’s contract or mint address; names and symbols can be copied or differ across networks.

What should you check before sending tokens?

Start by confirming the destination network and the recipient address format. Addresses that look alike can belong to different chains, and a wallet address is useful only on the network where the destination transaction will be made.

Then identify the destination asset. For a wrapped transfer, confirm that the recipient expects the wrapped version, not a native token with a similar ticker. For a project using NTT, check that its token deployment exists on the destination chain and that the application you plan to use recognizes it.

To make the transfer, follow this sequence:

1. Confirm the source token and its chain using the contract or mint address.
2. Choose the destination chain and check the recipient address on that chain.
3. Review whether the transfer uses a wrapped asset or the project’s native-token setup.
4. Submit the source-chain transaction, then check the destination-chain status and token balance.

Keep enough of the destination chain’s native currency for any later transaction you want to make there. Receiving a token and being able to use it are separate things: a wallet may need the right token account or application support, and a transaction on the destination chain can require its own network fee.

Which transfer model should a team choose?

For a project that needs long-term control of its token across multiple chains, native-token transfers are usually the stronger fit. They keep the project’s governance and token contracts central to the design, though the team takes on more integration work and operational responsibility.

For a team that needs a straightforward wrapped representation on another chain, wrapped transfers may fit better. That simplicity comes with a different trust and governance arrangement: users hold the wrapped asset, and the bridge’s governing system controls its contract.

For you as a sender, the practical takeaway is to verify the destination asset, not just the bridge route. A wormhole bridge transfer is complete only when the destination action has succeeded and the intended token is available on the chain where you plan to use it.