A source burn reduces that chain’s supply; a matched destination mint raises the other’s. The accounting is local to each chain, so a destination balance can increase while the aggregate supply of the bridged token stays level. That distinction helps when a transfer is pending: the source transaction may have changed supply even though the destination has not minted anything yet.
What does burn-and-mint change about supply?
In a burn-and-mint transfer, an authorized bridge contract destroys a specified amount on the source chain, then a contract on the destination chain creates the corresponding amount. Unlike lock-and-mint, the source tokens are not held in a vault; the bridge relies on its message and mint authority to make the destination issuance valid. The destination token may be the same cross-chain asset under a shared supply design, or a chain-specific representation whose value depends on the bridge’s rules.
When you use a cross-chain service such as ParaSwap cross-chain swaps, read the source burn as one leg of the transfer, not proof that the destination balance already exists. ParaSwap is a cross-chain bridge and swap service: it lets you move assets across chains and swap into an asset on the destination chain in one flow. Ethereum.org’s glossary defines minting as creating tokens and bringing them into circulation; here, the key question is which chain’s supply is being counted.
For a simple accounting check, suppose the source burns 100.00 units and the destination mints 99.80 after a 0.20-unit fee. The destination supply rises by 99.80, while the source falls by 100.00; the 0.20 difference must be accounted for as a fee, treasury allocation, or additional burn. If the bridge instead burns only 99.80 and handles the fee separately, compare the actual burn and mint events rather than assuming the entered amount is the minted amount.
What must happen between the burn and the mint?
The destination mint needs an authenticated message that identifies the source event, destination chain or domain, recipient, token, and amount. The bridge’s verification system waits for its configured source-chain finality condition, then authorizes a destination contract to mint; a relayer or user may still need to submit that message on the destination. EIP-7802, an Ethereum token interface proposal, reflects this separation by defining authorized cross-chain mint and burn entry points.
Finality is a protocol parameter, not a universal number of blocks. A bridge may require a fixed confirmation count, a finality signal, or an attestation from its verifier set. More conservative finality reduces the chance that a source reorganization invalidates the burn after minting, but it lengthens the pending period. A source transaction marked successful therefore establishes only that the burn executed on that chain; it does not establish that the required message is ready or that the destination mint succeeded.
Why can a confirmed transfer remain pending or fail?
A transfer can pause after the burn while the verifier waits for finality, while the message is being relayed, or while the destination contract rejects or has not yet processed it. Common contract-level causes include a paused token, a mint cap, an outdated or revoked minter permission, a recipient restriction, or a mismatch in token decimals or amount encoding. If the destination chain is congested, the message may be ready but its execution transaction may still be absent.
Fees and token behavior complicate the arithmetic. A fee-on-transfer token can deliver less to the bridge than the transaction input suggests; rebasing tokens can change balances independently; and decimal conversion can round down when chains use different token precision. The bridge’s actual burn event and destination mint event are the useful accounting records. Don’t infer a supply error from wallet display rounding alone.
What should you check before trying again?
Start with the source transaction receipt: confirm that it succeeded, identify the burned token and amount in its logs, and note any message identifier or nonce. Then check that message’s state in the bridge’s own status source, if available, and look for a destination transaction. If a destination transaction exists, inspect its receipt and mint event; a reverted mint and a successful mint require different next steps.
If the source burn succeeded but no destination execution appears, the transfer may still be waiting for finality or relay. Avoid starting a second transfer with the same intent until you know whether the original message remains executable; duplicate burns can create a second transfer rather than retry the first. If destination execution reverted, preserve both transaction hashes and the error details, then use the bridge’s documented recovery path for that specific message. Recovery rules vary: some systems allow a permissionless retry, while others require an authorized action.
Judge a burn-and-mint transfer by matching its finalized source burn to one successful destination mint, and account for any difference as an explicit fee or conversion rule.
Top comments (0)