T26 · Cross-chain

A Real-World Problem

A user has 1,000 USDC on chain A. To use a protocol on chain B, they transfer it through a bridge.

Two minutes later their wallet on B displays USDC 1,000. The icon, name, and decimals all look right. They deposit it as collateral in a lending protocol and borrow funds for another purpose.

Three weeks later, one night, the bridge's lockup contract on A is drained.

Nothing on B changes. The contract address is the same, their balance still says 1,000, and the token still says USDC. The only change is that there is now nothing behind those 1,000 tokens.

The price falls to pennies. Their collateral is instantly underwater, but liquidators refuse it: they would receive worthless claims. The lending protocol keeps the bad debt and spreads it across depositors.

The user did nothing obviously wrong. They used a popular bridge, saw a familiar ticker, and both wallet and market app called it USDC.

So ask precisely: what were those 1,000 things in their wallet?

Thought Experiment

Imagine two countries without a direct communication line.

You store a crate of goods in country A and receive a warehouse receipt. In country B, you want to sell that receipt.

Why should a buyer in B trust it? They cannot see A's warehouse or verify its inventory themselves.

People have historically used three kinds of answer.

First, hire a notary recognized in both countries. They saw the warehouse in A and attest that the receipt is real. Simple, fast, and cheap. The risk is just as clear: the notary decides. If bribed, coerced, or willing to print a false receipt, B has no way to notice.

Second, have B station its own observer outside A's warehouse. They record every deposit and withdrawal and maintain their own ledger. B need not trust a person, only the rules its observer follows.

The price is high. The observer must stay permanently and record every change, even if 99% is irrelevant to B. Complex accounting in A may be too expensive to reproduce.

Third, do not transfer the receipt at all. Someone in B already owns an identical crate. You give them your claim in A and they give you their goods in B. They bear the risk that A's crate really exists, because they judge the risk affordable and charge you for it.

Here is the crucial point.

The methods do not differ in how goods move: the goods never move. They differ only in why B believes a message saying “a crate in A belongs to you.”

The receipt is a message, not the goods. People in B exchange real value for it because they choose to interpret that message as an asset.

A message can be false. Once it is false, the asset inferred from it never existed.

The opening user's 1,000 USDC are the result of such an interpretation. When the lockup is drained, the basis of the message and thus its interpretation disappear.

Your Decision

Choose a bridge for your application, or design one. Start with how messages are verified.

What Happens

Compare the four designs:

Only the second column really matters. It leads to the first conclusion:

There is no cross-chain mechanism with no trust assumption, only different choices about whom to trust.

When marketing says “trustless,” translate it into “if this party fails or cheats, I lose my funds.” If you cannot identify that party, you have not understood the design.

A second conclusion explains why bridges see so many incidents.

Locked value grows with use, but the security budget need not grow with it. A bridge can move from ten million to a billion in locked assets while retaining the same N signers and nearly the same attack cost.

Each bridge can drift toward this state:

The cost of compromising it eventually falls below the reward.

That is next chapter's economic-attack formula in particularly stark form. Bridge funds are concentrated: a lending exploit may affect one pool, while a bridge exploit can reach everything locked there.

The third conclusion is this chapter's title:

Cross-chain systems move messages. An asset is one interpretation of a message.

The opening tokens were claims minted by a contract on B in response to a message from A. Their value depends on the message remaining true and its backing secure.

Build a Model

Three layers: transport, verification, interpretation

Any bridge separates into three layers. Only the middle one sets the trust assumption.

This separates substance from marketing. “Twenty independent relays” may sound safe, but relays transport data. More relays improve delivery, not truthfulness. Ask who verifies.

Three ways to represent an asset

“Moving money over” can mean three different onchain operations, producing different user holdings:

The first creates the opening scenario and a subtle problem:

One asset can have multiple incompatible versions on the destination. Five bridges produce five token contracts all labelled USDC. They are not interchangeable: a token minted by bridge A cannot redeem through bridge B.

Liquidity fragments and users may not recognize the version. Integrations must enforce:

Your allowlist contains contract addresses, not symbols. Code that identifies assets by ticker will eventually accept the wrong one.

Issuer-operated burn-and-mint narrows trust from a bridge to the issuer. If you already trust that issuer, it can improve on wrapped assets.

Message layer: idempotency and replay, another outbox

