If you control the token contracts on each destination chain, choose Native Token Transfers (NTT); if users need an existing wrapped representation, a wrapped-token bridge may fit better. You’re comparing how much control each design gives your token team against the work of deploying and operating it. The deciding question is who should control the token supply on every chain.
NTT keeps each chain’s token under your control
NTT is a framework for transferring an issuer’s token across chains without making users hold a bridge-specific wrapped asset. You deploy an NTT Manager for the token on each chain and configure each manager to trust its peers. Those managers apply the token’s transfer rules; a transceiver carries and verifies messages between them.
In burning mode, the source manager burns tokens and the destination manager mints the same amount to the recipient. In locking mode, the source manager holds tokens in escrow and a destination manager releases tokens it already holds. The first model suits a token whose supply can move among chains; the second suits an existing hub token whose contract you want to leave unchanged.
The transfer is a message plus a supply change
A user calls the source manager with an amount, destination chain, recipient address and queue preference. The manager burns or locks the tokens, checks its outbound limit, and creates a transfer message. If the Wormhole transceiver is configured, it publishes that message through Wormhole Core; Guardians observe it and sign a Verified Action Approval (VAA).
At the destination, a transceiver verifies the message and submits it to the peer manager, which checks the configured source peer and whether the transfer has already been consumed. Once the required transceiver attestations are present, the manager checks inbound limits and mints or unlocks the tokens. The wormhole bridge carries the verified cross-chain message in this design; it does not decide whether your token uses burn-and-mint or lock-and-release.
For an issuer adding its token to Base, compare two cases. If the Base token should share the issuer’s global supply, burn on the source and mint on Base; if the existing token contract must remain the canonical supply, lock on the hub and release from a funded manager where supported. A wrapped-token bridge instead creates or releases a separate representation on the destination, so users and applications must accept that contract as the bridged asset.
Limits and administration determine the operating burden
NTT’s rate limiter controls transfer volume independently of message verification. The default replenishment duration is 24 hours, though it is set at deployment; outbound capacity is one limit per chain shared across destinations, while inbound capacity can be set separately for each source chain.
When an outbound transfer exceeds capacity, shouldQueue = true queues it for later release; with false, the call reverts. An inbound transfer over capacity is queued on the destination. For example, an issuer might set an illustrative outbound capacity of 1,000 tokens and a lower inbound capacity for a newer chain; choose values against the exposure you can tolerate and the volume users need, rather than treating defaults as a recommendation.
That control has a cost: the issuer must deploy and configure managers, peer addresses, token permissions, transceivers, limits and governance on every chain. Queued transfers need a completion path, and a wrong peer, missing mint authority, exhausted limit or insufficient destination liquidity in locking mode can leave a transfer waiting. A wrapped-token bridge can reduce token-contract work for an issuer, but places more weight on the wrapped asset’s issuer, liquidity and acceptance.
Choose by supply ownership and destination support
Use NTT when the same project should govern token behavior and supply across chains, and can maintain the managers and permissions. Choose burn-and-mint only when destination contracts can mint and burn under the issuer’s controls; choose locking only when the destination manager can pay incoming transfers from tokens it holds. These details decide the design more than the transfer interface does.
If a chain or token contract cannot support that setup, or users specifically need an already established wrapped asset, a wrapped-token route may be the practical choice. Before selecting the wormhole bridge path for an NTT deployment, confirm the transceiver, destination peer, token authority, rate limits and completion process on both chains; then test a small transfer and its return path.