Native or wrapped tokens: choose by destination and control

Choose the issuer’s native cross-chain token when the destination supports its official deployment and you need the project to control that token; choose a wrapped token when compatibility across chains matters more. “Native” can mean the token the issuer controls on a chain, or that chain’s gas asset, so check which meaning the transfer interface uses. A token with the same ticker and symbol can still be a different contract with a different issuer and redemption path.

In Wormhole’s terminology, Native Token Transfers (NTT) move a project’s token through project-controlled deployments, while Wrapped Token Transfers (WTT), called Token Bridge in its SDK and contracts, use a bridge-issued representation. The source chain emits a message that Wormhole Guardians sign as a Verifiable Action Approval (VAA); a destination transaction submits that VAA to release or mint tokens. For the stages involved when a transfer needs recovery, see this Wormhole Bridge transfer recovery walkthrough.

How does a native token transfer work?

An NTT transfer moves value between deployments of the issuer’s token rather than creating a bridge-owned wrapped contract. In burn-and-mint mode, the source deployment burns the transferred amount, and the authorized destination deployment mints the corresponding amount after verifying the cross-chain message. The supply moves between chains; the issuer’s contracts and governance remain responsible for token policy.

In hub-and-spoke mode, the hub holds tokens in custody while spoke deployments mint corresponding balances. A return transfer burns tokens on a spoke and releases tokens from the hub. This can bring an existing token to additional chains without replacing its original contract, but the custody and spoke accounting must remain consistent. A hub-and-spoke deployment does not mean that the destination token is literally the same contract as the hub token.

NTT is the stronger fit when an issuer needs control over token contracts, access rules, rate limits or upgrade policy across supported chains. It also requires the issuer to deploy and configure the system on those chains. A transfer can be blocked by configured limits or pauses, and a destination without a compatible NTT deployment cannot receive the token through that path. The word “native” does not remove those deployment requirements.

What does a wrapped token transfer change?

WTT uses lock-and-mint. The sender’s token is locked in custody on the source chain, and the source contract emits a transfer message. After Guardians sign the message, a destination transaction verifies the VAA and mints the corresponding wrapped token. The wrapped contract identifies the original token by its source chain and contract address; its ticker or displayed name alone is not proof of identity.

The first transfer of a particular token to a destination may require an attestation that registers its metadata and enables the wrapped contract to be created there. Later transfers can use that registered asset. When a wrapped asset returns to its origin through the same bridge route, the destination representation is burned and the original tokens are released from custody. This depends on the route and its contracts: a wrapped token on one bridge is not automatically redeemable through another bridge.

WTT can provide a direct path where an issuer has not deployed its own native-transfer system. The trade-off is control: the wrapped contract is managed by the bridge’s contracts, while the original issuer’s token remains locked on its source chain. A source transaction can succeed before the destination transaction is submitted, so the balance may not appear until the VAA is redeemed. Manual flows require someone to complete that destination step; automatic flows rely on a relayer to do it.

Which transfer should you choose?

Choose based on the destination contract you need to hold and who controls it. Before approving a transaction, inspect the source token address, destination chain, recipient address, transfer route and destination token contract. Confirm that the destination asset is accepted by the application where you intend to use it; a wrapped version may not be interchangeable with the issuer’s deployment, even when the display name matches.

• Use NTT when the project’s official deployment exists on the destination and issuer control or consistent token policy matters.
• Use WTT when the destination supports the bridge route and you accept a bridge-managed representation.
• For a return transfer, confirm that the route can redeem the specific wrapped asset into the expected source token.
• If a transfer is pending, check the source transaction and VAA status before initiating another transfer; the destination may still need redemption.

For most users, the better choice is the asset the destination application explicitly supports, not the one with the more familiar ticker. If both routes are supported, NTT preserves the project’s control over its cross-chain token; WTT offers a bridge-issued representation with its own contract and redemption path. Those differences determine what you can do with the balance after it arrives.