Bridges Explained: Lock-and-Mint vs Burn-and-Mint vs Liquidity Network
There are three common bridge architectures. Each has different security and speed properties. Here is when to prefer which one.
A bridge moves value from one blockchain to another. The interesting fact is that 'moving value' is a misnomer — value never literally crosses chains. What actually happens is one of three patterns: the asset is locked on the source chain and a wrapped representation is minted on the destination, the asset is burned on the source chain and a fresh asset is minted on the destination, or the user trades into a pool on the source chain and out of a pool on the destination. The pattern in use determines security, speed, and cost.
Lock-and-Mint
- Mechanism: deposit ETH on Ethereum into a bridge contract — the contract locks it; on the destination chain, the same bridge mints wETH-bridged tokens
- Examples: original Multichain bridge, Wormhole's wrapped assets, Axelar wrapped assets
- Trust assumption: the destination wrapped token is only redeemable if the source contract honours the burn — a multi-sig or validator set must remain honest
- Speed: depends on confirmation time on the source chain plus relayer dispatch time — typically 5-30 minutes
- Failure mode: bridge multi-sig compromised — wrapped tokens become unredeemable; happened in Ronin (2022), Nomad (2022), Multichain (2023)
Burn-and-Mint
- Mechanism: native asset on source chain is burned, native asset on destination chain is minted — no wrapped representation in either direction
- Examples: USDC's CCTP (Circle Cross-Chain Transfer Protocol), native LayerZero OFTs, native USDe on chains supported by Ethena
- Trust assumption: the issuer (Circle, Tether, Ethena) is the trust root — they verify the burn before minting
- Speed: typically 10-15 minutes including the source chain finality requirement
- Strength: single representation of the asset across chains — no wrapped-vs-native confusion, no liquidity fragmentation
Liquidity Network (Atomic Swap)
- Mechanism: source-chain pool of asset A and destination-chain pool of asset A — user deposits to one, withdraws from the other
- Examples: Across, Stargate, Hop, Synapse — and increasingly the dominant pattern for bridge UX
- Trust assumption: the pool's solver/relayer set must be honest, but the user has source-chain recourse if the destination payment is delayed
- Speed: 30 seconds to 2 minutes on most pairs — by far the fastest pattern
- Cost: pool fees plus a relayer fee — typically 5-15bps for the bridged amount; cheaper than wrapped-asset paths
Which Pattern to Use
- For USDC: always use CCTP (burn-and-mint) — single canonical USDC across chains
- For USDT: prefer Layer Zero OFT or native if available, otherwise Stargate
- For ETH: liquidity networks (Across, Stargate) for speed; canonical bridges only when entering a major L2 (Optimism, Arbitrum)
- For long-tail tokens: liquidity networks if available; otherwise project-issued canonical bridge
- Never use a bridge whose validator set is unfamiliar or whose audit history is thin — bridge hacks are the largest single-source loss in DeFi history
How Steyble Routes
Steyble's cross-chain swap routes through whichever bridge type produces the best combination of speed, cost, and security for the requested asset. CCTP is preferred for USDC, OFT for compatible tokens, and Across/Stargate for everything else. The user sees a single quote with the bridge type explicit — no opaque routing, no hidden risk.