Fifty chains, one user: building across Ethereum's L2s

Ethereum's rollup-centric roadmap worked: transactions are cheap and fast on layer 2s. It also produced a new problem. A user with funds on Base, an app on Arbitrum and an airdrop on Optimism has three balances, two bridges to choose between and, on optimistic rollups, a withdrawal to mainnet that can take up to a week.

The problem: scale bought with silos

• Scattered liquidity. The same asset trades in many pools on many chains, so each pool is thinner and prices are worse.
• Users must know which chain they are on. Wrong-network errors, stuck funds and bridge choices are the top source of confusion in onchain support queues.
• Uneven trust. L2BEAT tracks how decentralised each rollup is, and only a handful of the major L2s have reached its highest stage, where users can exit without trusting an operator.
• Bridges remain a target. The largest exploit of April 2026 went through a cross-chain route with a single verifier, as we cover in keys, not code.

The Ethereum Foundation has made this a priority. Its interoperability work, including an Ethereum Interop Layer intended to make moving across L2s feel like one chain, and standards such as ERC-7683 for cross-chain intents, aims to fix it at the protocol level. Until those land and are widely adopted, applications have to solve it themselves.

The proposal: make the chain an implementation detail

1. 01One account, many chains. Give users a smart account with the same address on every chain you support, and show one balance per asset, aggregated.
2. 02Intents for everyday moves. When a user acts on a chain where they lack funds, express it as an intent: "I want 100 USDC on Arbitrum, I pay from Base." A solver fills it in seconds from its own inventory and is repaid later. ERC-7683 standardises the order format so many solvers can compete.
3. 03Canonical bridges for size. Large or slow-moving transfers go through the rollup's canonical bridge, which inherits Ethereum's security at the cost of time.
4. 04Native USDC where possible. Circle's cross-chain transfer protocol burns and mints USDC rather than wrapping it, avoiding a bridged copy.
5. 05Cap every route. Each route has a value limit and monitoring, sized to the trust assumptions behind it.
6. 06Show the trade-off honestly. When a route is faster because it trusts more, say so in the interface.

What to deploy where

For most new products, one or two L2s where your users already are beats ten deployments. Add chains when users ask, and use intents to reach the rest. A dedicated rollup makes sense only at sustained high volume or with genuinely custom needs.

What to measure

• Wrong-network errors. Support tickets and failed transactions caused by users being on the wrong chain, before and after.
• Time to funds. Median time for a cross-chain action to complete, by route.
• Solver fill rate and cost. How often intents fill within your target time, and what users pay over the canonical route.
• Value at risk per route. The cap on each route against the trust assumptions behind it, reviewed when either changes.

How we would start

Map where your users' funds actually sit today, then design the first flow around an intent rather than a bridge. This is the core of our cross-chain and interoperability and dApp work.