Choose a Native or Wrapped Token Route by Destination Asset

Choose a native route when the destination offers the issuer’s intended token contract and enough usable liquidity; choose a wrapped route when that representation is the one the destination supports. A matching ticker does not establish that two tokens are interchangeable. The route determines which contract receives the cross-chain message, whether tokens are minted, released or unlocked, and what asset the recipient can actually use.

In Wormhole’s Native Token Transfers (NTT), a project can burn tokens on the source chain and mint them on the destination, or use a hub-and-spoke model that locks tokens centrally and releases them on connected chains. Wrapped Token Transfers (WTT) instead lock source tokens and mint a bridge-issued representation on the destination. The Wormhole bridge transfer checklist covers the transfer details to check before sending. In either model, the source transaction emits a message that must be verified and completed on the destination chain; a source-chain confirmation alone does not prove the recipient has received spendable tokens.

What is the difference between a native and wrapped route?

A native route delivers a token contract managed by its issuer or project, while a wrapped route delivers a separate contract representing tokens locked elsewhere. “Native” describes the token’s relationship to its issuer and chain deployment, not whether the asset is a chain’s gas token. A token can be native to its issuer’s deployment on one chain and transferred through a wrapped representation on another.

With NTT burn-and-mint, the source NTT Manager burns the user’s tokens and publishes a transfer message; after message verification, the destination manager mints the corresponding amount. The supply moves between chains rather than remaining as a locked source balance with a separate wrapped supply. In hub-and-spoke mode, the hub holds tokens and spoke managers release or mint according to the deployment’s configuration. The exact accounting depends on the selected mode.

With WTT, the source Token Bridge contract locks the transferred asset in custody and publishes a message. The destination Token Bridge verifies that message and mints its registered wrapped token to the recipient. On the return route, the wrapped token is burned and the source asset is unlocked. The destination representation is a distinct contract, even if its name, symbol and decimals match the source token.

Those distinctions affect control as well as accounting. NTT lets the token project retain control of its token contracts and configure transfer rules, subject to its deployment. WTT’s wrapped-token contracts are managed through Wormhole governance. Neither model guarantees that a token will have the same liquidity, integrations or permissions on every chain.

How can you tell which route delivers the token you need?

Check the destination contract address and the route’s stated token identity before approving a transfer. The label in a wallet or interface is only a display name; symbols can be duplicated, and metadata can be incomplete. If the destination application expects a particular contract, receiving another token with a familiar ticker may not satisfy that requirement.

• Match the contract. Confirm the destination token address against the project’s official information or the receiving application’s requirements. For a wrapped route, identify the bridge-issued contract, not just the source token’s address.
• Check route support. Confirm that the selected source and destination chains support the route for this token. A project may have NTT deployments on some chains and require a wrapped route elsewhere.
• Inspect the amount and fees. Compare the quoted destination amount, transfer fee and any required destination gas. Check how the interface handles token decimals and minimum transfer amounts.
• Confirm how completion works. A manual transfer may require a separate destination-chain transaction to redeem the verified message. An automatic route may use a relayer to submit that transaction, with its own fee and availability conditions.

Token registration can also be a prerequisite. In WTT, the destination must have a registered wrapped asset before it can mint that representation; a first transfer may require submitting a token attestation there. That setup is distinct from the transfer itself. A valid source transaction can therefore exist before the destination asset is ready to receive the mint.

Which route is better for a transfer?

The better route is the one that delivers the contract your destination use requires, with enough liquidity to use or exit the position. If the destination application needs the issuer’s native token and the project supports an NTT route there, that route preserves the issuer-defined token contract. If the destination only supports a bridge-issued representation, WTT may provide the needed chain coverage, but the resulting asset remains a separate token contract.

Do not treat “native” as a synonym for safer or more liquid. NTT’s controls can include rate limits and pausing, and a hub-and-spoke deployment depends on the destination manager having tokens available to release. WTT depends on custody of source assets, destination wrapped-token registration and successful message redemption. Both have failure or delay conditions; the relevant ones depend on the deployment and route.

For a material transfer, verify the token contract, recipient address, destination amount and redemption state before sending a larger balance. If the interface’s route label does not make clear which contract will arrive, resolve that from the route’s token details or the project’s published deployment information. The choice is about the asset the destination will accept, not the neatness of the route name.