[ZIP-XX] Dissolution of the ZKsync Guardians

Proposal Type ZIP, TPP, GAP
One Sentence Summary This ZIP proposes dissolving the Guardian entity and transfer roles held by the Guardians within the governance system to the ZKsync Foundation.
Proposal Author ZKsync Guardians
Proposal Sponsor Pending
Date Created October 2026
Version v1
Summary of Action Transfers the Guardians’ onchain roles on the ZIP, TPP and GAP governors to the ZKsync Foundation, and replaces the Emergency Upgrade Board with a new board requiring approval from the Security Council and the ZKsync Foundation only.
Link to Contracts Pending

Abstract

This governance proposal proposes simplifying the current governance system by dissolving the Guardian entity, removing them from their formal governance roles onchain. If approved, this proposal will remove the Guardians from the Emergency Upgrade Board, and transfers Guardian veto and fallback approval rights in respect of the three governors (ZIPs, TPPs, and GAPs) to the ZKsync Foundation.

Please note that three onchain proposal will be submitted, one for each of the governors (ZIP, TPP, GAP). Each will have relevant call data for each governor.

Motivation

Since the launch of ZKsync governance two years ago, the ZKsync Guardians have played an important role in the governance system, holding a veto power over governance proposals. Now, ZKsync is entering a different stage. The protocol has matured, governance processes have been tested through multiple ZIPs.

This proposal continues the process of governance alignment to institutional partner needs by simplifying governance further and dissolving the Guardian entity, while preserving the veto security model.

Prividium requires an institution-focused governance model

ZKsync’s strategic focus is increasingly shaped by Prividium operators and institutional adoption.

This shift changes the type of stakeholders the governance system must be capable of supporting. Institutional counterparties favor simplified accountability, while maintaining predictable governance processes, recognised legal and operational structures, and defined decision-making authority.

A broad public-facing Guardians body was appropriate in the early days of the protocol governance. It is less suited to the next phase, where the governance system must be easier for institutional stakeholders to understand, evaluate, and rely on.

As ZKsync moves toward institutional-grade adoption, governance should become simpler, more legible, and more directly tied to accountable governance participants.

This proposal reflects the natural evolution of ZKsync governance from a launch-phase model supported by public-facing legitimacy mechanisms toward a mature, optimistic, and enterprise-ready governance system.

Specification

If approved, this ZIP would remove the ZKsync Guardians as an onchain governance body and implement the following governance changes:

1. Transfer of Guardian Governance Veto Rights

The following Guardian rights under Schedule 4 of the Governance Procedures are transferred to the ZKsync Foundation:

  • the Onchain Veto over proposals submitted to the Token Governor (TPPs) and the GovOps Governor (GAPs);

  • the Offchain Veto over proposals submitted to the Protocol Governor (ZIPs) during the Offchain Veto Period; and

  • the right to extend the Offchain Veto Period from three (3) to seven (7) days.

References to a Guardian veto in the Governance Procedures will be updated to a Foundation veto, unless later amended by a governance proposal or replaced by a Token Assembly Delegate veto period under an optimistic governance process.

2. Removal of the Guardian Fallback Approval

The Guardians’ right to approve a Protocol Governor proposal during the Risk Review Period, where the Security Council is unwilling or unable to approve it (Schedule 4, Section 6), is transferred to the ZKsync Foundation.

3. Removal from the Emergency Upgrade Board

The current Emergency Upgrade Board currently requires approval from three parties: the ZKsync Guardians, the ZKsync Security Council, and the ZKsync Foundation. These signers are fixed in the board contract and cannot be changed in place.

This proposal deploys a new Emergency Upgrade Board requiring approval from two parties:

  • the ZKsync Security Council; and

  • the ZKsync Foundation.

On execution, the Protocol Upgrade Handler is updated to the new board via updateEmergencyUpgradeBoard.

4. Dissolution of the Guardians Entity

