# The math of when stage 1 and stage 2 make sense Source: https://vitalik.eth.limo/general/2025/05/06/stages.html ## Summary Under a simplified model, stage 0 rollups are almost never justified, and a rollup should launch at least directly into stage 1. The model assumes each security council member has an independent 10% chance of breaking, which gives a stage 0 rollup a fixed 0.2728% chance of failing with a 4-of-7 council. To address concerns that slow 6-of-8 signing could delay fixing a critical bug, the text suggests letting any single council member delay withdrawals by one or two weeks. It also cautions against rushing to stage 2 at the expense of hardening the proof system. ## Article 2025 May 06 See all posts The math of when stage 1 and stage 2 make sense Expanded on from this earlier draft: https://x.com/VitalikButerin/status/1919263869308191017 The three "stages" of Ethereum rollup security can be described in terms of when a security council is allowed to override trustless (ie. pure cryptographic or game-theoretic) components: Stage 0: security council has full control. There may be a proof system (optimistic or ZK) running, but a security council can overturn it with a simple majority vote. Hence, the proof system is "advisory only". Stage 1: security council can override with 75% (at least 6-of-8) approval. A quorum-blocking subset (ie. >= 3) must be outside the primary organization. Hence, there is a high, but not impassable, barrier to overriding the proof system. Stage 2: security council can only act in case of provable bugs. Provable bugs could be eg. two redundant proof systems (eg. OP and ZK) disagreeing with each other. And if there are provable bugs, it can only choose between one of the proposed answers: it cannot answer arbitrarily. We can model this with a chart showing "what share of the vote" the security council has at each stage: One important question to ask is: when is it optimal for an L2 to move from stage 0 to stage 1, and from stage 1 to stage 2? The only valid reason to not go to stage 2 immediately is that you do not fully trust the proof system - which is an understandable fear: it's a lot of code, and if the code if broken, then an attacker could potentially steal all of the users' assets. The more confidence you have in your proof system (or, conversely, the less confidence you have in security councils), the more you want to move towards the right. It turns out that we can quantify this with a simplified mathematical model. First, let's list the assumptions: Each security council member has an independent 10% chance of "breaking" We treat liveness failure [refusal to sign or keys inaccessible] and safety failure [signing a wrong thing or keys hacked] as equally likely. In fact, we just assume a single category of "broken" where a "broken" security council member both signs the wrong thing and fails to sign the right thing In stage 0, the security council is 4-of-7, in stage 1 it's is 6-of-8. We assume a single monolithic proof system (as opposed to a 2-of-3 design where the security council could break ties if the two disagree). Hence, in stage 2 the security council does not matter at all. Given these assumptions, and given a particular probability of the proof system breaking, we want to minimize the probability of the L2 breaking. We can do this with binomial distributions: If each security council member has an independent 10% chance of breaking, then the chance that at least 4 of 7 will break is \(\sum_{i=4}^7 {7 \choose i} * 0.1^i * 0.9^{7-i} = 0.002728\) Thus, a stage 0 rollup has a fixed 0.2728% chance of failing. A stage 1 rollup can fail if either the proof system fails and the security council gets >= 3 failures so it can't override (probability \(\sum_{i=3}^8 {8 \choose i} * 0.1^i * 0.9^{8-i} = 0.03809179\) multiplied by the proof system failure rate), or if the security council gets 6+ failures and can force an incorrect answer by itself (fixed \(\sum_{i=6}^8 {8 \choose i} * 0.1^i * 0.9^{8-i} = 0.00002341\) probability) The chance that a stage 2 rollup will break is just equal to the probability that the proof system fails Here it is in graph form: As conjectured, as proof system quality increases, the optimal stage shifts from stage 0 to stage 1, then stage 1 to stage 2. Doing stage 2 with a stage-0-quality proof system is worst of all. Now, note that the assumptions in the above simplified model are very imperfect: In reality, security council members are not independent, and have "common mode failures": they could collude, or all get coerced or hacked the same way, etc. The requirement to have a quorum-blocking subset outside the primary organization is meant to mitigate this, but it is still far from perfect. The proof system could itself be a combination of multiple independent systems (this is what I advocate in https://ethereum-magicians.org/t/a-simple-l2-security-and-finalization-roadmap/23309... ). In this case, (i) the probability of a proof system breaking could end up very low, and (ii) even in stage 2, security councils matter, as a matter of tiebreaking. These two arguments both imply stage 1 and stage 2 are both even more attractive than the chart shows. If you take the math seriously, stage 0 is pretty much never justified: you should launch at least straight into stage 1. The main argument that I hear against is: if a critical bug happens, it may be too hard to get 6 of 8 security council members to sign fast enough to fix it. But there is an easy way around this: give any single security council member the permission to delay withdrawals by 1 or 2 weeks, giving everyone else enough time to act. At the same time, however, it is a mistake to jump to stage 2 too quickly, especially if work to move to stage 2 happens at the expense of work to harden the underlying proof system. Ideally, data providers like l2beat should show proof system audits and maturity metrics (ideally of the proof system implementation, not the rollup as a whole, so we can reuse) along with the stage.