# 10 — Bridges and Interoperability Chain A and Chain B each maintain their own carefully-verified truth. Now Chain A wants to know something about Chain B — say, that a deposit happened there. Pause on this for a moment: how could Chain A ever *know* that, rather than merely be told? It's worth sitting with, because the question has exactly one honest answer, and the entire interoperability landscape turns out to be a catalog of ways to pay for it — or avoid paying for it. ## The fundamental constraint > Chain A cannot know Chain B's state unless it verifies Chain B, or trusts someone who does. That's the whole game. Verifying another chain's consensus inside your own is expensive. Trusting someone is cheap. Every bridge design ever built is a point on the line between those two, and knowing where a given bridge sits tells you most of what you need to know about it. ## What a bridge actually does First, a correction to the mental image: assets don't move between chains. There is no wire. What actually happens: ```text lock asset on Chain A mint representation on Chain B ``` and on the way back: ```text burn on Chain B unlock on Chain A ``` So the "bridged asset" you hold on Chain B is an IOU — a claim whose backing sits locked in a contract on Chain A, and whose value depends entirely on the unlock working later. Which reframes the important question about any bridge. It's never "how fast?" It's: *who can authorize the unlock, and what evidence convinces them?* | **Type** | **Trust model** | |---|---| | Multisig bridge | Trust **m-of-n** signers — any m of n designated keys can authorize an unlock | | Light-client bridge | Verify source chain's consensus on the destination chain | | Optimistic bridge | Fraud-challenge period | | ZK bridge | Verify a validity proof | | Liquidity bridge | Market makers front the funds | Lay these against the [[Trust Assumptions]] spectrum and an uncomfortable pattern appears: the historically most common designs (multisigs) sit at the most-trusted end, while the most robust (light-client, ZK) sit at the least. Convenience won, for years. The exploit statistics record the outcome — bridges concentrate enormous locked value behind operational keys and cross-domain verification code, and they have been robbed on a scale unmatched anywhere else in the field. There's a formulation that captures why bridges are deeper than they look: > A bridge is not really a transfer mechanism. It's a statement about which chain's [[Finality]] another chain is willing to believe. And believing too early has a concrete failure mode: mint on Chain B before Chain A's history has settled, and a [[Reorgs|reorg]] can leave you having issued tokens against a deposit that no longer exists. ## Interoperability, more broadly Token bridging is just the narrowest case. The same family includes message passing (a contract on A calling a contract on B), cross-chain swaps, shared liquidity, chain-abstraction wallets, and intent systems. It's a useful exercise to take any of them and find the constraint again — verify or trust, applied to a different payload. It's always there. ## Intents The newest pattern flips the interface around, and it's worth seeing why. Instead of the user specifying a route: ```text swap 100 USDC on chain A through pool X, bridge to chain B, buy token Y ``` the user states an outcome: ```text I want token Y on chain B, paying at most 100 USDC. ``` Solvers then compete to fulfill it, absorbing the routing, bridging, and execution risk in exchange for a margin. A **solver** is a party that finds a profitable route to fulfill your stated outcome. If you want a familiar hook: it's declarative rather than imperative — the user writes the query, the solver is the query planner. The UX gains are real, and so is the pattern worth watching: the costs don't vanish, they relocate. Solver centralization, opaque execution quality, hidden fees, censorship, settlement disputes. When an interface hides the route, the question to keep asking is who chose the route, and what they kept for themselves. This is plausibly where mainstream crypto UX ends up — less "choose chain, gas, bridge," more "state the result." Which quietly raises the stakes on everything in [[07 Wallets and Account Abstraction]]: the wallet becomes the place where intent gets expressed and trust gets priced. ## Learning outcomes Questions worth trying on: - Could you explain why "sending tokens to another chain" is a fiction — and what actually happens instead? - Given any bridge's docs, could you find its answer to "who can authorize an unlock?" and place it on the trust spectrum? - Why have bridges hosted the largest exploits in the field? Could you name the ingredients that combine there? - Could you explain an intent system to a colleague using a pattern they already know from databases or networking? - And the thread to pull forward: rails, wallets, bridges — the infrastructure is assembled. What do the *applications* built on it look like as state machines, and what keeps them solvent? ## Checkpoint 1. What does a light-client bridge verify that a multisig bridge merely assumes — and what does it pay for the upgrade? *(If unsure, revisit "What a bridge actually does" and [[Trust Assumptions]].)* 2. A bridge mints on Chain B after seeing a deposit on Chain A; then Chain A reorgs. Walk through the damage. *(If unsure, see [[Reorgs]] and [[Finality]].)* 3. In an intent system, who carries the execution risk, and how are they compensated? *(If unsure, revisit "Intents".)* **Exercise.** Pick two real bridges — say, a canonical rollup bridge and a third-party liquidity bridge. For each, write one paragraph answering: who authorizes the unlock, what finality does it wait for, and what's the worst-case failure? Then compare your two paragraphs. The difference between them is, essentially, this entire subject. ## Resources - **Ethereum.org docs: Bridges** — taxonomy and risk framing. - **OP Stack / Arbitrum bridge documentation** — the canonical rollup bridges, and the best-understood designs. - **Post-mortems of major bridge exploits** (Ronin, Wormhole, Nomad) — some of the most instructive reading in the field. Each one is a trust assumption discovered the hard way. --- Next: the rails exist. What do the financial machines built on them look like — and what keeps a lending protocol solvent at 3 a.m.? → [[11 DeFi, Stablecoins, and Governance]]