Approval of this proposal constitutes the GovOps Governor Approval required under Article 5.1.1 of the ZKsync Guardians Bylaws and formally requests that the Guardians’ Board of Directors dissolve the ZKsync Guardians entity. Separately, upon execution, the Guardians Multisig will no longer have any formal role, authority, approval right, veto right, consultation right, appointment right, or other governance function within the ZKsync governance system.

5. Updates to Governance Documentation and Processes

This proposal requests that the ZKsync Association support in updating any governance documentation, legal entity documents, bylaws, operating procedures, governance interfaces, contracts, or offchain processes that reference the Guardians. They should reflect their dissolution and the transfer, removal, or replacement of their governance functions.

6. 2025-2026 Guardian Capped Minters

This proposal does not revoke or pause the capped minters established under TPP-7. The Guardians Operational Multisig (0x06E19F3CEafBC373329973821ee738021A58F0E3) keeps its roles on those contracts. It is separate from the Guardians Multisig whose governance functions are removed above.

The 2025–2026 compensation minter (0x1358f460bd147c4a6bfdab75ad2b78c837a11d4a) remains available to the Guardians until its onchain expiry on 31 October 2026. After that date, any unminted balance can no longer be minted. Tokens already minted are unaffected and remain claimable under their existing vesting terms.

Conclusion

This proposal proposes dissolving the ZKsync Guardians as a formal governance body.

This change recognizes that ZKsync has moved beyond its launch and early governance phase and now requires a governance model for institutional partners.

The Guardians served an important role in the launch of ZKsync governance and throughout the two years that followed. That role is now complete.

Dissolving the Guardians is a natural next step in aligning ZKsync governance with the development of Prividium, and the institutional stakeholders that will shape the next phase of the ZKsync ecosystem.

1 Like

Hi there!

We want to acknowledge the important role the Guardians have played during the early stages of ZKsync, while also supporting the decision to wind down the role in light of the protocol’s current and anticipated direction.

At the same time, we believe it is important to preserve the safeguards that remain guaranteed by the Emergency Upgrade Board under its new composition.

Two things the chain says about the dissolution: ZIP-18 installs an Emergency Upgrade Board that still checks Guardians signatures, and the L2 veto on Token and GovOps proposals is hard-wired to today’s Guardians.

Thanks to the authors of both threads for laying the pieces out. I replayed ZIP-18 stage 0 on a fork of Ethereum block 26,175,985 and read each seat’s requirements on-chain. No opinion on the dissolution itself, just the numbers.

Action Required today After dissolution, as proposed
Emergency upgrade (no legal veto, no delay) Guardians 5/8 + Council 6/8 + Foundation 3/6, 14 approvals of 22 Council 6/8 + Foundation 3/6, 9 of 14
Extend the legal veto Guardians 2/8 Foundation
Fallback approval Guardians 5/8 Foundation
Cancel a TPP or GAP on L2 Guardians 5/8, via L1 to L2 Foundation

• Each Guardian and Council member is itself a Safe: 14 signatures of 52 keys today, 9 of 44 after. No address sits in two sets.
• ZIP-18 stage 0, call 3, re-initialises the Handler with a new Council, new Guardians (same 8 members) and board 0x9198…4b7c, whose GUARDIANS() points to the new Guardians. On the fork, emergencyUpgradeBoard() returns it afterwards.
• On ZKsync Era, VETO_GUARDIAN on the Token and GovOps governors is the L2 alias of today’s Guardians, an immutable in the published source. A cancel from the new Guardians’ alias, or from the Foundation, reverts Unauthorized() in simulation.

Same test on 14 other contracts, with the calls to rerun: The holder of a role is not always the one who executes it: one measured case

One question I could not answer from the chain (the dissolution contracts are still pending): is it meant to execute after ZIP-18 with a board that no longer lists Guardians, and how does the L2 veto move to the Foundation on the two governors that hard-code it?

Hey @Spap: I just asked about your question and confirmed with engineering that this proposal would need to be executed after current v31 resubmission.