Some crypto assets use canonical representations because each blockchain has its own ledger, and one recognized token address prevents several bridges from creating competing versions of the same asset.
What “canonical” means in a bridge
A canonical representation is the version an ecosystem treats as the standard form of an asset on a particular chain. It is identified by a contract address, not by a ticker symbol. USDC on Ethereum, native USDC on Polygon Network, and PoS-USDC created through Polygon’s PoS Bridge may share a name while remaining different tokens.
Canonical does not mean native. Native USDC is issued by Circle on that chain. PoS-USDC is a bridge-created representation backed by USDC held elsewhere. The canonical choice depends on the chain, the issuer, and the applications that have agreed to recognize it.
The reason is simple: a bridge cannot move the same ledger entry from Ethereum to Polygon. It must either lock or burn the source tokens and then unlock or mint an equivalent balance on the destination chain.
- You choose the source chain, destination chain, asset, amount, and recipient.
- The bridge identifies the approved token mapping and destination contract.
- Your wallet approves the source token and calls the bridge or token pool.
- The source contract locks or burns the tokens and emits a transfer message.
- A verifier, oracle network, or bridge relay confirms the source event.
- The destination contract unlocks or mints the mapped representation.
In a lock-and-mint route, the original tokens remain in a custody contract on the source chain. The destination token is an IOU backed by that locked balance. In a burn-and-mint route, the source supply is destroyed and the destination supply is created. Across all supported chains, the intended total supply stays constant.
Circle’s Cross-Chain Transfer Protocol is the clean example. USDC is burned on the source domain. Circle’s attestation service signs the resulting message. A destination contract verifies it and mints native USDC to the recipient. No bridge liquidity pool or wrapped USDC is required.
Why ecosystems choose one representation
Canonicality gives applications a stable identity to integrate. A lending market can whitelist one contract. A decentralized exchange can build liquidity around one pair. Wallets, portfolio trackers, price feeds, and risk systems can index the same address instead of guessing which bridged version a user holds.
It also prevents liquidity from splitting across lookalike assets. Suppose three bridges each create a different Ethereum-to-Polygon USDC wrapper. Each pool has less depth. Prices can diverge. A lending protocol must decide which wrapper is safe. A user may receive a token that looks correct but cannot be deposited into the intended application.
Canonical routes also make the exit path easier to reason about. If the destination token is the official representation, the ecosystem normally documents which contract burns it, which contract unlocks the underlying asset, and which messages the receiving chain accepts. That does not remove bridge risk. It makes the trust and accounting model visible.
The trade-off is that canonical bridges can be slower. An optimistic rollup may require a challenge window before a withdrawal is final. A validity-proof system may have different confirmation and proving delays. A native issuer route may require a destination transaction after the source burn. Canonical is a provenance and integration decision, not a promise of speed.
For route-level context around Paraswap, see paragraph.com.
What changed in 2026
The important change this year is wider use of issuer-controlled, burn-and-mint infrastructure alongside older lock-and-mint bridges. Circle’s CCTP documentation now covers additional domains, including Injective and Pharos. Chainlink CCIP expanded to Mova and continued adding tokens to its Cross-Chain Token system.
The practical effect is more choice between a bridge-issued wrapper and a token issuer’s own cross-chain representation. Chainlink’s CCT design supports burn-and-mint, lock-and-mint, burn-and-unlock, and lock-and-unlock through token pools. The ERC-7802 proposal is also pushing toward common cross-chain mint and burn entry points for ERC-20 tokens. These developments reduce interface fragmentation, but they do not make every address carrying the same ticker interchangeable.
WalletConnect Protocol belongs to a different layer. It connects a wallet to the application and carries transaction requests for signing. It does not decide which USDC contract is canonical, verify a bridge message, or guarantee that the destination application accepts the token.
Which route should you use?
Start with the destination application, not the bridge brand. The fastest path from decision to completion is to confirm the exact token contract that application accepts, then choose the route that delivers that contract.
- Check the source and destination chain names before approving anything.
- Compare the token contract address, not just the symbol or logo.
- Use a native burn-and-mint route when the issuer supports it and the destination app accepts native tokens.
- Use the ecosystem’s canonical bridge when the asset is tied to a rollup or chain-specific mapping.
- Choose a liquidity bridge only when its destination representation is explicitly supported.
- Compare finality, fees, slippage, destination gas, and the return route before signing.
FAQ
Is a canonical token the same as a native token?
No. A token can be canonical for an ecosystem while still being minted by a bridge. “Canonical” describes recognition and route authority. “Native” describes where the asset was issued.
Should you always use the canonical representation?
No. Use the representation required by the application receiving the funds. A faster liquidity route can be sensible when it delivers an accepted token and its bridge assumptions are clear. If the route produces an unfamiliar wrapper, the apparent speed is usually not worth the integration problem.