Interoperability & cross-chain

burn-and-mint

Burn-and-mint moves a token between chains by destroying it on the side you leave and re-creating it on the side you arrive, so that the same token exists natively on every chain rather than as a stack of wrapped IOUs. When you send tokens from chain A to chain B, the bridge burns your tokens on A (removing them from A's supply) and mints an equal amount on B. The global supply summed across all chains stays constant; you have not created a claim on a locked pool, you have relocated real units.

The advantage over lock-and-mint is that there is no single honeypot of locked collateral and no fragmentation into many incompatible wrapped versions. There is one canonical token, and its issuer (or a permissioned set of bridge contracts) holds mint authority on every chain. Circle's Cross-Chain Transfer Protocol for USDC works this way: USDC is burned on the source and freshly minted on the destination, keeping a single native USDC everywhere instead of dozens of bridged variants. Many 'omnichain fungible token' standards adopt the same pattern.

The trade-off moves the trust to mint authority rather than to a vault. Whoever can mint on the destination is effectively trusted not to mint without a matching burn; a bug or compromise there inflates the token's supply directly. Burn-and-mint therefore suits assets with a clear issuer who legitimately controls supply across chains (a stablecoin, a project's own token), and is a poor fit for assets like native BTC that no on-chain party is allowed to mint.

Lock-and-mint vs burn-and-mint is a choice of where the danger lives: a pile of locked collateral that can be stolen, or a mint key that can over-issue. Neither removes trust; they relocate it.