A native token is issued by the asset's own issuer on the chain where it sits. A bridged token is a copy minted by a third party while the original is held somewhere else, which makes the holder's claim a claim on that third party rather than on the issuer.
This page explains how to tell which one you are holding, what each model does to total supply, and how the risks differ. To move an existing asset onto a canonical standard, reach out to our team.
What is the difference between a native and a bridged token?
A native token is the issuer's own contract, deployed by the issuer, on the chain where the holder holds it. Redemption, controls, and the holder's legal claim all run to the issuer.
A bridged token is minted by a bridge. The original is locked on another chain and the bridge issues a representation against it, so the holder's claim runs to the bridge and depends on its solvency, key management, and verification.
The distinction is not cosmetic labelling. Two tokens can share a name, a symbol, and a price and still be different instruments with different counterparties.
How to tell which one you hold
Check the contract address, not the ticker. Three signals separate them.
- The issuer publishes its addresses. A native deployment appears on the issuer's own list of contract addresses per chain. A bridged copy does not.
- The symbol carries a suffix. Names like
USDC.econventionally indicate a bridged representation rather than the issuer's token. - Multiple versions coexist. Where a chain has several contracts for what appears to be one asset, at most one is native.
Where an asset has both a native deployment and older bridged copies on the same chain, they do not trade interchangeably. Each has its own liquidity, and moving between them requires a swap or an issuer-run migration.
What each model does to total supply
Bridged issuance adds representations. Native issuance moves supply.
| Model | What is created | Effect on total supply | Who can mint |
|---|---|---|---|
| Native, burn-and-mint | Nothing. Supply relocates | Unchanged | The issuer's own contract |
| Native, escrow-and-mint | Nothing net. One escrow backs it | Unchanged | The issuer's own contract |
| Bridged, lock-and-mint | A new token per bridge, per chain | Grows with each bridge and each chain | The bridge operator |
| Pool-backed transfer | Nothing, but depends on pool depth | Unchanged, inventory-constrained | No mint. Inventory is released |
The third row is where fragmentation comes from. Two bridges serving one chain produce two incompatible representations of the same asset, liquidity splits across them, and each copy needs its own pools, integrations, and listings. The cost of a split supply compounds with every chain added.
Native models avoid this by construction. Under the OFT standard, a send debits the source chain and a receive credits the destination, so a transfer changes where supply sits and not how much exists. Where an existing token cannot mint or burn, a single escrow backs minted supply across the whole mesh rather than one escrow per pathway.
How the risks differ
The risks are not different magnitudes of the same risk. They are different risks.
- Counterparty. A bridged balance depends on a party the holder did not choose and often cannot name.
- Redemption. An issuer redeems its own token, and a third party's wrapped copy is not that token, so a bridged holder may have no direct path to the underlying.
- Controls. Issuer controls such as blocking a sanctioned address apply to the issuer's contract, so a control enforced natively may not reach a wrapped version.
- Composability. Protocols integrate specific addresses, so a bridged copy has to earn integrations separately.
The controls point decides the question for regulated assets. If eligibility and blocking have to hold everywhere supply exists, then supply cannot exist in contracts the issuer does not control, which is why cross-chain compliance and canonical issuance are the same decision for tokenized assets.
How an issuer makes a token native on every chain
By deploying its own contract on each chain and connecting those deployments under one accounting model, so a transfer debits one and credits another instead of minting a copy.
For a new token, the contract implements the standard directly and supply moves by burning and minting. For a token already live on one chain, an adapter connects the existing contract without replacing it. Precision differences between chains are handled by converting to a shared precision before sending and reconstructing the local amount on arrival, with any remainder below the shared precision floored off and refunded rather than lost.
FAQ
Can I move a stablecoin between chains without wrapping it?
Yes, where the issuer supports a native path between those chains. The token that arrives is the issuer's own contract on the destination, and no wrapped representation is created.
Are native tokens better than bridged ones?
For holding and redeeming, a native token removes a counterparty the holder did not select. Bridged tokens exist because they were the only option on many chains before canonical standards were widely deployed.
Can I use one deposit address for the same stablecoin across chains?
The address is often identical across chains, and the chain still is not. A deposit sent to the correct address on the wrong network does not arrive. Native issuance unifies the asset rather than the destination.
Do bridged tokens affect DeFi yields?
Indirectly. Each bridged copy has its own pools, so depth splits across representations and execution worsens for what is nominally one asset.
What happens to a bridged copy after a native version launches?
It keeps existing until holders migrate. Issuers commonly run a migration path, and until it completes both versions trade separately on that chain.
Bring an existing asset onto a canonical standard
An asset is native on a chain when the contract there belongs to the issuer and a transfer moves supply rather than minting a copy. For a token already live on one chain, an adapter reaches the same position without redeploying it.
To move an existing asset onto a canonical standard, reach out to our team, or take the technical path at Developers.