Bridges, burn-and-mint, and liquidity networks: how value crosses chains

Ahmed Azab

Co-founder and Chief Technology Officer

Jun 8, 2026

Blockchains don't talk to each other. A USDC balance on Ethereum has no native way to become a USDC balance on Solana - every "cross-chain transfer" is a construction that makes it seem to move, and every construction answers the same question differently: who do you trust to attest that value left chain A before it appears on chain B? Get that question right and the rest of the design follows. This is the engineer's guide to the three mechanisms in production, what each one trusts, how each one has failed, and how a settlement layer decides which to use - per token, per chain pair, per ticket.

Mechanism 1: lock-and-mint bridges

How it works. You deposit tokens into a contract on the source chain; a bridge system observes the deposit and mints a wrapped representation on the destination chain. To go back, you burn the wrapped token and the bridge releases the original.

What you trust. The bridge's own verification layer - a validator set, a multisig, or an oracle network 0 that decides whether a deposit "really happened." Critically, this trust layer is separate from the two chains it connects, and usually smaller and less battle-tested than either.

How it fails. The locked collateral is a vault, and vaults get robbed. Chainalysis counted roughly $2 billion stolen from cross-chain bridges in 2022 - 69% of all crypto stolen that year. Ronin lost about $625 million when five of nine validator keys were compromised; Wormhole lost roughly $320 million to a forged signature verification; Nomad lost $190 million to a flawed upgrade that let anyone replay withdrawals. Note the pattern: none of these broke a blockchain. Each broke the layer that decides who gets to say a deposit occurred.

Second-order cost. Wrapped assets fragment liquidity further - a bridged USDC.e is another token in the N×N matrix, not a solution to it, and it carries the bridge's credit risk forever.

Mechanism 2: burn-and-mint (native issuance transfer)

How it works. The token's issuer burns tokens on the source chain and mints native tokens on the destination - no wrapping, no locked pool. Circle's Cross-Chain Transfer Protocol (CCTP) is the reference implementation: burn USDC on chain A, an attestation service signs the burn message, native USDC is minted on chain B. Live since 2023; the second version added fast, near-final transfers.

What you trust. The issuer you already trusted by holding the token - plus its attestation service. The trust surface collapses from "a separate bridge system" to "the entity whose liability you already hold." There is no vault to drain because nothing is locked; supply on every chain is issuer-controlled and canonical.

Where it stops. It works only for that issuer's token, on the chains that issuer supports. It solves one row of the matrix - beautifully - and says nothing about moving between different tokens, or to a chain the issuer hasn't deployed on. As more regulated local-currency tokens launch on their own chosen chains, the number of rows grows; burn-and-mint per issuer doesn't connect them.

Mechanism 3: liquidity networks

How it works. Pools of the same asset sit on both chains; a transfer is settled by paying out from the destination pool and rebalancing later, netted against flows in the other direction. No wrapped asset, no waiting for source-chain finality before the user sees funds.

What you trust. The pool operator's solvency and the rebalancing mechanism - plus, at size, the depth of the pool itself.

How it fails. Quietly, by running dry. Liquidity networks are bounded by pool depth, and thin pools mean slippage or outright failure for large tickets. For dollar tokens on major chains that's rarely binding; for non-USD tokens with thin markets it's the constraint that decides whether the route exists at all.

The comparison

	Lock-and-mint bridge	Burn-and-mint (issuer)	Liquidity network
Trust surface	Separate bridge validators/multisig	The issuer + attestation	Pool operator + pool depth
Wrapped asset?	Yes	No - native on both sides	No
Honeypot?	Yes - locked vault	No	Pools, but no wrapped IOU
Historical failure mode	Key/verifier compromise; $2B stolen in 2022	None comparable to date	Depth exhaustion, slippage
Scope	Any token the bridge lists	One issuer's token, its chains only	Assets with pools on both chains
Speed	Varies; may await confirmations	Minutes; fast-finality variants seconds	Near-instant, depth permitting
Best for	Last resort; long-tail chains	Same-token moves where issuer supports both chains	Fast moves within depth limits

The dimension bridges don't touch: finality

Every mechanism inherits a subtler risk - finality on the source chain. If a transfer is attested before the source-chain block is truly irreversible, a reorg can leave value minted on the destination against a burn that "un-happened." Serious implementations wait for source finality or price the risk explicitly (fast transfers are a fee for the provider taking it). Settlement infrastructure moving real money should treat finality thresholds as a per-chain policy, not an afterthought - the same discipline as treating settlement as executed, not merely instructed.

How a settlement layer chooses

None of the three is "the answer"; the answer is a routing policy. In practice it reads like this: prefer burn-and-mint whenever the same issuer's token is being moved between two chains it supports; use deep liquidity networks for fast moves within depth limits; use lock-and-mint bridges only as a last resort, only for pre-approved bridges, with exposure caps and monitoring; enforce per-chain finality thresholds; and evaluate every route per token, per chain pair, per ticket size - because a mechanism that's ideal for a $5,000 USDC move can be the wrong one for a $2 million euro-token move on a chain with thin pools.

That routing discipline is a large part of what "chain-agnostic" actually means when a settlement layer says it. Not indifference to chains - the opposite: enough knowledge of each chain's issuers, pools, bridges, and finality that the customer never has to have any.

Frequently asked questions

Are cross-chain bridges safe?
Lock-and-mint bridges have been crypto's single most exploited component - roughly $2 billion stolen in 2022 alone per Chainalysis. Burn-and-mint transfers by the issuer and depth-bounded liquidity networks carry materially different, generally lower, risk profiles.

What is the difference between a bridge and CCTP?
A lock-and-mint bridge holds your tokens in a vault and issues a wrapped copy elsewhere. CCTP has the issuer burn native USDC on one chain and mint native USDC on another - no vault, no wrapped token, and the only trust is the issuer you already held.

What is a wrapped token?
A destination-chain representation of an asset locked on another chain by a bridge. It carries the bridge's risk and fragments liquidity - it is not the same as the native asset.

Why does finality matter for cross-chain transfers?
If value is minted on the destination before the source-chain transaction is irreversible, a chain reorganization can leave the system over-issued. Robust transfers wait for finality or explicitly price the risk.

Which is best for stablecoin settlement?
A routing policy, not a single mechanism: issuer burn-and-mint where available, liquidity networks within depth limits, vetted bridges only as a capped last resort - chosen per token, chain pair, and size.

Sources

Ahmed Azab

Co-Founder & CTO of Thiqwave. Fifteen years building banking software; ran engineering and DevOps at Arab African International Bank and large-scale systems for the Saudi market. MSc Computer Science, Lebanese American University.