Stage 1 requirements update: Security Council walkaway test

[donnoh]

Abstract

We propose to introduce a new Stage 1 requirement to disallow the active use of the Security Council to provide censorship resistance, liveness and safety guarantees under non-emergency circumstances, i.e. in the absence of bugs. We discuss the motivation behind the proposal, and the list of projects that would be downgraded from Stage 1 to Stage 0 if such requirement is introduced.

Background

In Jan 29, 2025, we announced a major Stage 1 assessment update with the aim of better formalizing its requirements. After a 6 months grace period, the new requirements went into effect, which we report here:

The only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) is by compromising ≥75% of the Security Council.

Assumption: if the proposer set is open to anyone with enough resources, we assume at least one live proposer at any time (i.e. 1-of-N assumption with unbounded N). We don’t assume it to be non-censoring.

As already discussed in that same article, without any further requirement, Stage 1 allows the active use the Security Council (SC) minority (i.e. same signer set but with a <25% threshold) to provide censorship resistance, liveness guarantees (e.g. by being the sole permissioned prover) or safety guarantees (e.g. by being the sole permissioned challenger).

At the time, after extensive discussions with relevant stakeholders, we decided not to address this aspect and leave the above requirements as is. Over time, we noticed an increased willingness from some projects to use such strategies to achieve Stage 1, and a declining interest in hardening proof systems or implementing forced transactions. After several more discussions, we believe that this should not be the intended outcome of the current Stage 1 rules.

Real-world examples

Some of the examples presented here have also been discussed during the Golden Raspberry Awards Of Ethereum Scaling 2025 presentation @ Protocol Berg v2, if you prefer a video version of this section.

Starknet

Today, Starknet makes heavy use of a Security Council minority to satisfy the Stage 1 requirements. In particular, two permissioned operators (i.e. provers) are registered in the rollup, one being the EOA that is in practice used under normal operations, and the other being the 3/12 SC minority.

Source

If the centralized operator is down or censoring, the 3/12 can in principle resume operations, and the system fails “only” if 10/12 members decide not to produce and sign a state update, satisfying the Stage 1 principle. In practice, running a prover requires significant infrastructure and coordination, and it’s not clear whether the Security Council has the ability to cover this role autonomously in a timely manner, especially in the presence of centralized delayed upgrades.

Even assuming it can successfully and timely run a prover, the permissioned operator can in principle frontrun and prevent enforcement of censorship resistance. At the time of writing, the Stages Framework does not take into account frontrunning risk, even though certain projects already account for it in their threat model (e.g. Arbitrum’s BoLD). Moreover, the exact mechanism through which a censored user would need to contact the Security Council has never been specified.

A more robust way to satisfy the Stage 1 principle would be to implement a forced transaction mechanism together with a liveness fallback that opens up proving to everyone if the operator fails.

Kinto

Kinto, an ex-Stage 1 rollup, used to enforce safety of the system by assigning the Security Council minority as a permissioned challenger in their Orbit’s pre-BoLD proof system.

Source

The Stage 1 principle is satisfied because the system is unsafe only if all (8/8) Security Council members refuse to dispute a malicious state root.

Instead of relying on permissioned actors, a more robust approach consists in opening challenge creation to everyone. Unfortunately, the pre-BoLD proof system is vulnerable to severe delay attacks in the absence of a whitelist, and Offchain Labs itself discourages smaller chains from using BoLD because of the high-bond requirements to prevent resource exhaustion attacks.

Scroll

Scroll allows a small multisig to indefinitely pause the chain in case of emergency. This alone wouldn’t allow the chain to be designated as Stage 1, as only the Security Council majority would be able to unpause and therefore a blocking minority could cause a liveness failure.

Source

To address this concern, Scroll has added a Security Council minority multisig with the ability to unpause. With this setup, the only way to cause a permanent liveness failure is by having the Security Council majority vetoing the unpause.

An alternative to this mechanism is to allow the centralized pause to automatically expire. Any centralized delayed upgrade capability should account for such expiration time to maintain an exit window.

