How Bridges Move Value

You found a 1% gap: ETH is $2000 on Chain A and $2020 on Chain B. The trade is obvious — buy on A, sell on B. The problem is that A and B don’t share a ledger, don’t share a clock, and have never been introduced. To act on both sides you need to move value across the gap, and the thing that does that is a bridge.

A bridge is not a teleporter. It is a cross-chain messenger: it observes an event on a source chain and, on the strength of that observation, causes an action on a destination chain. Three canonical designs dominate — lock-and-mint, burn-and-mint, and liquidity networks — and by the end of this lesson you should be able to tell them apart at a glance and see the punchline they all share: under the hood, every single one is two transactions on two ledgers, never one atomic move.

Let’s build that up from the messaging layer.

The messaging layer underneath

Peel away the marketing and every bridge reduces to a cross-chain message: a statement of the form “this event happened on the source chain, therefore perform this action on the destination chain.” Lock happened on A → mint on B. Burn happened on A → unlock on B. Deposit happened on A → pay out on B. Same skeleton every time.

Precise definition. A cross-chain message is an assertion about source-chain state, delivered to the destination chain along with enough information for the destination contract to act on it. The hard part is not delivering the bytes — it’s getting the destination chain to believe them.

That belief is the whole ballgame, because Chain B cannot natively read Chain A’s state. So a bridge always has to answer one question: who attests that the source event really happened? The usual answers:

The wire-transfer analogy

Think of a wire transfer between two banks that don’t share a ledger. Your bank debits your account; the recipient’s bank credits theirs. But the credit only posts because someone vouched that the debit actually happened — a clearing network, a SWIFT message, a correspondent bank. The two banks never touch a common book; they trust an intermediary’s message. A bridge is the same shape: a debit on A, a credit on B, and an attestation in the middle saying “the debit is real, go ahead and post the credit.”

When it matters

The messaging layer is the thing you’re actually trusting when you bridge. As an arbitrageur, your capital is at risk not on the chains themselves but on the message between them — if the attestation set lies or stalls, your value is stuck in transit. Every design below is a different way of dressing up this same message, so knowing it’s there keeps you from confusing “wrapped token” or “LP payout” with the real risk surface.

Lock-and-mint (and burn-to-unlock)

Definition. A lock-and-mint bridge takes the native asset on the source chain, locks it in a custody contract, and mints a wrapped representation of it on the destination chain — a derivative token backed 1:1 by the locked original. To go back, you burn the wrapped token on B, which signals the custody contract on A to unlock the original. Lock to go, burn to return.

Worked example: bridging 100 ETH

You bridge 100 ETH from A to B through a lock-and-mint bridge.

The wrapped-ETH on B is worth one locked ETH on A — no more, no less. The invariant the bridge promises: wrapped supply on B = locked balance on A, always 1:1.

The fragmentation problem

Because anyone can stand up a lock-and-mint bridge, you end up with many non-fungible wrapped versions of the “same” asset: Bridge-X-ETH, Bridge-Y-ETH, Bridge-Z-ETH — all nominally “ETH on B,” none interchangeable, each backed by a different custody contract with a different trust set. Liquidity splinters across these variants, and a pool quoting “ETH” might mean any one of them. For an arbitrageur, this is a footgun: the “ETH” you sell on B might be a wrapped variant you can’t redeem through the bridge you used.

When it matters

Lock-and-mint is the most general design — it works for any asset, even one whose issuer has no idea the bridge exists, because it only needs a custody contract, not mint authority. That generality is why it’s everywhere, and why the fragmentation + custody-honeypot risks are everywhere too. As an arb, you reach for lock-and-mint when no native/canonical path exists, and you price in the depeg tail.

Burn-and-mint (canonical/native bridges)

Definition. A burn-and-mint bridge applies when a single entity controls mint authority on both chains — the asset’s issuer, or a rollup’s native bridge. Instead of locking the asset, it burns (destroys) the supply on the source chain and mints the canonical asset on the destination chain. What lands on B isn’t a wrapped derivative — it’s the real, issuer-blessed token, indistinguishable from any other unit of it. Total supply across chains stays constant: burn N on A, mint N on B.

Circle’s CCTP (Cross-Chain Transfer Protocol) does this for USDC: burn native USDC on A, attest the burn, mint native USDC on B. Rollup native token bridges work the same way for the rollup’s canonical assets.

Worked example: bridging $1,000,000 USDC via CCTP

No custody contract holds your million dollars; the supply on A simply ceases to exist and reappears on B. There is no second-class wrapped USDC to depeg — what you hold on B is the USDC.

