Scaling a blockchain app: choosing between layer 2s, app-chains and cross-chain designs

Most blockchain apps don't need their own chain to scale. For the majority, the right move is to deploy on a mature layer 2 rollup, keep state on one chain as long as possible, and add cross-chain messaging only where users and liquidity genuinely live elsewhere.

That answer hides a lot of nuance. Scaling a blockchain app is not one decision but three: where your contracts execute, where your data is published, and how your app talks to other chains. This article walks through each, with the trade-offs that tend to bite teams later.

What "scaling" actually means for a dApp

When a team says their app "doesn't scale", they usually mean one of four different problems:

• Cost per action. Fees on Ethereum mainnet make small, frequent actions (game moves, social posts, micro-payments) uneconomic.
• Throughput. The chain can't include all the transactions the app wants to send in a given block.
• Latency. Users wait too long for confirmation or finality.
• Reach. Users and assets are spread across several chains, and the app only lives on one.

Layer 2s mostly solve the first three. Interoperability solves the fourth. Mixing them up leads to the most common mistake: deploying on five chains to fix a cost problem, and ending up with fragmented liquidity and five times the attack surface.

Layer 2 rollups in plain terms

A rollup executes transactions off the base chain, batches them, and posts the batch data plus a commitment to the resulting state back to Ethereum. Because Ethereum stores the data, anyone can reconstruct the rollup's state and, in a mature design, withdraw their funds even if the rollup operator disappears. That's what separates a rollup from a sidechain, which has its own validators and its own security.

Optimistic rollups

Optimistic rollups (Arbitrum One, OP Mainnet, Base and the many chains built on the OP Stack) assume batches are valid and allow a challenge period, typically about seven days, during which anyone can submit a fraud proof. The consequence for your app: native withdrawals to Ethereum take a week. Third-party "fast bridges" front users the money for a fee.

ZK rollups

ZK rollups (ZKsync Era, Starknet, Scroll, Linea and others) post a validity proof with each batch. Once Ethereum verifies the proof, the state is final, so withdrawals don't need a week-long wait, though proof generation and batching still add delay. Their trade-off has historically been EVM compatibility: some are bytecode-equivalent, while others, like Starknet with its Cairo language, require a rewrite.

Why fees dropped in 2024

Ethereum's Dencun upgrade in March 2024 introduced EIP-4844, which added "blobs": a cheaper, temporary data space designed for rollups. Rollup fees fell sharply as a result. The Pectra upgrade in 2025 raised the blob capacity further. For app builders, the practical upshot is that rollup transaction costs are now low enough for many consumer use cases that were impossible on mainnet.

The fine print: rollup maturity

Not every rollup is equally trustless. Many still run a single centralized sequencer, rely on upgradeable contracts controlled by a multisig, or have fraud-proof systems that are restricted to approved parties. The independent L2BEAT project tracks this with a "stages" framework (Stage 0 to Stage 2) that is worth checking before you commit. A centralized sequencer can't steal funds in a well-built rollup, but it can censor or delay transactions and it can go down.

The scaling options compared

A note on the last row: data availability (DA) is where a rollup publishes its transaction data. Using Ethereum blobs gives the strongest guarantees. Using an external DA layer such as Celestia or EigenDA, or a data availability committee, cuts costs further but adds a dependency: if the data is withheld, users may not be able to prove their balances.

Interoperability: how chains talk to each other

Once your app spans more than one chain, you need a way to move assets and messages between them. There are four broad patterns:

• Lock and mint. Tokens are locked on chain A and a wrapped representation is minted on chain B. Simple, but the locked pool becomes a honeypot.
• Burn and mint. The issuer burns on one chain and mints on another, so there's no wrapped asset. Circle's CCTP for USDC works this way. It requires issuer control of the token.
• Liquidity networks. Market makers hold inventory on both sides and swap for users, settling later. Fast, but relies on liquidity depth.
• General message passing. Protocols such as Chainlink CCIP, LayerZero, Wormhole, Hyperlane and Axelar relay arbitrary messages, so a contract on one chain can trigger logic on another. Cosmos chains use the IBC protocol, which verifies the other chain with light clients.

Why bridges are the riskiest part of the stack

Bridges have been behind some of the largest losses in crypto. In 2022 alone, the Ronin bridge lost over $600 million after validator keys were compromised, Wormhole lost about 120,000 wrapped ETH to a signature verification bug, Harmony's Horizon bridge lost around $100 million after a small multisig was compromised, and Nomad lost roughly $190 million when an initialization error let anyone forge messages. The pattern is consistent: whatever verifies cross-chain messages, whether a multisig, a validator set or code, holds custody of everything bridged.

When choosing a messaging layer, ask who attests to messages, how many independent parties must collude to forge one, whether you can configure your own verification (several protocols let apps choose their verifiers), and what rate limits exist to cap the damage if something goes wrong.

Chain abstraction and intents

A newer approach hides chains from users altogether. With intent-based designs, a user signs what they want ("swap this USDC on Base for ETH on Arbitrum") and competing solvers fill it, taking on the bridging themselves. Standards such as ERC-7683 for cross-chain intents aim to make these orders portable between protocols. For app builders, this can mean accepting deposits from many chains while keeping core contracts on one.

A step-by-step scaling plan

1. Measure the real bottleneck. Estimate transactions per user per day, value per transaction and acceptable latency. A DeFi vault with a few large deposits has different needs from an on-chain game.
2. Start on one chain. Pick the rollup or chain where your users, wallets and liquidity already are. Single-chain apps are dramatically easier to secure and reason about.
3. Optimize before you migrate. Move non-critical data off-chain (events plus an indexer, IPFS for media), batch operations, and use signatures for actions that don't need immediate settlement.
4. Design state for portability. Keep contracts upgradable only through a timelocked, multisig-controlled process, and avoid assumptions about block times or block.number that differ between chains.
5. Add chains for reach, not cost. Expand only where there's a concrete user or liquidity reason. Decide which chain is canonical for each piece of state.
6. Choose one messaging layer and constrain it. Use rate limits, per-chain caps and pausability. Treat every inbound cross-chain message as untrusted input.
7. Consider an app-chain last. Only when you need custom gas economics, custom execution or sequencing revenue, and you can staff the operations.

Common mistakes

• Deploying the same contracts on many chains without a plan for which chain's state wins.
• Assuming an L2 behaves exactly like mainnet. Opcodes, precompiles, gas pricing and block timestamps can differ, and oracle feeds need sequencer-uptime checks.
• Choosing a bridge on fees alone rather than on its trust model.
• Launching an app-chain before having enough users to keep validators, explorers and indexers economically viable.
• Forgetting the user's side: wallet support, gas tokens and on-ramps for the chain you pick.

For deeper dives, see the guides on multichain blockchain development, layer 2 for NFT projects, ZKsync integration and cross-chain marketplace architecture.

Frequently asked questions