A Layer 1 is the base blockchain: its own validators, consensus and transaction history. A Layer 2 runs transactions somewhere else and posts the data back to the Layer 1. It relies on the Layer 1 for security, which makes it cheaper to use without building a new security model from scratch. On Ethereum, the main Layer 2 design is the rollup. Since December 2025, Ethereum upgrades have mostly been about giving rollups more room to post their data.
The two layers in one sentence each
ethereum.org describes Layer 1 as "the underlying foundation that layer 2 projects build on top of". That covers node operators, block producers, the transaction history and the consensus mechanism.
It defines a Layer 2 as a separate chain "that extends Ethereum and inherits the security guarantees of Ethereum".
The phrase "inherits the security" has a specific mechanism behind it, covered in the next section. A network that does not meet that test is not a Layer 2 in Ethereum's terms, whatever it calls itself.
How a rollup inherits Layer 1 security
Per ethereum.org, rollups "bundle (or 'roll up') hundreds of transactions into a single transaction on layer 1". Transactions run on the rollup, and the transaction data goes to Ethereum. The security claim follows from that step: "once the data is uploaded to layer 1, reverting a rollup transaction requires reverting Ethereum."
Ethereum is therefore also a data availability layer. Anyone can use the published data to rebuild the rollup's state or challenge a bad result.
Rollups post that data in one of two forms:
- Calldata: kept permanently in Ethereum's history.
- Blobs: cheaper. Ethereum guarantees them for about 18 days and then prunes them.
Optimistic rollups
ethereum.org says optimistic rollups assume transactions are valid unless someone challenges them.
- Challenge window: after a batch is posted, there is a window, which ethereum.org puts at "roughly seven days", for anyone to submit a fault proof.
- Failed batch: if a challenge succeeds, the rollup re-executes the disputed transactions and the sequencer is penalised.
- Withdrawals: moving funds from the rollup back to Ethereum through the rollup's own route waits out that window. Messages from Ethereum to the rollup are "typically executed after some minutes."
Zero-knowledge (ZK) rollups
A ZK rollup posts a validity proof with each batch, which ethereum.org calls "a succinct cryptographic commitment verifying the correctness of batched transactions." Ethereum's verifier contract checks the proof before it accepts the new state.
- Withdrawals: ethereum.org says "There are no delays when moving funds from a ZK-rollup to Ethereum" once the proof is verified.
- Proof cost: making proofs is resource-intensive, and checking one on Mainnet costs roughly 500,000 gas. That cost can show up in user fees.
- Compatibility: ZK rollups are not directly EVM-compatible. A zkEVM tries to close that gap.
- Other drawbacks named by ethereum.org: proving may need specialised hardware, which could centralise control. Some proof systems need a trusted setup.
Sidechains are not Layer 2
ethereum.org draws the line directly: "Unlike layer 2 scaling solutions, sidechains do not post state changes and transaction data back to Ethereum Mainnet." A sidechain "doesn't inherit Ethereum's security properties". It runs its own consensus, such as proof-of-authority, delegated proof-of-stake or Byzantine fault tolerance.
A sidechain can be fast and cheap, but its security is only as strong as its own validator set.
Is that network really a Layer 2?
Answer up to four questions about a network that calls itself Layer 2 to see where its security comes from and what you still depend on.
Does the network post its transaction data back to the Layer 1, as calldata or blobs?
- Yes, the data goes to the Layer 1 → next question
- No, it keeps the data elsewhere and runs its own consensus → A sidechain, not a Layer 2
- I don't know → Check where the data goes first
Which proof system does it use? With fault proofs (optimistic rollup), withdrawals through the rollup's own route wait out a challenge window of roughly seven days. With validity proofs (ZK rollup), there is no delay once the proof is verified.
- Fault proofs (optimistic rollup) → next question
- Validity proofs (ZK rollup) → next question
If the sequencer delays your transaction past the set maximum, can you submit it directly to the rollup contract on the Layer 1?
- Yes, forced inclusion through the Layer 1 exists → next question
- No, or I can't tell → You depend on the sequencer
Which L2BEAT stage is the network?
- Stage 0 → Stage 0: data and a proof system, few other guarantees
- Stage 1 → Stage 1: Security Council and a 7-day exit window
- Stage 2 → Stage 2: permissionless proofs and 30 days to exit
- Not listed, or I don't know → Upgrade risk unknown
If it does not post its data back to Ethereum, it does not inherit Ethereum's security. It can be fast and cheap, but its security is only as strong as its own validator set.
This decides whether it is a Layer 2 at all. Once the data is on the Layer 1, anyone can use it to rebuild the rollup's state or challenge a bad result. Without that, the Layer 1 offers no such check.
The escape route ethereum.org describes is submitting transactions directly to the rollup contract on the Layer 1. Without it, a single sequencer that delays you decides when your transaction gets in.
State roots and data are on the Layer 1 and a proof system exists. It does not meet the Stage 1 conditions: the 75% Security Council threshold and the 7-day exit window. The bridge you use carries its own smart contract risk.
Barring bugs, blocking or forging a withdrawal indefinitely requires compromising at least 75% of a Security Council. Upgrades from outside the Council must give users at least a 7-day exit window. Stages measure decentralisation, not protection against bugs, and the bridge you use is a separate risk.
Fault proofs are permissionless, and users get at least 30 days to exit before unwanted upgrades take effect. Stages measure decentralisation, not protection against bugs. Trusted and trustless bridges both still carry smart contract risk.
Without a stage, you don't know who could block or forge a withdrawal, or whether you get an exit window before upgrades. Check the stage and the bridge before relying on the network.
This walks through the article's design questions only: it does not rate any specific network, measure current fees or speeds, or check a rollup's or bridge's code for bugs.
Speed and cost: where the savings come from
A Layer 2 is cheaper mainly because many transactions share one Layer 1 posting cost. Ethereum has also made that posting cheaper in several steps.
| Date | Change | What it did for Layer 2s |
|---|---|---|
| 13 March 2024 | Dencun upgrade (EIP-4844) | Added blobs, which ethereum.org says "significantly reduces the cost of rollups" |
| 3 December 2025 | Fusaka upgrade (PeerDAS, EIP-7594) | Each full node stores only part of the blob data, about one-eighth, which ethereum.org says allows up to 8x theoretical blob scaling |
| 9 December 2025 | BPO1 (EIP-8134) | Blob target raised from 6 to 10, maximum from 9 to 15 |
| 7 January 2026 | BPO2 (EIP-8135) | Blob target raised to 14, maximum to 21 |
BPO stands for "blob parameter only". EIP-7892 defines these as upgrades that change only blob settings "through configuration", with no client code changes. The dates for BPO1 and BPO2 come from the activation timestamps in their EIPs.
More blob space does not guarantee low fees at any given moment. Fees still depend on demand for the rollup and for blob space.
Where trust actually sits
Calling a network "Layer 2" says how it connects to Ethereum. It does not say how much users depend on its operators. Three points decide that.
The sequencer
ethereum.org says some rollups use a single sequencer that orders transactions and is the only party allowed to submit batches to the onchain contract. Users have an escape route: if the sequencer delays them past a set maximum, they can submit transactions directly to the rollup contract on Layer 1.
Upgrade keys and exit windows
L2BEAT's Stages framework grades rollups on decentralisation:
- Stage 0: state roots and data are on Layer 1, and a proof system exists.
- Stage 1: blocking or forging a withdrawal indefinitely requires compromising at least 75% of a Security Council, barring bugs. Upgrades from outside the Council must give users at least a 7-day exit window.
- Stage 2: fault proofs are permissionless, and users get at least 30 days to exit before unwanted upgrades take effect.
L2BEAT notes that the stages measure decentralisation and trust minimisation, not protection against bugs.
Bridges
Getting assets onto a Layer 2 usually means bridging. ethereum.org separates trusted bridges, which "depend upon a central entity or system", from trustless bridges, which "operate using smart contracts and algorithms." Both carry smart contract risk, which ethereum.org defines as "the risk of a bug in the code that can cause user funds to be lost". As an example, ethereum.org says 120,000 wETH (about $325 million) was stolen in the Wormhole bridge hack.
Layer 2 beyond Ethereum
The term is also used for Bitcoin. The Lightning Network describes itself as built on "Bidirectional Payment Channels". Payments move "off-blockchain" and are enforced with "real Bitcoin/blockchain transactions". Lightning does not work like a rollup: it does not post every transaction's data to Bitcoin. The label means different things on different chains.
Checklist for any network called Layer 2
- Does it post its transaction data to the Layer 1, or keep it elsewhere?
- Does it use fault proofs (with a withdrawal window of about seven days) or validity proofs?
- Who runs the sequencer, and can you force a transaction through Layer 1?
- Which L2BEAT stage is it, and how long is the exit window before upgrades?
- Which bridge are you using, and who controls it?
For the fee mechanics behind all of this, see our explainer on how gas fees work on Ethereum.
Limitations: this article explains designs and does not measure current fees, speeds or the risk of any specific network.
