vitalik.eth (@VitalikButerin): Here is a simplified mathematical model that shows when to move to stage 2.

Here is a simplified mathematical model that shows when to move to stage 2. 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 * Goal: minimize chance of the protocol breaking given the above assumptions * Stage 0 security council is 4-of-7, stage 1 is 6-of-8 Note that these assumptions are very imperfect. In reality, security council members have "common mode failures": they could collude, or all get coerced or hacked the same way, etc. This makes stage 0 and stage 1 both less secure than they appear in this model, and so moving to stage 2 is optimal somewhat earlier than the model implies. Additionally, note that the probability of the proof system breaking can be reduced greatly by making the proof system itself a multisig of multiple independent systems (this is what I advocate in ethereum-magicians.org/t/a-simple-l2-… ). I suspect all stage 2 deployments for the first years will be like this. WIth all this in mind, here's the chart. X axis is probability of the proof system breaking. Y axis is probability of the protocol breaking. 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. TLDR: @l2beat should ideally 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.