For an L2 claiming "decentralization", you must first examine two hard indicators—whether an exit window exists and who holds the upgrade authority. The exit window determines whether you can safely withdraw your assets if an unwanted upgrade occurs. The upgrade authority determines who has the power to change the rules. Without verifying these two, any other "decentralization" narrative lacks substantive support.
1. Why the "Exit Window" Is the Fundamental Safety Bottom Line
The Exit Window is the "escape passage" L2 provides to users—when an upgrade you do not accept happens, you can withdraw your assets from L2 back to L1 within a limited time.
L2Beat's analysis of 129 L2 projects in July 2025 revealed a sobering statistic: approximately 86% of projects have no exit window, and contracts can be upgraded at any time. This means if the project party is hacked or maliciously controlled, users have no buffer time to retrieve assets to L1, and an upgrade can be executed without any user awareness.
L2Beat's Stage framework sets clear requirements for the exit window:
| Stage | Exit Window Requirement |
|---|---|
| Stage 1 | Upgrades not initiated by the Security Council require ≥7 days exit window; Security Council can perform instant upgrades |
| Stage 2 | Security Council can only perform instant upgrades when an on-chain vulnerability is detected; otherwise, exit window ≥30 days |
In June 2026, Aztec revoked the ownership of the rollup contract through on-chain governance, making the contract immutable and preserving an "escape hatch" mechanism that allows users to exit at any time, thus achieving the L2Beat Stage 2 rating. This case illustrates: the exit window is not an optional feature but a hard threshold for Stage 2-level decentralization.
2. Upgrade Authority: Who Can "Change the Rules"
Solana founder Anatoly Yakovenko pointed out in October 2025: L2 faces the same fundamental risk as cross-chain bridges—multi-sig can upgrade the contract and move assets without user knowledge. He refuted the claim that "multi-sig architectures are more complex and therefore safer," emphasizing that the key issue is whether there exists a set of keys not controlled by users that can directly operate funds.
This judgment points to a core question: if the upgrade authority of an L2 is controlled by a small group (e.g., 4/7 or 6/8 multi-sig), then the mechanism is essentially still centralized. Even if it claims to "inherit Ethereum's security," as long as the multi-sig can unilaterally upgrade the contract, this claim does not hold.
Academic research corroborates this: an analysis of power across 129 L2 projects shows decision-making power is concentrated in multi-sig governance bodies, centralized sequencers, and core development teams. These roles can upgrade contracts or change security parameters without meaningful community consent or user appeal channels. About 50% of projects face the risk of "proposer failure"—meaning only whitelisted proposers can post state roots on L1, and if a failure occurs, withdrawals will be frozen.
3. Practical Steps: Two Steps to Determine If an L2 Is Truly "Decentralized"
Step 1: Check the project's Stage rating and exit window status on L2Beat
What to do: Open L2Beat (l2beat.com) and search for the project you are interested in.
How to do it: Check whether the project page has a "Stage 1" or "Stage 2" label. Expand the Risk Summary module and look at the "Exit Window" item:
If it shows "None" or "No exit window," it means the contract can be upgraded at any time and users have no exit window.
If it shows "7 days" or "30 days," it means at least basic protection exists.
When it is considered done: You have confirmed the exit window status and Stage rating of the L2 project. If there is no Stage label and no exit window, the project is still in the "training wheels" phase.
Step 2: Check the control structure of upgrade authority (who controls the multi-sig)
What to do: In L2Beat's "Risk" panel or project documentation, find the description of "Upgrade Governance" or "Security Council."
How to do it:
Case A (project has reached Stage 1): Upgrades require ≥6/8 multi-sig approval, and the Security Council has a quorum to block a subset. This is "with a certain threshold" but still carries centralization risk.
Case B (project has reached Stage 2): The Security Council can only intervene when two proof systems (e.g., OP and ZK) contradict each other and cannot respond arbitrarily. This is the state of highest decentralization.
Case C (project is still Stage 0): The Security Council has full control, and proof systems are only "advisory." In this case, the credibility of any "decentralization" claim is extremely low.
When it is considered done: You have identified the upgrade control structure of the L2 and determined whether it is "people-controlled" or "rule-controlled."
Prerequisite: You are evaluating the security or decentralization level of an L2 project.
Risk reminder: Even if a project has reached Stage 2, you still need to verify whether the Security Council members are sufficiently decentralized. L2Beat recommends that the Security Council be a multi-sig with at least 8 members, a 75% consensus threshold, and members from different companies and jurisdictions. If the Security Council members are highly concentrated (e.g., multiple people from the same organization), the credibility of the Stage 2 certification is still discounted.
After completing the above checks, how do you confirm that an L2 is truly trustworthy?
On L2Beat, look up the project's Stage rating and exit window status. If the project is still at Stage 0 and has no exit window, it still relies on "training wheels," and any claim of "decentralization" should be treated with a high degree of skepticism. Only when it has at least reached Stage 1 (has an exit window, upgrades require multi-sig approval) is it worth further evaluation. If it is at Stage 2 (contracts immutable, the Security Council cannot unilaterally do evil), it demonstrates that substantial effort has been put into decentralization—then make your judgment based on your capital scale and risk appetite.
