Lock-and-mint preserves a fixed supply; burn-and-mint moves supply between chains. The right choice depends on where tokens must be available, how the supply is controlled, and whether the destination can mint them.
Suppose you are launching a token on two chains and want holders to move it between them without relying on a separate pool of user-funded liquidity. If balances should act as one coordinated supply, consider the omnichain approach. Before choosing a design, trace what happens to one token on the source chain, during message delivery, and on the destination.
Lock-and-release fits fixed-supply tokens with funded pools
Lock-and-release holds tokens in a source-chain pool, then releases tokens already held in a destination-chain pool. The token supply stays constant; tokens move between users and pools. Chainlink CCIP documents this as a lock-and-release token pool pattern.
Choose this when the token cannot mint or burn, or when its issuer requires a fixed supply. It can also suit a deployment where destination reserves are deliberately managed. It does not fit well if those reserves may run short: a valid transfer message cannot release tokens that the destination pool does not hold.
For example, if a user sends 100 tokens from Chain A to Chain B, Chain A’s pool locks 100. Chain B’s pool releases 100 it already holds. Someone must have placed those tokens on Chain B in advance, and the deployment needs a way to rebalance reserves when transfers mostly go in one direction.
Lock-and-mint suits an existing token with a mintable counterpart
Lock-and-mint locks the source token and mints a corresponding representation on the destination. On the return trip, the destination token is burned and the source pool releases the original. Chainlink CCIP describes a setup using a lock-and-release pool on one chain and a burn-and-mint pool on the other; the pools must be configured to work together.
This option fits a project that already has a canonical token on one chain but wants users to access tokens elsewhere without preloading each destination with reserves. It also suits issuers who want the original asset held in custody while destination balances circulate. It does not fit if the issuer cannot safely authorize minting and burning, or if users expect the destination token to be independently redeemable without the bridge.
The operational cost is trust and coordination: pool contracts, token permissions, and message handling all affect whether the wrapped balance is backed and redeemable. Before deployment, check who can change those permissions and what happens if one chain pauses or a message remains unexecuted.
Burn-and-mint suits one supply shared across chains
Burn-and-mint destroys tokens on the source chain and mints the equivalent on the destination. No reserve pool needs to hold tokens for payouts; the issuer must authorize the relevant contracts to burn and mint. LayerZero’s Omnichain Fungible Token (OFT) standard is one example of this model.
Choose this when you control the token contracts and want supply to move between chains as a single coordinated balance. It is a poor fit for an immutable third-party token that cannot grant those permissions, or for a design where each chain’s supply must remain separately backed by local reserves.
Check decimal precision before connecting chains. As an example, an 18-decimal token using a six-decimal shared representation may discard amounts smaller than 0.000001 token on transfer. LayerZero documents this rounding as “dust”; test the exact received amount, especially for small transfers and contracts that assume every unit arrives unchanged.
Compare the full transfer path before choosing
For a token meant to circulate across chains as one supply, I would start with burn-and-mint if the issuer can safely grant those permissions. If the token cannot mint or burn, check whether the team can maintain destination reserves; if it can mint only a representation, examine lock-and-mint. These mechanisms support an omnichain design when cross-chain messages keep token supply coordinated.
- Token permissions: can the bridge contracts lock, release, burn, and mint as required?
- Supply accounting: which chain or contract defines the canonical supply?
- Destination availability: does a transfer depend on tokens already being in a pool?
- Precision: what amount arrives after decimal conversion and rounding?
Then trace a transfer in both directions, including a delayed message, a paused destination, and a small amount near the precision limit. The next step is to match those results to your token’s permissions and supply rules before selecting a pool or token standard.
Does burn-and-mint create extra supply?
It should not when the source burn and destination mint are part of one correctly enforced transfer flow. The source balance is destroyed before the destination balance is created. Review the contracts’ permissions and message execution rules, since a misconfigured or compromised system could break that accounting.
Is lock-and-mint the same as a wrapped token?
It commonly creates a wrapped or representative token on the destination, backed by the source tokens held in a pool. The important question is how redemption works: the destination representation should be burned before the original is released. Confirm that the pool and token contracts enforce this path.
What happens if a destination pool runs out of tokens?
In a lock-and-release design, the pool cannot release more tokens than it holds, so a transfer may be delayed or fail until liquidity is replenished. Lock-and-mint and burn-and-mint can avoid that particular reserve shortage, but they depend on mint permissions and successful message execution.
Which option works for an existing token I do not control?
Usually, you cannot use burn-and-mint unless the issuer authorizes the bridge to burn and mint. If the token supports transfers but not those permissions, a lock-and-release pool may be possible, provided the pools can be funded and operated. Check the token’s contract capabilities and the bridge’s accepted configuration before deciding.