# First zk-rollup with Stage 1 confirmed: What it is and why it matters Source: https://x.com/scroll_zkp/status/1916871844151406649?s=46 ## Summary Scroll has become the first zk-Rollup to achieve Stage 1 status with its Euclid upgrade, which was recently approved through Scroll governance. The upgrade adds a permissionless sequencer mode that keeps the network live if the sequencer fails or misbehaves, and it enforces inclusion of Layer 1 user transactions. The article says Scroll's zk proof system was already fully functional, and that a move to a general-purpose zkVM called OpenVM, co-built with @axiom_xyz, enables continuations so that large or forced transactions take longer to prove rather than breaking the rollup. The Security Council has 12 members with a 75% quorum requirement, and upgrades carry a 3-day timelock. ## Article Scroll becomes the first zk-Rollup to achieve Stage 1 status. While Scroll has always had a fully functional zk proof system, users previously had to trust the centralized sequencer to avoid censorship or downtime. That’s no longer the case. The Euclid upgrade, recently approved through Scroll governance, introduces a permissionless mode for the sequencer. This ensures the network remains live even if the sequencer fails or misbehaves. More importantly, it enforces inclusion of Layer 1 (L1) user transactions - making censorship by the sequencer impossible. With Euclid, Scroll becomes not just a type-1 zkEVM, but a Stage 1 Rollup - a major technical and decentralization milestone. In this article, we explain why building a Stage 1 zk-Rollup is uniquely hard, how Scroll solved these challenges, and what’s next. Why Stage 1 Is Especially Hard for zk-Rollups A key requirement for Stage 1 rollups is permissionless force inclusion: users must be able to post transactions to L1 that the sequencer is forced to include on-chain, even if it's offline or censoring. But this creates a big challenge for zk-Rollups. Why? zk Proofs Aren’t Infinite Unlike optimistic rollups, zk-Rollups must generate a zk proof for every block. That proof is generated using a circuit - which has a fixed size limit and cannot prove arbitrary-length programs. If a forced transaction is too large or contains too many zk-unfriendly opcodes (like keccak, extcodesize, etc.), it might exceed the prover's capacity and halt finality of the entire network. A centralized sequencer can mitigate this by simulating the circuit before proposing the block, dropping oversized transactions if needed. Scroll used to do this with a system called the Circuit Capacity Checker (CCC). But this undermines decentralization - it lets a centralized actor decide what users are allowed to do. The solution: Continuations + Recursive Proofs The solution is to break blocks into smaller segments that each fit into a circuit, and then stitch them together recursively using proof aggregation. This continuation approach lets us prove arbitrarily large execution traces - meaning forced transactions can no longer “break” the rollup. Instead of “this tx can't be proven,” we now have “this tx just takes longer to prove.” This is hard to do with rigid zkEVM circuits that hardcode lots of cells and constraints. So we moved to a more general-purpose zkVM architecture - one that’s lighter-weight, extensible, and better suited to proof continuation. How Scroll Achieves Stage 1 Stage 1 - Limited Training Wheels: In this stage, the rollup transitions to being governed by smart contracts. However, a Security Council might remain in place to address potential bugs. This stage is characterized by the implementation of a fully functional proof system, decentralization of fraud proof submission, and provision for user exits without operator coordination. The Security Council, comprised of a diverse set of participants, provides a safety net, but its power also poses a potential risk. Source With @L2BEAT's Stage 1 requirements in mind, let's take a look at how Scroll achieves Stage 1 in more detail in each of the categories with the recent Euclid upgrade. A Production-Ready zkVM: OpenVM To enable continuation and future extensibility, we co-designed and co-built OpenVM with @axiom_xyz. It’s a highly optimized zkVM backend - purpose-built for production use, not just experimentation. OpenVM allows us to: Avoid too many rigid hardcoded constraints of traditional zkEVM circuits. Support continuations for large blocks and forced transactions. Easily implement new EVM features (like EIP-7702) without thinking in raw constraint logic. Leverage the Rust ecosystem to speed up development and testing. This isn’t a simple backend swap. It’s a shift from a hardcoded, opcode-specific zkEVM to a fully programmable zkVM - and it’s a core reason Scroll can now meet Stage 1 requirements. This transition sets Scroll up for rapid feature development, significantly accelerating innovation speed and delivering substantial performance improvements through integration with Reth. A Real Security Council, Not a Rubber Stamp To meet Stage 1 standards, Scroll has established a diverse, technically capable Security Council with real power - and real constraints: 12 members total 75% quorum required to act At least 7 independent members needed for quorum Only 2 members are affiliated with Scroll The council can intervene quickly in emergencies but operates transparently and under clear limitations. Its role is to provide a safety net - not centralized control. User Exit Guarantees: You’re Always in Control One critical Stage 1 feature is user protection from unwanted upgrades. With Euclid: All upgrades must go through governance. Once approved, the Security Council enacts them with a 3-day timelock. The only exception is urgent security fixes - and even those are transparently recorded. This means users always have time to exit safely before an upgrade takes effect. Scroll can’t upgrade the system behind your back or move your funds - a critical protection for users that many rollups still lack. Operator Failures? Users Take Over If Scroll’s sequencer or proposer goes down - or starts censoring - the protocol automatically opens up to anyone. Thanks to Euclid: Anyone can submit blocks and zk proofs through L1. Users’ L1-posted transactions must be included or else the system enters permissionless mode. Once permissionless mode is active, the centralized operator is blocked until re-enabled by the Security Council. This ensures the rollup stays live, provable, and usable - even if Scroll disappears. What’s Next: Toward Stage 2 Stage 1 is a huge milestone, but Scroll is already looking forward. Our next goal is Stage 2. To get there, we’re exploring multi-prover systems and zk + trusted execution environments (TEE) to limit the emergency powers of any single group, including secure council (they can only upgrade if there is bugs in the system). It’s a double-edged sword - the faster you move, the more risks emerge, need to be very programmatic and systematic about how aggressive we want to move to stage 2 with fast iterations for new features. Conclusion With the Euclid upgrade and achieving Stage 1 status, Scroll is poised to become the most performant and secure zk-Rollup available today. We remain true to our mission - delivering @ethereum-level security, scalability, and decentralization without ever cutting corners. The journey ahead is even more exciting, and Scroll is just getting started. We'll continue innovating, bringing even more powerful features and a seamless user experience. The best is yet to come. ## Comments **0x4ee0...1cB3**: L2 beat says it will be downgraded back to Stage 0 https://l2beat.com/scaling/projects/scroll#stage ?