Cross-chain messages need two properties familiar from the T17 outbox:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract MessageReceiver {
    // Executed messages for replay protection; key is a globally unique coordinate
    mapping(bytes32 => bool) public executed;

    event Executed(bytes32 indexed id);

    function execute(
        uint256 srcChainId,
        uint256 nonce,
        address sender,
        bytes calldata payload,
        bytes calldata proof
    ) external {
        // 1. Include the destination chain; otherwise one message executes on multiple chains
        bytes32 id = keccak256(
            abi.encode(srcChainId, block.chainid, nonce, sender, payload)
        );

        // 2. Idempotency: reject a message already executed
        require(!executed[id], "already executed");

        // 3. Verification determines the bridge's security
        require(verify(id, proof), "invalid proof");

        // 4. Record first, then execute; reversing the order enables reentrancy (T28)
        executed[id] = true;
        _apply(sender, payload);

        emit Executed(id);
    }

    function verify(bytes32, bytes calldata) internal view virtual returns (bool) {
        return false; // Concrete verification layer implements this
    }

    function _apply(address, bytes calldata) internal virtual {}
}

The four comments map to real incident classes.

The unique ID must include destination chain. Otherwise the same proof can execute once on every deployed destination, turning one deposit into many mints.

Idempotency must be persistent and onchain. Relays retry, users retry, and reorgs cause redelivery. As with T16's primary key, deduplicate by the message's coordinates, not by remembering that you sent it.

The verification line is the bridge's entire security boundary. The Real-World Case section shows how many failures occur there.

Record execution before calling outward. The reverse permits reentrancy, whose cost the next chapters demonstrate.

Finality: the most often missed cross-chain boundary

This is T17's problem with higher stakes:

Source: user locks → transaction included → ...confirmations... → sufficiently final
Destination:              ↑
                    At what point should it mint?

Mint on the destination immediately after a source block, then let a reorg remove the source deposit, and the destination token is already minted without backing.

That is unbacked issuance, with no way to recall it.

The T17 outbox rule applies: wait before doing an irreversible action until the source event is deep enough. An incorrect notification can be apologized for; unbacked minted assets remain claims.

Every bridge needs a waiting depth, with two practical traps:

First, configure depth per chain, not globally. Finality models vary. Copying a number from one chain to another invites an exploit.

Second, waiting conflicts with user experience. “Arrives in three seconds” is powerful marketing. It can come from reducing confirmation depth or from a liquidity provider advancing funds and bearing that risk. The latter prices risk openly; the former passes it quietly to users.

Attack-surface checklist

Bridges see frequent losses because they combine concentrated funds, complex verification, and two security models.

List historically common attack surfaces:

The last row is worth isolating. Many bridges carry general messages: not only “mint this amount,” but “call this function on this contract on the destination.”

That power makes forgery more destructive. On integration, add your own boundary: accept only messages from an approved source address and with an approved format, never arbitrary calls.

Do one calculation

The next chapter makes this a method. Start simply:

Compromise cost = obtaining M keys + gas + time
Compromise reward = all assets locked by the bridge

Safety condition: compromise cost > compromise reward

Locked value is public onchain for anyone to read. Key-compromise cost is hard to estimate, but ask concrete questions: how many validators, who operates them, whether one team controls them, how keys are kept, and whether an upgrade timelock exists.

If locked value rises by two orders of magnitude while every answer in the first line stays the same, the bridge may now be economically worth attacking even with unchanged code.

What It Is Called

Hands-on

- Where did the funds go: a lockup contract or an externally owned account?
- What event was emitted? Does it include destination chain ID, recipient, and nonce?
- How much does that contract hold? Read its balance, not a website figure.
- Is it a proxy? Who can upgrade it, and is there a timelock?

- Who submitted it: a relay, validator, or you?
- Which function was called, and what does its proof argument look like?
- Who may mint? Read mint permissions in the token contract.
- What is the received token's address? Is it the same as the chain's official token with that name?

Insufficient: "If the bridge is attacked, I lose money." That says nothing.
Specific:     "If keys from five of these eight validators leak together,
               my wrapped destination assets become unbacked claims."

AI Lab

Step one:
Compare external-validator, light-client, and challenge-window bridges.
For each, finish “if ___ cheats or fails, users lose funds” with a concrete
role and threshold, not vague words like “bridge” or “system.” Add delay,
cost, and difficulty of adding another chain.

Step two:
Separate transport, verification, and interpretation layers. What happens
if each fails? Which failure loses funds and which only delays messages?

Step three:
Find a real bridge loss. Using the layers above, explain:
1. What transaction did the attacker send, and what did they do?
2. Which layer failed?
3. Would the attack work under either of the other two architectures?
4. Could public onchain data have revealed the risk in advance?

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check