Chapter 12 · Why the Future Will Have More Than One Chain
Will users still need to know which chain they are using?
- Capabilities practiced
- Protocol LiteracySystem Thinking
- Hands on
- Bridge a small asset to another chain, record its arrival time, and investigate what collateral backs that asset on the bridge.
- AI Lab
- Have AI list the trust assumptions of three types of cross-chain solutions. Compare them with a real bridge exploit and identify what it missed.
A Real-World Problem
You open an app. A message appears: Please switch to the XX network.
You switch, only to find a zero balance: your money is on another chain. You find a bridge, transfer your assets, and wait several minutes. Once they arrive, you try again: Insufficient funds for fees.
Your money arrived, but you lack this chain's native token to pay fees. Getting a little usually requires another swap, another transfer, and perhaps an exchange account.
Four steps later, you still have not used the app.
Compare this with something you do every day: emailing someone who uses another email provider.
You need not know their provider, switch to its email network, or hold its token to send mail. You do not even know these things exist.
Information can do this. Money cannot yet.
Users are not lazy. The question is: why is this so difficult?
Thought Experiment
Return to the town. After Chapter 11, it has more than one board.
A main board makes final rulings and stores data. Several secondary boards handle daily business with their own clerks. Two or three entirely independent boards belong to neighboring villages, whose different needs demand different rules.
Your problem is specific: you have 10 coins recorded on board A and want to buy something on board B.
Your first thought is to transfer the coins. But consider: where are the coins?
They are nowhere. Board A only contains a line saying, "This person has 10 coins." That is A's record. The people at B have never seen A. Why should they recognize it?
Physically transferring coins does not exist. There is only one thing you can actually do:
Convince board B that something happened on board A.
Once you accept this description, the remaining questions become concrete: who tells B, and why should B trust them?
The town develops four approaches.
First: appoint a messenger everyone trusts. They visit A and report that you locked 10 coins. B issues 10 new coins to you. Fast and cheap, provided the messenger neither lies nor gets impersonated.
Second: ask a group to vote. Nine people inspect A independently and return. Five votes are enough. More reliable than one messenger, unless five collude or all nine work for the same boss.
Third: let B check for itself. B keeps A's rules and verifies its records. This is the most reliable approach because no person needs to be trusted. It is also the most expensive: B must do extra work and update its checks when A changes its rules.
Fourth: do not transfer anything. You give Alex 10 coins on A; Alex gives you 10 of their own on B. Each board records its own transaction. Nothing crosses between them.
The fourth approach is intriguing: it turns a cross-board problem into an exchange between counterparties. You must find someone with money on both sides who is willing to make the exchange.
Your Decision
You want to move some money from A to B to use it there.
What Happens
The options differ substantially, but agree on one point:
What crosses chains is a message about something that happened on another chain, never the asset itself.
This is the chapter's central insight. Accept it, and apparently complicated questions become simple:
- "Where is my asset during bridging?" It remains locked on its original chain; what you receive is a claim.
- "Is this bridge safe?" Who guarantees that the message is true?
- "Why do bridges keep failing?" They concentrate two things: a large pool of locked assets and the power to decide whether a message is true.
Compare their trust assumptions:
| Approach | Who guarantees the message | Failure mode | Cost |
|---|---|---|---|
| Single messenger | One entity | Misconduct, compromise, or impersonation | Lowest |
| Group vote | A group | Collusion or concentrated keys compromised together | Low |
| Destination-chain verification | The rules of both chains | Implementation bugs or a source-chain rule upgrade breaking verification | High |
| Counterparty exchange | Matching mechanism and counterparty | One party fails to perform or the matcher lacks capital | Medium |
Remember a second question. What you receive on B is a claim, not the original coin. The questions Chapter 13 asks about stablecoins apply here unchanged:
Who holds the collateral? Is it sufficient? Can it be removed? If the source chain stops, what remains of this claim?
People often hold the "same asset" on several chains without asking what backs each version. They are frequently different things.
Build a Model
Model 1: Four steps of a cross-chain operation
- Something happens on chain A
- Someone proves it happened
- Chain B accepts that proof
- An outcome occurs on chain B
Evaluate any cross-chain design by examining the middle steps: who proves the event, and why the destination accepts the proof.
Model 2: Why one chain will not be enough
The title deserves a direct answer. Multiple chains result from three forces acting together:
| Reason | Explanation |
|---|---|
| Price pushes demand out | Chapter 7: low-value uses cannot survive on a congested chain and must go elsewhere |
| Trade-offs cannot be unified | Chapter 8: different uses need different combinations of six dimensions; no configuration fits all |
| Building a chain is becoming cheaper | Chapter 11: execution can move elsewhere and new networks can borrow existing security |
Any one would make multiple chains inevitable. All three hold simultaneously.
The question is whether users must pay the price of multiple chains.
Model 3: From instructions to desired outcomes
Describe the user's situation again.
What a user actually wants to say is: "I want 100 X on chain B."
Today they must pick a bridge, transfer, wait, swap, obtain native fee tokens, and finally do what they intended. Every intermediate step is an implementation detail, not their goal.
A shift is underway: let users state only the desired result and let specialists compete to deliver it.
| Today's workflow | Outcome-based workflow | |
|---|---|---|
| What the user says | Six specific operations | One desired outcome |
| Who chooses the route | The user | Competing providers |
| What the user must hold | Each chain's native token | The asset they intend to spend |
| Failure | Stuck at an intermediate step | Either completed or never executed |
| Required trust | Every step performed correctly | The matching and settlement mechanism |
The last row explains the price: outsourcing complexity also outsources some trust. Whether this is worthwhile depends on the mechanism's design, which you must learn to investigate.
Follow this idea further and reach the title's real question: if users only state outcomes, must they know which chain they are on?
Do not answer immediately. Return after completing the Lab.
What It Is Called
A situation where many chains coexist and users' assets and activities are distributed among them.
Remember that it is an outcome, not a goal. Nobody wants dozens of chains for their own sake; they result from price pressure, incompatible trade-offs, and cheaper chain creation.
For researchers, this has a practical implication: collect the same project's data separately for each chain and reconcile definitions before combining it. Chapter 23 revisits this trap.
A system that passes messages between chains and uses them to create assets or trigger operations on the destination.
Separate two things: messages are transmitted; assets are locked. Messages define security assumptions, while locked assets define potential losses.
This explains the concentration of bridge losses: a pool of locked assets and the authority to decide message validity sit together. Chapter 24 treats this as its own risk category.
Whether chains can safely read one another's state, transmit messages, and trigger operations.
Asset transfers are only its simplest use. A fuller version starts an operation on one chain and executes it on another, such as borrowing on B against collateral on A.
The standard remains: why should the destination believe what happened on the source?
An expression of the user's desired outcome rather than execution steps.
"I want 100 X on B and will pay at most 2" is an intent. "Bridge, swap, then transfer" is a sequence of steps.
The benefit goes beyond convenience: providers compete to fulfill the result, often delivering a better outcome than users achieve themselves. The price is trust in matching and settlement, including their ability to work under extreme market conditions.
Removing the choice of chain from the user's decisions.
Its complete form includes an account usable across chains, no separate fee preparation on every chain, outcome-based requests, and automatic routing behind the scenes.
It remains a direction rather than a completed reality, with a cost that must be acknowledged: when users cannot see the chain, they cannot see which chain's risk they bear. The tension between convenience and informed risk remains unresolved.
Summarize the chapter in one sentence:
Multiple chains are the outcome; abstraction is the direction. Cross-chain systems transmit messages, not assets themselves.
Evaluate any design by asking: who guarantees that message is true?
Hands-on
This Lab involves real assets. Use a testnet or limit the amount to a few dollars. Bridges concentrate many of this industry's failures, as Chapter 24 discusses. The goal is a complete observation record, not a financially meaningful transfer.
Research before acting. Choose a bridge and establish which of the four approaches it uses and who guarantees its messages.
Find answers in its official documentation. If you cannot, choose another bridge. Failure to find the answer is itself a finding.
Bridge a small amount. Record initiation time, source-chain confirmation time, and destination arrival time.
Record every fee, separated into source-chain transaction fees, bridge service fees, and destination-chain fees if applicable.
Find the locked funds on the source chain. Use its explorer to locate the address that received your assets.
Open it and ask: how much does it currently hold in total? Record the amount and observation time.
Inspect the asset received on the destination. Open its contract page and answer:
- What is its total supply? Does that match collateral locked on the source?
- Who can mint more?
- Can the contract be upgraded, and who has authority?
The second question is the heart of this Lab. If an address can mint at will, the bridge's entire security comes down to that key.
Complete this table.
| Question | Your finding |
|---|---|
| Which approach does the bridge use? | |
| Who guarantees message validity? | |
| Time until arrival | |
| Total fees and breakdown | |
| Locked source-chain assets | |
| Total destination-chain supply | |
| Who can mint destination claims? | |
| Upgrade authority and timelock |
Finally: if this bridge is compromised tomorrow, what does your asset become?
If you hold the "same asset" on three chains, do they share the same collateral pool? Most people have never checked.
AI Lab
First ask AI:
Divide cross-chain designs into three categories: one external guarantor,
a group of external voters, and destination-chain verification of source state.
For each, explain:
1. Every trust assumption users rely on
2. How each assumption can fail
3. Cost and speed trade-offs
Then reconstruct a real bridge attack step by step:
what the attacker did, which assumption failed, the loss, and the response.
Include the official postmortem link and incident date.
Mark anything uncertain as "uncertain".Then do the real work: compare its assumption list with that incident and identify what it omitted.
Models have a consistent blind spot here: they list design assumptions well but often miss operational assumptions.
They describe the required number of signatures, but fail to ask:
- Where are each signer's private keys stored?
- Can the signer list be replaced, and by whom?
- Can the contract be upgraded?
- Who holds an emergency pause or withdrawal power?
- Are all locked assets concentrated in one address?
Several of the largest historical bridge attacks broke one of these assumptions rather than the signing threshold itself. Correct code plus lost keys still means lost money. Chapter 9's lesson repeats here.
Add every omitted assumption. Keep the resulting checklist for evaluating any cross-chain product.
Verify these points yourself after using AI
- Did it include whether the message prover can be replaced?
- Did it automatically equate multiple signers with decentralization, without checking their independence?
- Can the incident date, amount, and attack path be verified in an official postmortem?
- Did it merge two separate bridge incidents?
- Did it distinguish stolen private keys from exploited contract logic? These are different attack categories.
- Did it mention locked asset volume, which sets the maximum potential loss?
- Does every specific number have a source and timestamp?
Real-World Case
Several enormous attacks during that period targeted cross-chain bridges, with individual losses reaching hundreds of millions of dollars.
Two attack paths dominated: stealing signers' private keys to forge a source deposit message and mint assets on the destination; or exploiting flawed contract verification to construct a false message that passed checks.
Their common feature: the destination believed a false message. These are steps two and three of this chapter's model.
When a chain stops producing blocks for an extended period, its bridged collateral cannot be verified or withdrawn.
Claims on the other chain can still trade freely, but their backing becomes uncertain and their prices often diverge substantially.
The core point is clear: your claim's value depends on whether collateral on the other chain still exists and remains accessible. Chapter 13's reserve questions apply unchanged.
A user bridges stablecoins to a new chain and sees the balance clearly. Then nothing works: they lack the native token needed for fees.
This basic, underestimated problem motivates chain abstraction. It involves product design rather than a security assumption.
Existing approaches include paying fees in the asset already held, app-sponsored fees, or including a little native token when bridging. Such changes often improve experience more than higher performance does.
A widely used asset can be issued differently across chains: directly by its issuer, as a claim against bridge collateral, or even after two bridging steps.
Wallets show the same name, icon, and price. The risks can be completely different.
Judge by the contract address, not the name. Start this habit now; every on-chain asset investigation will need it.
Change One Variable
Cross-chain problems and bridge risks disappear, and users never switch networks.
But Chapter 7's problem returns more severely: all demand competes for one pool of blockspace, with prices set by the wealthiest uses, permanently excluding low-value uses.
Chapter 8's trade-offs also become impossible to reconcile: one configuration across six dimensions must serve the conflicting needs of saving, gaming, and clearing.
Multiple chains have real costs, and a single chain does too. Unification cannot solve the underlying trade-offs.
Interoperability becomes standardized like network protocols: a new chain implements one specification instead of building a bridge for every pair.
Locked assets can move out of dozens of separate bridge contracts, substantially reducing the attack surface.
The cost: standardization also standardizes a shared failure point. A defect in the common specification affects all chains. Every infrastructure standard faces this trade-off.
Experience improves, fulfilling the goal of chain abstraction and the question behind this chapter's title.
But invisible chains still carry risk. A user's assets may sit on a chain with weak security assumptions or have just crossed a bridge controlled by five people.
An unresolved product question remains: how can users understand their risk without being exposed to all the complexity? Traditional finance uses regulation and disclosure; on-chain systems have not settled this. Chapter 27 examines the tension.
On-chain records and your destination-chain claim remain.
The redemption route breaks: nobody guarantees the message requesting return to the source. You retain a claim that temporarily cannot be redeemed.
This mirrors Chapter 13's scenario of a country prohibiting dollar stablecoins: on-chain ownership is hard to remove, but interfaces between chains and between chains and reality can still be cut off.
Takeaway Questions
Cross-chain systems sharpen this question: why must a chain guarantee this message?
If a centralized entity entirely guarantees value transfers between two chains, the trust structure resembles an internal transfer between brokers, with records on-chain. That can be useful, but understand what you actually receive.
Who uses chain abstraction? Someone who does not even want to know what a network is.
This sets product direction: every request to switch networks can lose that user. It also raises the unresolved question: if they do not want to know, how do you disclose risk?
Without identifying users, you cannot decide which complexity to hide and which to reveal.
Cross-chain costs exceed the bridge's quoted service fee. They include fees on both chains, swap slippage, and price risk while waiting.
A less visible cost: a counterparty advances funds and charges for capital tied up and price fluctuations. That charge is embedded in the exchange rate rather than a fee line. Chapter 15 shows how to calculate it.
The answer is clear: the holder of the cross-chain claim bears the risk.
When a bridge is compromised, attackers take locked assets and every claim holder suffers, including people who never used that bridge and simply bought the claim on a market.
The key practical reminder: you may bear a bridge's risk without knowing it. Check contract addresses, not names.
Chapter Check
Assets exist as records, not physical objects that can be carried. A records a balance for an address; B has never seen that record.
The only possible operation is: convince B that something happened on A, then produce an outcome on B accordingly.
Then the proper security question becomes: who guarantees that message is true?
They put two things together: a large pool of locked assets and authority over message validity.
The former sets the maximum loss; the latter sets the attack path. Capturing that authority allows an attacker to mint destination claims and exchange them for real assets.
Many of the largest incidents involved operational failures: key custody, replaceable signer lists, upgradeable contracts, or emergency powers held by individuals. Correct code does not protect money after keys are lost.
Three independent reasons hold simultaneously:
- Prices push demand out. Low-value uses cannot survive on congested chains.
- Trade-offs differ. No single combination of six dimensions fits every use.
- Chain creation is cheaper. Execution can move elsewhere and borrow existing security.
The question is whether users must bear this cost. Chain abstraction addresses that part.
Usually not.
They may be issuer-native assets, bridge claims, or claims bridged twice. The same displayed name, icon, and price can conceal different collateral and risks.
The contract address is the reliable identifier. Develop this habit; it will repeatedly protect your later research.
This chapter's central question concludes Stage 2 and has no standard answer.
The case for hiding chains: emailing does not require knowing the recipient's provider, and transferring money should not either. Network switching loses users; products should absorb complexity.
The case against hiding chains: chain choice determines the security budget, bridge assumptions, and claim collateral behind the user's risk. If users cannot see it, they cannot ask; without asking, they cannot choose.
Check your answer for three things:
- Did you distinguish freedom from operating details from freedom from knowing them?
- Did you offer a concrete disclosure design, specifying when and how users must be informed?
- Did you acknowledge that this tension remains unresolved?
Stage 2 ends here. Return to your stage project and the three-chain comparison from Chapter 8. Add one row: "What risk does an unaware user bear on this chain?"
If you can answer that row, you have completed the stage in substance.
Key idea
Multiple chains are the result; abstraction is the direction. Cross-chain systems carry messages, not the assets themselves.