Counter-examples (i.e., “good” projects)

Notably, many of the top chains already satisfy the updated Stage 1 requirement. Both Arbitrum One and Stage 1 Superchain chains like Base, OP Mainnet and Ink implement permissionless proof systems and forced transactions to provide liveness and safety.

Arbitrum One contains no privileged multisig that can perform emergency actions outside of the Security Councils majority, even for the pause. On the other hand, the Superchain implements a centralized pause mechanism that automatically expires. Since only the Security Council can upgrade the contracts, there’s no concern regarding upgrade delays.

The proposal

We propose to make the Stage 1 designation stricter by introducing the following requirement:

The previous requirement must hold even if the Security Council is permanently inactive.

An effect of this requirement is that then the only difference between Stage 1 and Stage 2 is strictly reduced to upgradability, as Stage 2 already naturally requires all the security features to be implemented. In other words, the role of the Security Council is restricted to emergency actions and protocol upgrades.

Next steps

If the proposed change is welcomed by the community and the relevant stakeholders, a 6 months grace period would be started to allow affected projects to adapt to the new requirement before being downgraded.

[Eitan]

Counter Proposal

Abstract

The proposed “Security Council permanently inactive” assumption is a Stage 2 autonomy bar, not a Stage 1 refinement. Keep Stage 1 stable; designate Stage 2 as the home for censorship-resistance mechanisms in practice — specifically, forced transactions and sequencing decentralization — and move the current “fully code-controlled end-state” requirements into Stage 3.

————————————————————————————————

We support strengthening censorship-resistance and liveness guarantees over time, and we appreciate the effort to clarify how these properties should be measured. That said, we think the proposed new requirement — “the previous requirement must hold even if the Security Council is permanently inactive” — is a Stage 2 autonomy requirement rather than a Stage 1 refinement.

It changes the trust model from “recoverable assuming an honest SC majority” to “fully self-sufficient even if governance disappears.”

In parallel, we believe the dominant trust assumption in the medium term is not “SC inactivity,” but who can propose blocks and include transactions, and whether users have a mechanical enforcement path if they are censored.

For that reason, we suggest Stage 2 should explicitly incorporate two concrete, measurable pillars that directly address censorship risk in normal operations:

• Forced transactions + liveness fallback (with a clear, bounded maximum delay for enforcement), and

• Sequencing decentralization (e.g., multi-operator block proposal with defined quorum/threshold rules and a credible path toward permissionless participation).

Therefore, our counter-proposal is:

1. Keep Stage 1 semantics stable (do not add the “SC permanently inactive” assumption to Stage 1).

2. Keep protection from the “inactive security council” requirement in Stage 2, and define Stage 2 around the ability of users to permissionlessly affect sequencing through forced transactions and sequencing decentralization, as the practical mechanisms that reduce censorship power.
   One of the reasons for decentralized sequencing: Forced transactions are very time-insensitive and are inapplicable to many DeFi use-cases, where liquidations can be completed in seconds. Decentralized sequencing is done immediately and is much more applicable when real funds are involved.

3. To preserve a clear progression, move the current Stage 2 “fully code-controlled end-state” requirements (e.g., permissionless proof/challenge systems, long upgrade exit windows, and SC restricted strictly to adjudicable on-chain bug conditions) into a Stage 3 tier. Stage 3 can then be defined as “protection from a malicious security council”, in line with the previous stages, where assumptions around the security council are gradually reduced.

Finally, as noted in the proposal, adopting “SC permanently inactive” as a Stage 1 requirement would largely collapse the Stage 1 ↔ Stage 2 distinction into “upgradability-only”, while disregarding the other censorship-resistance mechanisms between Stages. We view preserving a meaningful ladder as important: keep Stage 1 stable, use Stage 2 to measure concrete censorship-resistance mechanisms — such as forced transactions and sequencing decentralization — and reduce Stage 3 to upgradability as L2Beat proposed.