Bitcoin settles a few transactions per second. Ethereum manages more, still a rounding error next to a card network. This is not an oversight waiting for a clever fix; it is the direct cost of the property that makes these systems worth using. Layer 2 is the family of designs that tries to keep that property while lifting the throughput ceiling. Some designs succeed almost completely, others mostly rename the trust they reintroduce.
Why the base layer is slow by design
Every full node verifies every transaction. That is the point: you do not have to trust a miner, a company or a majority, because your own computer checks the rules. It also means the network can only go as fast as an ordinary computer can verify and store, and as fast as data can travel around the world between blocks. Raise the block size or shorten the block time enough and only data centres can keep up, at which point users are back to trusting a few operators. This tension is usually called the scalability trilemma: decentralisation, security and throughput, pick two, or find a structural trick.
The structural trick is to stop putting every payment on the base layer. Use the chain as a court of final appeal and a settlement ledger, and do the everyday volume somewhere cheaper, in a way the court can still enforce.
Design 1: payment channels and the Lightning Network
Two parties lock coins in a shared on-chain transaction, then exchange signed IOUs off chain updating how the coins are split. Thousands of updates cost nothing and confirm instantly; only the opening and the final closing touch the blockchain. If one side vanishes, the other publishes the latest signed state and the chain enforces it. If one side tries to publish an old state, the protocol lets the victim claim all the channel's funds as a penalty.
Lightning links channels into a network, so you can pay someone you have no channel with by routing through intermediaries. Each hop is protected by a cryptographic condition: an intermediary can only claim the payment if it has already passed it along, so no one in the path can steal.
Strengths and limits
- Security inherited almost entirely from Bitcoin: no new tokens, no operator who can freeze funds.
- Instant, near-free payments for amounts that fit inside channel balances.
- The catch is liquidity: you can only receive what your counterparties have on their side of the channel, and large payments must find a route with enough capacity. Channels must also be watched, because the penalty only works if someone is online to publish the latest state; “watchtower” services exist for this.
- It suits payments, not general computation. There is no “smart contract” inside a channel beyond what the two parties agreed.
Design 2: rollups
A rollup executes transactions on its own chain, then posts two things to the base layer: a compressed record of the transaction data and a commitment to the resulting state. Because the data is on the main chain, anyone can rebuild the rollup's state without trusting the operator, and because the base layer holds the funds, withdrawals are enforced by the base layer's rules. The two families differ in how they prove the state is correct.
Optimistic rollups
The operator asserts the new state and the chain accepts it optimistically. During a challenge window, typically about seven days, anyone can submit a fraud proof showing the state transition was invalid; if the proof holds, the bad state is reverted and the operator is penalised. The design is simple and supports ordinary smart contracts, at the price of slow withdrawals to the base layer, since a withdrawal must wait out the window unless a third party fronts the funds for a fee.
Zero-knowledge (validity) rollups
The operator submits a cryptographic proof that the new state was computed correctly. The base layer verifies the proof, which is cheap, before accepting the state. No challenge window is needed, so withdrawals can be fast, and correctness does not depend on anyone watching. The cost is complexity: generating proofs is computationally heavy, and the proving systems are young and intricate.
What both rollups rely on
- Data availability. The transaction data must actually be published on the base layer. Variants that keep data elsewhere are cheaper but reintroduce trust in whoever holds the data.
- Sequencer honesty for ordering, not for safety. Most rollups have a single sequencer that orders transactions. It can censor or delay but, in a well-built rollup, cannot steal or forge, and users can usually force transactions through the base layer if it stalls.
- Upgrade keys. The rollup's contracts on the base layer are often upgradeable by a multisig. Whoever holds those keys can, in the worst case, change the rules. Reputable projects publish who holds them and add time delays; this remains the most common source of real trust in “trustless” rollups.
Design 3: sidechains, which are not Layer 2
A sidechain is a separate blockchain with its own consensus, connected to the main chain by a bridge: you lock coins on the main chain and an equivalent token is issued on the sidechain. The bridge is usually a federation of known parties holding the locked coins. If the federation's keys are stolen or its software has a bug, the main chain cannot help, because from the main chain's point of view the coins simply belong to the federation.
That is not a hypothetical. In September 2026 an inflation bug in the software behind Liquid, a federated Bitcoin sidechain, allowed unbacked tokens to be minted and roughly four thousand bitcoin to be withdrawn from the federation's reserves; our brief on the incident has the details. Sidechains are legitimate tools with real uses, but calling them Layer 2 blurs exactly the property users care about. The honest description is: fast, cheap, and secured by the people running the bridge.
A practical test for any “Layer 2”
| Ask | Real Layer 2 answer | Warning sign |
|---|---|---|
| If the operators vanish tomorrow, how do I get my coins out? | By submitting a transaction to the base layer myself | “The team would restore service” |
| Where is the transaction data stored? | On the base layer | On the operator's servers or a separate committee |
| Who can change the rules? | Nobody, or a published multisig with a long time delay | An unnamed admin key with instant upgrades |
| Can the operator steal funds? | No; at worst they can delay | Yes, if a threshold of them collude |
| What backs the token I hold? | Base-layer coins enforced by base-layer rules | Coins held by a federation or a company |
What scaling does not mean
Higher transactions per second on a chain that only a few companies can validate is not scaling; it is outsourcing. The test of a scaling solution is whether an ordinary user with an ordinary computer can still, in the worst case, verify their funds and retrieve them without permission. Lightning and well-built rollups pass that test with caveats about liquidity, watching and upgrade keys. Sidechains and centralised “Layer 2s” fail it by construction, which is fine as long as everyone knows.
Frequently asked questions
What is the difference between a Layer 2 and a sidechain? A Layer 2 keeps enough information and enforcement on the main chain that users can withdraw their funds even if the Layer 2's operators disappear. A sidechain has its own consensus and a bridge run by a federation or company; if the bridge fails, the main chain cannot recover the funds.
Is the Lightning Network safe? Its security comes from Bitcoin's own rules: the latest signed channel state can always be enforced on chain and cheating is penalised. The practical risks are operational: keeping the node online or using a watchtower, managing channel liquidity, and choosing reliable peers.
Why do optimistic rollup withdrawals take about a week? Because the base layer accepts the rollup's state without checking it and gives everyone a window, typically around seven days, to submit a fraud proof. A withdrawal must wait out that window to be final, unless a third party advances the funds for a fee.
What is data availability and why does it matter? It is whether the rollup's transaction data is actually published on the base layer. If it is, anyone can reconstruct the rollup's state and exit. If it is kept elsewhere, users depend on whoever holds that data.