Native Token Transfers: A Practical Primer
by Hodlhaus
If you are launching a new token and you know it will need to live on more than one chain, the first decision in front of you is one most teams underweight: what bridging model are you going to use? Get this wrong and you spend the next two years patching it. Get it right and most of the rest of the architecture follows.
This post is a short, opinionated primer on the three models that exist in production today — lock-and-mint, burn-and-mint, and Native Token Transfers (NTT) — and the questions we walk our clients through when they need to pick.
The three models, briefly
Lock-and-mint is the original pattern. The token is "real" on a home chain. To move it to another chain, you lock the original on the home chain inside a vault contract, and a parallel "wrapped" representation is minted on the destination. To move it back, you burn the wrapped token and unlock the original. Wrapped USDC, wrapped BTC, and most of the early bridges work this way.
The strength: simple to reason about. The supply is always knowable — the wrapped supply on every chain plus the unwrapped supply on the home chain equals total supply. The weakness: the home-chain vault is a giant honey pot. If it gets drained, every wrapped token on every other chain instantly becomes a claim against an empty vault. Most of the famous bridge hacks of 2022 — Ronin, Wormhole's own incident, Nomad — were lock-and-mint vaults being drained.
Burn-and-mint flips it. Instead of locking on the source and minting a wrapper on the destination, you burn on the source and mint a fresh native token on the destination. There is no vault. The token has no "home chain" — every chain holds canonical supply. USDC's CCTP uses this model. The strength is obvious: nothing to drain. The weakness is subtler: the cross-chain message that authorizes the destination mint is now a single point of trust. If that messaging layer is compromised or replays a message, you over-mint.
Native Token Transfers (NTT) are the newer pattern. They are a generalization of burn-and-mint that gives the issuer of the token control over who can mint on each chain, what the rate limits are, and how the cross-chain messages are verified. NTT does not invent a new bridge; it gives token issuers a standard way to deploy their token across many chains while keeping a single canonical supply and a single set of policies. Our engineering practice draws directly on the Wormhole Labs core team that maintains it, so this is the model we know best from the inside.
How to choose
Here are the questions we ask, in roughly the order they matter.
1. Do you control the token contract on every chain you want to be on?
If the answer is no — if the token already exists on chain A as an immutable contract you cannot upgrade — your options narrow. Lock-and-mint may be your only realistic path on that chain, with NTT or burn-and-mint everywhere else. This is often the case for tokens that launched before the team thought about cross-chain.
If the answer is yes, you have the full menu. Almost always, the answer worth picking is NTT or burn-and-mint, not lock-and-mint, because the latter gives you a vault to defend forever.
2. Where does the canonical supply live?
Lock-and-mint says: on one chain, surrounded by wrappers. Burn-and-mint and NTT say: nowhere in particular — all chains hold equal-status supply. The second answer is operationally simpler (no special "home" chain to monitor harder than the others) but it requires the bridging layer to be trustworthy because there is no on-chain vault as a backstop.
For most new tokens we work with, the right answer is "nowhere in particular." The mental model of a single home chain is a holdover from the era when only one chain mattered, and it creates an asymmetry that becomes uncomfortable as soon as a meaningful fraction of your activity moves elsewhere.
3. What is your worst-case loss if the bridge messaging layer is compromised?
Be honest about this number. Under burn-and-mint and NTT, a compromised messaging layer can over-mint on the destination. Under NTT specifically, you can set per-chain rate limits — caps on how much of the token can move into a chain in a given window — that bound the loss. We strongly recommend using them. The default of "no rate limit" is appropriate for almost no token.
Under lock-and-mint, a compromised vault is an unbounded loss: an attacker drains the vault, every wrapper everywhere is now unbacked, and the recovery story is a multi-chain coordinated airdrop of replacement tokens. There is no rate limit you can set on the vault that helps after the fact.
4. How much liquidity fragmentation can you tolerate?
Every chain you deploy on is another DEX you need liquidity on. NTT and burn-and-mint do not solve this — they give you a single canonical token across chains, but they do not give you a single canonical liquidity pool. You still have to bootstrap pools on each chain you deploy to, and you still have to decide whether to incentivize them.
Our usual advice: pick two chains to deploy on at launch. Get liquidity good on both. Add a third only after you can demonstrate that the first two are healthy. Teams that deploy on six chains on day one almost always end up with six shallow pools that arbitrageurs love and users hate.
5. What is your incident response posture?
The day one of your chains has a bad week — a halt, a reorg, a contract bug in the messaging layer — you need to be able to (a) pause minting on that chain quickly, (b) tell your users what is going on, and (c) make a decision about whether to roll forward or roll back. NTT gives you the controls for (a). The other two are on you.
If you do not have a written runbook for "what we do when chain X is broken for six hours," you are not ready to deploy on chain X. We help clients write this runbook before launch, not after.
What we tell teams who are about to ship
If you are launching now, in 2026, and you control your token contracts, the default answer for most teams is NTT with conservative per-chain rate limits, deployed on two chains at launch, with a written incident-response runbook before mainnet day. That is not because NTT is magic — it has trade-offs of its own, especially around the trust assumptions of the messaging layer — but because it is the model that gives you the most levers to pull when something goes wrong, and something will go wrong.
If you are working with a token that already exists on chain A and you cannot change the contract there, the answer is more nuanced and we should talk.
Cross-chain token mobility is one of the two practice areas Hodlhaus is built around. If you are about to ship something across more than one chain, get in touch before you finalize the design — the decisions made in the first month are the ones that compound.