Burn-and-Mint Token Pool

Overview

In a burn-and-mint transfer, the user sends tokens to a protocol contract on the source chain. The contract destroys or permanently removes those units and emits evidence of the burn. A cross-chain messaging system verifies the event and authorizes minting of the corresponding amount on the destination chain.

The model differs from lock-and-mint bridging. No reserve of the source token remains locked to back the destination supply. Instead, the issuer or protocol maintains one logical supply distributed across networks.

Correct accounting requires global coordination. If a message is replayed or forged, the destination can mint unbacked units. If a valid burn is not delivered, the user can lose access until the message is retried or recovered. Rate limits can reduce damage from a compromised chain or messenger.

Token contracts need carefully restricted mint and burn roles. Upgradeable pools and message receivers add governance risk. The protocol should bind each transfer to source chain, destination chain, recipient, amount, nonce, and token identity.

Applications should track source burn, message status, destination mint, and finality separately. A successful burn does not mean the destination mint completed.

A burn-and-mint pool improves cross-chain supply efficiency and avoids large locked reserves, but it concentrates importance in cross-chain verification and mint authorization.

Global supply reconciliation should compare every confirmed source burn with one authorized destination mint. Delayed or reverted messages need exception queues rather than manual supply adjustments. Independent monitoring can detect supply drift before it becomes large enough to undermine confidence in the token’s cross-chain equivalence.

Related products such as Token Pool and Lock-and-Mint Token Pool should not be grouped automatically with Burn-and-Mint Token Pool. Their legal rights, custody model, market liquidity, and technical identifiers can differ.