Bridge Designs: Lock-and-Mint, Burn-and-Mint and Native Issuance

2026-08-12

Moving a token to another chain does not move the token. It stays where it was, and something new appears on the other side. What that new thing is depends on the design: a redemption claim on locked collateral, the same supply reissued elsewhere, or a token the issuer minted on that chain directly. This article compares the three and shows how to tell which one you hold.

What a bridge does to your token

A blockchain cannot send anything to another blockchain. Each network writes only its own ledger. A bridge coordinates two separate bookkeeping events: one on the chain you left, another on the chain you arrive at.

The units that appear on the destination chain are new entries, created by whatever contract is allowed to create them. So the question is not where your token went, but who issued the thing you hold and what you can redeem it for.

Ethereum's developer documentation lists three ways to move assets across chains: lock and mint, burn and mint, and atomic swaps. An atomic swap is a trade with a counterparty rather than an issuance model, so what you hold comes from the first two, plus native issuance by the asset's own issuer.

A second question cuts across it: who runs the bridge. A network usually ships one of its own, governed alongside the chain, and what it mints becomes that chain's designated version of an asset. Anyone else can build a bridge to the same chain. Identical mechanics, two different tokens.

That is what catches people out. Two balances with the same name and symbol, on the same chain, can be separate assets with separate backing and separate ways to fail.

Lock-and-mint and the wrapped token it produces

Lock-and-mint is the oldest design. You hand the asset to a contract on the source chain, which holds it, and a paired contract on the destination chain mints a new token for the same amount. Documentation for one widely used cross-chain token standard puts it plainly: the original is locked on its issuing chain, and a fully collateralised wrapped token is minted on the destination.

The return leg is the mirror image, burn and unlock. You destroy the wrapped token, which authorises the source-chain contract to release the original. The wrapper is not valuable in itself. Its value is the promise that the release happens when asked for.

Bridges that ship with a network work this way. Public documentation for one rollup's standard bridge spells out both halves: native tokens are locked and bridged representations minted, and bridged representations are burned so native tokens can be unlocked. The bridged representation is an ordinary token contract whose mint function only the bridge may call.

The consequence deserves no hedging: a wrapped asset is not the asset. Ethereum's own introduction to bridges says so directly. A wrapped coin held on Ethereum is a token native to Ethereum, a version of that coin rather than the original on its own chain. It trades close to the original because redemption works, not because the two are the same object.

Burn-and-mint and why the total stays the same

Burn-and-mint skips the escrow. What you send is destroyed on the source chain and an equal amount created on the destination chain, so the token's total supply across all chains stays constant. There is no locked pool, because nothing was set aside. The supply itself moved.

This works only if both sides can mint and burn on the instruction of whoever runs the transfer. A token whose whole supply was minted once, on one chain, with no mint function left open, cannot do it at home. The usual answer is a hybrid: lock-and-mint outward, burn-and-unlock back, and burn-and-mint for hops between the other chains, where the units are already mintable.

For the holder the risk changes shape rather than size. There is no escrow to drain, but there is a mint permission, and whoever holds it can create supply out of nothing. Serious implementations therefore pair that right with a rate limit: a ceiling on how much a bridge may mint or burn, refilled over time at a set rate, so a failure is bounded.

Note what the mechanism leaves open. It says nothing about who holds the permission, and behaves the same whether that is the issuer, a bridge operator, or a committee in between. The next two sections are about that question.

Native issuance, where the issuer mints on every chain

Native issuance is burn-and-mint run by the issuer itself. The issuer deploys its token on each chain it supports and mints there directly, so there is no wrapper and no collateral pool anywhere. Protocol documentation for one large issuer describes exactly that: burn on the source chain, mint on the destination, with no wrapped tokens and no bridge liquidity pools.

Trust does not vanish, it changes address. With a wrapper you are exposed to whoever holds the escrow and the mint key. With native issuance you are exposed to the issuer, equally on every chain, which is the exposure you already had where you started. For an asset that is somebody's liability anyway, that is a real simplification. For an asset that is nobody's liability, there is no issuer to do it.

The limit is availability. Only the issuer can mint natively, and only where it chose to deploy. Everywhere else the asset arrives as somebody's wrapper, and where the issuer deployed late, the older wrapper usually keeps circulating beside the native version as a separate token.

Omnichain token standards and who controls the mint

Newer standards make multi-chain issuance a property of the token rather than a feature of a bridge. One family, described as omnichain fungible tokens, extends an ordinary token standard with cross-chain messaging: a transfer debits the source chain by burning or locking and credits the destination by minting or unlocking, so a single total supply is shared across every chain. An existing token joins through an adapter that acts as a lockbox.

A second approach takes on the permission question directly. ERC-7281, also known as xERC20, is a minimal extension to the fungible token standard: a mint and burn interface callable only by bridges on the issuer's allowlist, a configurable rate limit for each, and a lockbox so an existing token can adopt it without starting over. Its stated purpose is to move ownership of a bridged token from bridges to issuers.

What that buys, in the proposal's own framing, is containment. If a listed bridge is compromised, the loss is capped at its limit and the issuer can delist it without dragging users through a migration. Because limits are per bridge and revisable, bridges compete on security to be trusted with a larger one.

What it does not buy is safety. The author says so plainly: the standard bounds the fallout but does not save anyone from a broken bridge, and bridge security still has to be fixed underneath. It also assumes an issuer with a governance process to maintain the allowlist, which suits a token with a project behind it and does nothing for one with nobody in charge.

Bridge Designs: Lock-and-Mint, Burn-and-Mint and Native Issuance-bitbase-8085

Working out which one you hold

None of this shows in the ticker. It shows in the contract address, which is the part that cannot be dressed up. Same symbol, same chain, different address means a different asset with different backing.

Documentation for a standard rollup bridge is unusually blunt: one native token may have more than one bridged representation at the same time, different representations count as entirely independent tokens, and users must always specify which one they mean. Nothing forces them to be worth the same.

That is why networks publish curated token lists, and why the same documentation warns that using the wrong bridged address can lock the underlying asset up permanently. The list is not a convenience feature. It is the mapping between a name you recognise and the contract the network's own bridge will honour.

Three questions cover most cases. For a wrapped token: what is locked, where, and who can release it. For a burn-and-mint token: who may call mint, and what caps them. For a natively issued token: is this chain's deployment really the issuer's.

Then check where the depth is. Liquidity attaches to a representation, not to a name, so a wrapper that few venues quote cannot be sold at the price of the version everyone uses. Fixing that fragmentation is the reason both standards above give for existing.

The bottom line

Bridging does not move a token: it retires units on one chain and creates units on another, and the design decides what those units are. Lock-and-mint leaves you with a redemption claim on collateral in an escrow contract. Burn-and-mint moves the supply itself, so your safety is the safety of a mint permission and its rate limit. Native issuance removes the wrapper by having the issuer mint on each chain, and works only where the issuer went. The standards layered on top exist so that issuers rather than bridges decide which of these you get. Whichever it is, the answer is in the contract address, not the symbol.

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.