Many chains, one problem: why blockchains can't talk to each other

Same dollars, two islands

Picture this. You hold 1,000 USDC on Ethereum. A friend asks you to send them USDC, but their wallet only lives on another chain — say a Layer 2, or Solana. You'd assume you could just send it. You can't. The USDC in your Ethereum wallet is a single number stored in one specific contract's ledger on one specific chain. The 'USDC' on the other chain is a completely different token, issued by a different program, even though both display the ticker USDC and both are worth a dollar. From Ethereum's point of view, the other chain simply does not exist. There is no transaction you can sign that moves a balance out of one chain's state and into another's.

This is not a feature someone forgot to ship. It is baked into what a blockchain is. Over the earlier rungs you came to see a blockchain as a shared distributed ledger that thousands of independent machines all agree on. That very agreement — the thing that makes a chain trustworthy — is exactly what makes it blind to every other chain. This rung is about interoperability: how we bridge that gap anyway, and why doing it safely is one of the hardest and most dangerous problems in the whole field.

A blockchain is a sealed room

Recall why nodes agree at all. A chain's consensus mechanism works because every node, starting from the same prior state and replaying the same ordered list of transactions, computes the exact same next state. If two honest nodes could legitimately arrive at different states, there would be nothing to reach consensus on. So the rule is absolute: the state-transition function must be deterministic and self-contained.

That forces a hard wall. The only inputs an EVM contract is allowed to read are the calldata of the transaction calling it, and data already sitting in the chain's own state. There is no opcode to open a network socket, make an HTTPS request, read a file from disk, or — the point of this rung — query another blockchain. Every input must be something every node in the world can reproduce identically.

// Why the EVM has no "fetch from the internet" opcode
contract PriceFeed {
    function getPrice() public returns (uint) {
        // IMAGINARY opcode -- it does NOT exist in the EVM:
        return HTTP_GET("https://api.exchange.com/eth-usd");
    }
}

// Validator A executes this at 12:00:00  -> returns 2500
// Validator B executes this at 12:00:01  -> returns 2501
// The two now disagree on the resulting state. Consensus breaks.
//
// So the opcode simply does not exist. The ONLY inputs a contract
// can read are: (1) the transaction's calldata, and
//               (2) data already in this chain's own state.

Nothing actually crosses the bridge

Because of that wall, the everyday words are misleading. When you 'send ETH to an L2' or 'bridge USDC to another chain,' no token teleports anywhere. A token is just a number in a contract's storage on one chain — and a number cannot leave the chain it lives on any more than a row in a database can jump to a different database by itself.

What really happens (and the next guide on bridges dissects it in full) is a coordinated pair of actions on two separate chains. The canonical lock-and-mint pattern: your real asset is locked in a contract on the source chain, and a brand-new wrapped representation is minted on the destination chain. That wrapped token is an IOU. It is worth a dollar only as long as the original is genuinely locked away and genuinely redeemable for it.

The one question every bridge must answer

Strip away the marketing and every cross-chain system reduces to a single question. Chain A is handed a claim — *'event E happened on Chain B'* (a deposit was locked; a message was sent) — by some outside party, because A cannot check B for itself. How should A decide whether the claim is true? Everything else is detail.

At one extreme, A simply trusts a designated group. A validator set or multisig watches B and signs off, and A's contract believes anything that group signs. This is cheap and works between any two chains — but you have reintroduced a trusted third party, and if their keys are stolen the bridge is drained. This is exactly the externally-verified model behind the largest hacks in crypto history.

At the other extreme, A verifies B's consensus itself, with no human committee in the loop. A contract on A runs a light client of B: it checks B's validator signatures, or a validity proof attesting that the claimed state is real, before believing anything. This is the light-client / trust-minimized approach, and it inherits B's security rather than adding a fresh trust assumption. The catch is cost and difficulty: verifying another chain's signatures and finality rules inside a contract is expensive, and every pair of heterogeneous chains — different curves, different consensus — needs its own purpose-built verifier.

