You'll see "Stage 1" on L2Beat and most developers treat it as a good sign — higher is better, move on. But it's a specific security model with specific requirements. Scroll crossed into it with the Euclid upgrade in April 2025.
The three stages
L2Beat defines rollup maturity in three stages. The progression isn't about performance — it's about who can stop you from getting your money out.
Stage 0 is where most rollups start. The validity proof system may be live, but user protections are thin: the operator can censor transactions, the team controls upgrade keys unilaterally, and there's no guaranteed exit path that doesn't depend on the team cooperating. You're trusting that the people running it won't act against you.
Stage 1 adds three things:
- Forced transaction inclusion. If the sequencer ignores your transaction, you can submit it directly to the L1 inbox contract. The sequencer can't censor you indefinitely.
- Permissionless batch submission. If the sequencer fails to post a batch within a defined window — the Liveness Gap — any user can submit a batch and a validity proof directly to the L1 contract to move state forward. The chain doesn't die with its operator.
- Security Council with independent majority. Upgrade keys move from team-controlled multisig to a council where independent members hold the majority. For Scroll, that's a 9-of-12 multisig — 7 of the 9 required signers are not Scroll employees. The team cannot push a protocol upgrade unilaterally.
Stage 2 removes trust in the Security Council as well. Exit is fully guaranteed by code, not governance. No rollup has reached Stage 2 yet — Arbitrum has removed the whitelist for fraud proofs, but retains a Security Council emergency override for bug fixes, most researchers still call it Stage 1.
What Euclid actually changed
Before Euclid, Scroll's prover used custom halo2 arithmetic circuits — one circuit gadget per EVM opcode, hard capacity ceiling per batch. Valid state transitions required the proof system, but forced inclusion and permissionless batch submission weren't live.
Euclid shipped in two phases: Phase 1 on April 16, 2025, Phase 2 on April 22. Forced inclusion went live — users can now submit directly to the L1 inbox contract if censored — and the Security Council replaced team-controlled upgrade keys. Scroll also replaced the prover stack with OpenVM (a RISC-V zkVM built with Axiom and the Ethereum Foundation's PSE team), which delivered the 5× throughput and ~50% fee reduction, and migrated the state commitment from Scroll's custom zktrie to Ethereum's standard Merkle-Patricia Trie.
The ZK validity proofs were already live before Euclid. What Euclid added was the exit guarantees and independent upgrade control.
What this means for a contract you deploy today
For a simple storage contract: every state transition is cryptographically verified, so an adversarial sequencer can't produce an invalid state root without generating an invalid proof. If the sequencer goes rogue, your funds aren't trapped — unlike an Optimistic rollup where exit requires a 7-day fraud proof window, the validity proof proves your exit is valid immediately once the batch is finalized on L1. A protocol upgrade still requires sign-off from independent members who can block it.
None of this is full decentralization. A single sequencer still handles transaction ordering, and Stage 2 is the actual end state — nobody's there yet. But the trust assumptions are different from a Stage 0 chain where "we're a reputable team" is the primary protection.
It matters most when evaluating chains for anything with real money in it. For the Proof of Support rubric, it's part of why Scroll's ecosystem score sits where it does — even as Scroll has shifted focus from the points-farming TVL chase of 2024 toward Total Value Secured (TVS) and technical alignment.
→ The build this came from: Week 2 retrospective on Scroll
→ The live app is at https://proof-of-support.pages.dev
→ Scoring methodology for the series: How I'm Scoring the Chains
Top comments (0)