Choose a token model by deciding where its supply should live. If users should hold the same asset across chains, compare how each design keeps balances backed and reconciled; if they only need to move an existing asset, a bridge may be enough.
What changes when a token moves between chains?
A cross-chain transfer starts on one network and completes on another through a message that triggers a token action. The source contract locks or burns tokens, the message carries the amount and recipient, and the destination contract releases or mints tokens after the message is verified.
That final action determines the supply model. With lock-and-release, tokens stay in a pool on one chain and are released from a pool on another, so both pools need enough liquidity. With burn-and-mint, tokens are destroyed on the source and created on the destination, so the token issuer must authorize the contracts to burn and mint.
For example, imagine a game studio with players on two chains. If it wants a single in-game currency that can be used on either chain, an omnichain fungible token (OFT) can coordinate supply through burn-and-mint transfers. If players only need to move existing tokens between networks, a bridge may suit the narrower task.
Which model fits your token and liquidity?
Match the transfer design to the token’s permissions and where you can keep funds available:
- Lock and release: Use when the token cannot be minted or burned. Each destination pool needs liquidity ready to release.
- Burn and mint: Use when the issuer can grant trusted pool contracts burn and mint permissions. It avoids holding destination-side reserves, but requires careful role management.
- Lock and mint, then burn and unlock: Use when one chain is the token’s home. Remote representations are minted there and burned when users return tokens to the home chain.
Suppose the studio cannot change its token contract and has a fixed amount of tokens already issued. Lock-and-release may fit, but it must fund destination pools and monitor their balances. If it controls minting on every chain and wants supply to follow users, burn-and-mint avoids that liquidity work.
What should you verify before choosing?
Check token permissions, pool liquidity, decimal settings, and the behavior when a destination transaction fails. A decimal mismatch can produce an incorrect amount, while a missing mint or burn role can stop destination execution. Test a small transfer in both directions and reconcile the source and destination balances before relying on the setup.
The same checks help compare omnichain systems: each coordinates cross-chain state and token movement through messages, but the contracts and liquidity model still decide what happens to supply. For the separate question of how omnichain messages are checked, timed, and priced, the related guide covers the full process. Start by writing down whether your token can mint and burn, then choose the model that meets that requirement with the least liquidity overhead.