// The cross-chain question, distilled into one function.
// Chain A is told: "message M happened on Chain B." Believe it?

function receiveMessage(bytes M, bytes proof) external {
    // --- Option 1: TRUSTED (cheap, universal, but you trust a committee)
    require(committee.hasQuorumSigned(M), "not enough signatures");

    // --- Option 2: TRUST-MINIMIZED (verify B's consensus yourself)
    // require(lightClientOfB.verify(M, proof), "invalid proof of B's state");

    execute(M);   // e.g. mint the wrapped token, call the target contract
}

// The entire field of interoperability is the design space between
// these two require() lines: how little must A trust, and at what cost?

That spectrum — from 'trust a committee' to 'verify the math' — is the single most important axis in this entire rung. The next guide on trust models places real bridges along it and shows precisely which assumption failed in each billion-dollar hack.

A spectrum of solutions

Interoperability isn't one technology; it's a family of approaches, arranged roughly from narrowest to most general:

1. Atomic swaps. The oldest trust-minimized trick. A hash time-locked contract lets Alice on Bitcoin and Bob on Litecoin swap coins so that either both legs complete or both refund — no custodian ever holds the funds. Atomic swaps are beautifully trustless, but they only swap assets (no general data) and need a counterparty who wants the exact opposite trade.
2. Token bridges. Lock-and-mint or burn-and-mint plumbing that moves value between chains. This is the workhorse of today's multi-chain world — and, as we'll see, the single largest source of stolen funds in all of crypto.
3. General message passing. Not just tokens, but arbitrary calls — 'execute function f on Chain B with these arguments.' Native designs like IBC (light clients between chains) and third-party messaging layers carry these. This is the subject of a later guide in the rung.
4. Shared security / unified ecosystems. Don't bridge between strangers at all — build many chains that share one common security and settlement base. Polkadot parachains, Cosmos zones, and rollup 'superchains' on a shared settlement layer make interoperability a native property rather than a bolt-on. This is where the rung ends.

Notice the trade-off running through that list, sometimes called the interoperability trilemma: a cross-chain protocol struggles to be simultaneously trustless (adds no new trust assumption), extensible (works across wildly different chains), and generalizable (carries arbitrary data, not just token transfers). You can comfortably have two; the third gets compromised. IBC is trustless and general, but extends easily only to chains with fast, light-client-friendly finality. A multisig token bridge is extensible and general, but not trustless. There is no free lunch — only an informed choice about what to give up.

Multi-chain, yes; cross-chain, carefully

There is a sharper version of that warning, argued famously by Ethereum's Vitalik Buterin in early 2022: he is optimistic about a multi-chain world (many chains coexisting) but skeptical of a deeply cross-chain one (assets fluidly bridged everywhere). The reason is systemic risk. If your asset lives natively on its home chain, a 51% attack on that chain is bad but contained — it can only reorder that chain's own history. But once an asset is bridged across many chains, an attack on any one of them can propagate: an attacker mints counterfeit wrapped tokens and drains the collateral that backed everyone's holdings, and the damage ripples outward through the web of bridges. More connections can mean more fragility, not less.

That tension — the multi-chain world is real and genuinely useful, yet stitching it together safely is genuinely hard — is the spine of this rung. The honest state of the art is a menu of trade-offs, not a single winner, and a serious builder picks consciously rather than reaching for whichever bridge has the lowest fee.

Here is the road ahead in this rung. Next you'll dissect the lock-and-mint mechanism that actually moves a token across a bridge; then the trust models and the anatomy of the Ronin, Wormhole, and Nomad hacks; then general cross-chain messaging beyond tokens; and finally the app-chain and shared-security ecosystems — Cosmos, Polkadot, and rollup superchains — that try to make interoperability native, the way modular designs and omnichain protocols envision a unified multi-chain world. Keep one question in your pocket the entire way: *for this asset to be safe, exactly whom — or what — am I trusting?*