Lock-and-mint vs burn-and-mint, side by side

When it matters

When a canonical/native path exists for your asset — native USDC via CCTP, a rollup’s native bridge for its own token — prefer it. You get the real asset and dodge the wrapped-derivative depeg tail. You can’t always get one (it requires issuer cooperation), which is exactly why lock-and-mint and the next design still exist.

Liquidity-network (“inventory”) bridges

Definition. A liquidity-network (or inventory) bridge does no minting whatsoever. Liquidity providers pre-fund inventory on both chains. When you deposit on A, the bridge immediately pays you out of its existing B-side inventory, then settles the A↔B imbalance later (often optimistically, with the relayer fronting capital and getting reimbursed once the A-side deposit finalizes). Think Across, Hop, Stargate-style designs.

The payoff: in the optimistic case you get paid on B without waiting for source-chain finality, because the LP is willing to front you against your deposit and eat the finality risk for a fee. The constraint: you can only be paid as much as the B-side inventory holds, and that inventory gets lopsided and must be rebalanced.

Worked example: bridging $1,000,000 with the canonical numbers

You move $1,000,000 (in USDC) from A to B through an inventory bridge that runs $2,000,000 of inventory on each side and charges a 0.05% (5 bps) fee.

• You deposit $1,000,000 on A.
• The bridge pays you $1{,}000{,}000 \times (1 - 0.0005)$, i.e. $999,500 out of its B-side inventory. The $500 is the bridge fee.
• B-side inventory drops from $2,000,000 to $1,000,000; A-side inventory rises (after your deposit finalizes) toward $3,000,000.
• The bridge is now $2,000,000 imbalanced and must rebalance — shuffle inventory back across, or wait for flow in the opposite direction — before it can serve another large A→B transfer.

This is how you operate

Here’s the part that matters for the rest of the course: a liquidity-network bridge is a cross-chain arbitrageur wearing a bridge costume. It holds inventory on both chains, pays out of local inventory for speed, and rebalances when it gets lopsided. That’s exactly the playbook a serious cross-chain arb runs — pre-position capital on both sides so you can act instantly, then rebalance. Lesson 4 is entirely about that inventory-and-rebalancing game; this design is your first look at it.

When it matters

Inventory bridges win when speed beats everything and the size fits the available inventory — which is most retail and small-arb flow. They lose on large transfers that blow past the destination pool, where you’ll hit rejects, slippage, or queues. And philosophically, they’re the model to internalize, because running your own cross-chain inventory is the endgame this course is building toward.

Why every design is two transactions on two ledgers

We’ve met three mechanisms that look very different — one locks, one burns, one just shuffles inventory. But zoom out and they share one settlement shape:

source transaction → (wait for finality) → relay/attestation → destination transaction

There is no atomic version of this on independent chains. On a single chain, a transaction either fully happens or fully reverts — that atomicity is exactly what makes single-chain flash-loan arb safe. Across two chains with separate consensus and no shared state, that guarantee evaporates. You commit the first leg, then you wait, exposed, hoping the second leg lands at a price you still like.

Walk the timeline

The hero visual below traces a single non-atomic cross-chain transfer through its stages — sell submitted on A → block inclusion → finality wait → bridge relay → buy executes on B — and lets you dial the two knobs that set your exposure window: how many confirmations you wait for, and how long the bridge relay takes.

Play with it using our canonical numbers: ~12 confirmations at ~12s/block is ~144s of finality, plus a ~90s bridge relay, gives an exposure window of ~234s (~4 minutes) and a total settlement near ~250s. Toggle the atomic baseline chip and notice it collapses to zero — because on a single chain there is no window. That gap is where everything in this course lives: at ~80% annualized volatility, ~4 minutes of drift is roughly ±0.2%, which can quietly eat a fifth of your 1% gap before your second leg even fires.

The three designs, lined up against the same skeleton

Same two-legged shape, every row. What differs is what moves (a wrapped claim, a canonical token, or LP inventory) and who you trust (a custody contract, an issuer, or a liquidity provider). What never differs is the existence of two legs and a gap between them.

When it matters

Always. The two-legged shape is the load-bearing fact of this entire course: it’s why you need inventory (to skip a leg), why finality choice is a risk dial, and why MEV searchers can pick you off mid-transfer. Internalize “two transactions, two ledgers, one gap” and the rest of the curriculum is footnotes on managing that gap.

Recap

You can now tell the three canonical bridge designs apart — what each one moves, what backs it, and who you’re trusting — and you’ve seen the single structural fact under all of them: two transactions, two ledgers, one exposure window. Next, we put a number on the danger lurking in that window.