How Do Blockchain Bridges Work? Lock-Mint, Burn-Mint, and Who You're Trusting

You've used a bridge every time you moved funds onto an L2, and probably several times since without thinking about it. But "bridge" is a single word covering several genuinely different mechanisms, and the differences matter — bridges have been the single largest source of losses in crypto, because the mechanism you pick decides who you're trusting. This post explains what a bridge actually does, the main designs, and the one question that determines whether a bridge is safe.

Why bridging is hard at all

A token on Ethereum can't "move" to another chain. Ethereum has no idea another chain exists, and vice versa — each chain only knows its own state. So an asset never physically travels. Instead, every bridge is some scheme for two things:

1. Prove that something happened on the source chain (you deposited or locked funds).
2. Act on the destination chain in response (release or mint funds to you).

The entire design space of bridges is different answers to "how do we prove step 1 to chain 2, and who do we trust to do it?" Everything else is detail.

The main mechanisms

Lock-and-mint

The most common third-party design. You lock the real asset in a contract on the source chain, and the bridge mints a wrapped representation on the destination chain. To come back, you burn the wrapped token and the original is unlocked.

The wrapped token is an IOU: USDC.e or a bridged WETH is only worth anything because collateral sits locked on the other side. This is powerful — you can represent any asset anywhere — but it means the wrapped token's value depends entirely on the bridge staying solvent and honest. If the lock contract is drained, every wrapped token it backed becomes worthless.

Burn-and-mint

Some assets are issued natively on multiple chains by the same issuer. Here there's no wrapping — you burn the token on the source chain and the issuer mints the equivalent native token on the destination. Circle's cross-chain transfer for USDC works this way, as do "omnichain" token standards. The result is one canonical asset everywhere instead of a patchwork of wrapped IOUs, which avoids the "which bridged USDC is this?" problem.

Liquidity-pool bridges

The "fast bridge" model (Across, Hop, Stargate, and similar). Instead of minting anything, the bridge keeps liquidity pools on both chains. You deposit on chain A, and a relayer immediately pays you out of the pool on chain B, then the pools rebalance in the background. You get near-instant transfers because nobody waits for a mint — you're just being paid from pre-positioned liquidity. The trade-off is that these bridges are limited by pool depth and charge a fee for the service.

Canonical (native) rollup bridges

Every rollup has an official bridge between it and its L1. Depositing from L1 to the L2 is usually fast. Withdrawing back is where the rollup's finality model shows up:

• Optimistic rollups (Arbitrum, Base, Optimism) make you wait a challenge window — around 7 days — before a trustless withdrawal completes, because the system has to allow time for someone to dispute the state.
• ZK rollups (Linea, Scroll, zkSync) settle via validity proofs, so there's nothing to dispute — withdrawals finalize as soon as the proof is verified on L1, no multi-day window.

That difference is the practical face of soft vs hard finality: the canonical bridge is exactly where "the sequencer said so" versus "Ethereum proved it" becomes real money you can or can't withdraw. (This is also why "fast bridges" exist — they front you the liquidity so you don't have to wait out the challenge window.)

The question that actually determines safety

Here's the part that matters. All of the above still rests on step 1 — proving to the destination chain that something happened on the source chain. How that proof is verified is where bridges live or die:

• External validators (multisig / MPC). A set of off-chain signers watches the source chain and attests to the destination. Fast and flexible, but you're trusting that signer set. This is the design behind the largest bridge hacks in history — compromise enough keys and you can mint unbacked tokens or drain the lock contract. When you read that a bridge lost hundreds of millions, it was almost always this.
• Light-client / native verification. The destination chain verifies a cryptographic proof of the source chain's state directly, trusting no external party — only the source chain's own consensus. This is the most secure design and the hardest to build. Some omnichain systems approximate it with a threshold-signature validator set that custodies assets on external chains (ZetaChain's approach to native Bitcoin is an example of pushing toward native verification of an external chain).
• Optimistic verification. Assume the cross-chain message is valid, but allow a challenge window in which a watcher can prove fraud. Cheaper than full verification, at the cost of a delay.

So the useful question when you look at any bridge isn't "how fast is it?" — it's "who verifies the cross-chain message, and what happens if they're wrong or compromised?" Canonical rollup bridges and light-client bridges inherit the security of the chains themselves. External-validator bridges are only as safe as their signer set.

The developer's view

If you're building something that reacts to a bridge — crediting a deposit, triggering a downstream action — the mechanics come down to watching events and respecting finality:

• Watch the bridge contract's events. Deposits and withdrawals emit logs; you track them with eth_getLogs or a subscription on the bridge contract, the same way you'd index any contract.
• Never credit a deposit before source-chain finality. This is the cardinal rule. If you act on a deposit that later disappears in a reorg, you've paid out real value against nothing. Wait for the source chain's finalized tag (or enough confirmations), exactly as in handling chain reorgs. Reading the deposit's transaction receipt confirms it succeeded — but "mined" still isn't "final."
• Canonical withdrawals need a proof step. Withdrawing from a rollup usually involves submitting a proof on L1 after the challenge/proof window; that's a second transaction on the destination chain, not an automatic credit.

None of this needs special RPC methods — it's standard eth_* against both chains, one endpoint per chain.

The takeaway

A bridge never moves an asset; it locks or burns on one side and mints or releases on the other, and the only thing standing between you and a loss is how the cross-chain message gets verified. Wrapped tokens are IOUs backed by locked collateral. Canonical rollup bridges inherit the L2's finality model — instant-ish on ZK, a challenge window on optimistic. And the security question is always the same: who attests that the source-chain event really happened? Answer that, and you understand the bridge.

Building across chains? SwiftNodes gives you the same endpoint format for 60-plus chains behind one key — sign up and point each client at https://rpc.swiftnodes.io/rpc/<chain>?key=YOUR_API_KEY, from Ethereum to every L2 you're bridging between.