Summary: Activate optimistic governance for ZIPs by deploying the council, veto, and supermajority contracts created by Scopelift, and set parameters outlined in the Specification section.
| Field | Details |
|---|---|
| Title | Activate Optimistic Governance for ZIPs |
| Proposal Type | ZIP |
| One Sentence Summary | This ZIP activates Optimistic Governance for ZIPs which allows Security Council members to propose protocol upgrades and for the Token Assembly to veto any ZIP prior to execution. |
| Proposal Author | ZKsync Association |
| Proposal Sponsor | [TBC] |
| Date Submitted | [TBC] |
| Version | 1 |
| Summary of Action | Activate optimistic governance for ZIPs by deploying the council, veto, and supermajority contracts created by Scopelift, and set parameters outlined in the Specification section. |
Abstract
This proposal activates Optimistic Governance for ZIPs. Security Council members will propose protocol upgrades and the Token Assembly will have the opportunity to veto any ZIP before it can proceed to execution. This removes the requirement for the Token Assembly to affirmatively approve every ZIP and focus voting on Token Program Proposals and Governance Advisory Proposals, while preserving its ability to veto a proposal.
Motivation
ZIPs are technical proposals that can upgrade the ZKsync protocol, its core contracts, and the governance system. The Security Council currently has responsibility for reviewing and approving protocol upgrades before they are executed. Allowing Security Council members to propose ZIPs places responsibility for driving upgrades with the governance body best positioned to assess them.
Under the current process, every ZIP must receive at least 630 million ZK in affirmative votes and a simple majority of votes cast. This means a proposal can fail because it does not reach quorum, even where there is no material opposition. It also requires the Token Assembly to approve technical changes before the Security Council completes its review.
Optimistic Governance shifts the Token Assembly’s role from approving every ZIP to having the ability to veto any ZIP, as well as increasing their focus on token programs, mechanics, and governance advisory. Once adopted, optimistic governace means protocol upgrade proposals can proceed without an affirmative Token Assembly vote, but 630 million ZK can stop it. A veto can only be overridden if at least 1.26 billion ZK votes For and there are more For votes than Against votes. This allows technical experts to drive protocol upgrades while keeping the Token Assembly as a check on whether they proceed.
This ZIP only changes the Protocol Upgrade path. The Token Governor (TPPs) and GovOps Governor (GAPs) are unchanged.
Specification
This proposal deploys a council token, a Council Governor, a Veto Governor, a Supermajority Governor, and a dedicated supermajority timelock on ZKsync Era. It reuses the existing Protocol Timelock so that successful proposals continue to reach the existing ProtocolUpgradeHandler on Ethereum.
Changes Proposed
1. Security Council proposal process
Each of the eight Security Council member entities will receive one non-transferable and non-delegable seat through CouncilERC20. Each seat will be held by that member entity’s SAFE multisig on ZKsync Era.
A seated member of the Security Council may submit a proposal through BasicCouncilGovernor. Any Security Council member entity can submit a protocol upgrade onchain. This submission equates to that entity sponsoring the ZIP. It is expected that the sponsor of the ZIP then casts a vote ‘FOR’ the proposal. One Security Council member entity voting FOR is sufficient to forward the proposal to the Token Assembly veto stage. The Security Council voting delay will be one day, enabling proposals to be cancelled and resubmitted if there is an error in the initial submission. The council voting period will be a maximum of three days. A one-seat super-quorum allows a proposal to advance as soon as the first valid FOR vote is cast.
The ZKsync deployment will use council vote-counting logic under which a valid FOR vote from one seat satisfies sponsorship regardless of Against votes. This preserves the intended one-member sponsorship model and prevents the council stage from becoming a separate majority-approval gate.
A successful council proposal is forwarded to the Veto Governor. It cannot be queued directly for execution through the Council Governor.
Council Members:
- Matter Labs: 0xe38dc029623f0af56BdC46E5318610E257d6b760
- Nethermind: 0x870Ec9631E28ee6C8b304e238E9b6890a99ab8aA
- Open Zeppelin: 0x305798C076B64Be35Aa6367C6632b79e29D0113A
- Spearbit: 0x356cF4Ac9fA86F0a9dDdc62e48082FE5Cd14bE7b
- Chainlight: 0x3043bF9c9A512d20Dda2c2b2C3D69AF6f7Fcd5B1
- Cyfrin: 0x9BC8d216d63b38c390e465D664FEb63B67659c13
- Dedaub: 0xdbc2E250cBA867D6619Bed342Ca3Eca7b71e8b82
- Peckshield: 0x46fc9a8A72456c84F42c5c9e5df46984c0078B15
2. Token Assembly veto process
Every proposal forwarded by the Council Governor will enter a Token Assembly veto process through BasicCouncilVetoGovernor. Delegated ZK voting power may cast veto votes during the configured veto period.
A proposal succeeds by default unless veto votes reach 630 million ZK. If the threshold is reached, the proposal is defeated unless the Token Assembly subsequently approves an override through the process described below.
The veto threshold will be set at a fixed threshold of 630 million ZK.
The veto vote will remain open for seven days. Once the veto votes reach 315 million ZK—50% of the veto threshold—the voting period will be extended by two days.
3. Token Assembly Supermajority Vote
A veto may be overridden by a Token Assembly supermajority:
- at least 1.26 billion ZK voting For, equal to twice the 630 million ZK veto threshold; and
- more For votes than Against votes.
The Supermajority Governor [ZKsync Supermajority Governor] will use the existing ZK token and the same fractional-counting model as the current Protocol Governor. It will have a proposal threshold of 21 million ZK, a one-day voting delay, a seven-day voting period, and a three-day late-quorum extension.
Successful supermajority proposals will execute through a dedicated self-administered TimelockController with a one-day minimum delay. That timelock will hold the Veto Governor’s vetoOverrideRole. No externally owned account, Security Council Safe, Foundation Safe, or general governance administrator will hold the supermajority role.
The supermajority vote must execute within 14 days after the veto deadline. This window accommodates the override vote, possible late-quorum extension, and supermajority-timelock delay.
Under the proposed implementation, the supermajority may apply to any proposal in the Defeated state, including a proposal stopped through the Foundation’s safety veto. This prevents the Foundation from becoming a unilateral denial-of-service point, but means its veto acts as a delay rather than an absolute stop when at least 1.26 billion ZK supports a proposal proceeding.
Following a successful supermajority vote, anyone may queue the proposal on the Veto Governor and, after the applicable timelock conditions are satisfied, execute it through the Council Governor. The existing L1 approval process still applies.
4. Foundation safety veto
The ZKsync Foundation will retain veto power in the Veto Governor’s vetoGuardian role via its L2 multisig, 0xF197677d63BF6E2841F5108b8dFd2FD6eCEff74B.
The Foundation may stop a proposal while it is Pending or Active by calling vetoByGuardian() on ZKsync Era. The Foundation cannot use this role to originate, affirmatively approve, queue, or execute a proposal.
A Foundation-vetoed proposal may be restored through the 1.26 billion ZK Token Assembly override described above.
5. Standard ZIP process
The standard process will be:
- One Security Council member submits a ZIP through the Council Governor.
- The proposing Security Council member, or any other council member, casts one FOR vote to advance the proposal to the Token Assembly veto stage.
- The proposal enters the Token Assembly veto process.
- The Foundation may exercise its safety veto while the proposal is Pending or Active.
- If no veto occurs, the proposal succeeds at the end of the veto period.
- If a veto occurs, the proposal proceeds only if the Token Assembly approves an override with at least 1.26 billion ZK voting For and more For votes than Against votes.
- The Veto Governor queues and executes the proposal through the existing Protocol Timelock.
- The Protocol Timelock sends the L2-to-L1 message to the
ProtocolUpgradeHandler. - The upgrade proceeds through the existing L1 approval, delay, and execution stages.
Every standard ZIP is subject to the Token Assembly veto process. Only a higher-threshold Token Assembly vote may reverse a veto on L2.
6. Council Governor parameters
| Parameter | Initial Value |
|---|---|
| Name | ZKsync Protocol Upgrade Council |
| Council Veto Governor | Deployed Veto Governor |
| Governor admin | 0xf41eca3047b37dc7d88849de4a4dc07937ad6bc4 |
| Voting delay | 86,400 seconds (1 day) |
| Voting period | 259,200 seconds (3 days) |
| Proposal threshold | 1e18 (one seat) |
| Quorum fraction | 12% (one of eight seats) |
| Super-quorum fraction | 12% (one of eight seats) |
| Vote-success rule | One FOR vote is enough |
7. Veto Governor parameters
| Parameter | Initial Value |
|---|---|
| Name | ZKsync Protocol Upgrade Veto Governor |
| Token | ZK at 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E |
| Voting delay | 86,400 seconds (1 day) |
| Voting period | 604,800 seconds (7 days) |
| Proposal threshold | 0 (propose() is restricted to the Council Governor) |
| Veto Guardian | 0xF197677d63BF6E2841F5108b8dFd2FD6eCEff74B |
| Veto override duration | 1,209,600 seconds (14 days) |
| Voting-period extension | 172,800 seconds (2 days) |
| Extension threshold | 50% of veto threshold (315 million ZK) |
| Veto threshold | 630 million ZK |
| Protocol Timelock | 0x085b8B6407f150D62adB1EF926F7f304600ec714 |
| Governor admin | 0xf41eca3047b37dc7d88849de4a4dc07937ad6bc4 |
| Council | Deployed Council Governor |
| Veto override role | Deployed Override timelock |
8. Council token parameters
| Parameter | Initial Value |
|---|---|
| Name | ZKsync Protocol Upgrade Council Seat |
| Symbol | ZKPUC |
| Admin | 0xf41eca3047b37dc7d88849de4a4dc07937ad6bc4 |
| Maximum tokens per member | 1e18 |
| Initial members | Matter Labs: 0xe38dc029623f0af56BdC46E5318610E257d6b760; Nethermind: 0x870Ec9631E28ee6C8b304e238E9b6890a99ab8aA; Open Zeppelin: 0x305798C076B64Be35Aa6367C6632b79e29D0113A; Spearbit: 0x356cF4Ac9fA86F0a9dDdc62e48082FE5Cd14bE7b; Chainlight: 0x3043bF9c9A512d20Dda2c2b2C3D69AF6f7Fcd5B1; Cyfrin: 0x9BC8d216d63b38c390e465D664FEb63B67659c13; Dedaub: 0xdbc2E250cBA867D6619Bed342Ca3Eca7b71e8b82; Peckshield: 0x46fc9a8A72456c84F42c5c9e5df46984c0078B15 |
| Tokens per initial member | 1e18 |
| Transferability | Non-transferable and non-delegable |
9. Supermajority Governor parameters
| Parameter | Initial Value |
|---|---|
| Name | ZKsync Supermajority Governor |
| Token | ZK at 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E |
| Proposal threshold | 21 million ZK |
| Fixed For-vote quorum | 1.26 billion ZK |
| Success condition | At least 1.26 billion ZK FOR and more FOR than AGAINST |
| Voting delay | 86,400 seconds (1 day) |
| Voting period | 604,800 seconds (7 days) |
| Late-quorum extension | 259,200 seconds (3 days) |
| Override timelock minimum delay | 86,400 seconds (1 day) |
| Override timelock proposer and canceller | Veto Override Governor |
| Override timelock executor | Open (address(0)) |
| Override timelock administration | Self-administered |
10. Existing Protocol Timelock migration
This design requires no changes to the existing ProtocolUpgradeHandler and continues to use the existing Protocol Timelock at 0x085b8B6407f150D62adB1EF926F7f304600ec714.
The migration will:
- grant
PROPOSER_ROLE,EXECUTOR_ROLE, andCANCELLER_ROLEon the Protocol Timelock to the new Veto Governor; and - revoke those roles from the current
ZkProtocolGovernorat0x76705327e682f2d96943280d99464ab61219e34f.
The Veto Governor requires EXECUTOR_ROLE because it calls executeBatch() itself. The Protocol Timelock is self-administered and currently has a minimum delay of zero. This ZIP does not change that delay.
11. Administration and council membership
The governorAdmin roles for the Council Governor and Veto Governor, as well as the CouncilERC20 admin role, will be assigned to the L2 alias of the ProtocolUpgradeHandler, 0xf41eca3047b37dc7d88849de4a4dc07937ad6bc4.
As a result, parameter changes and council seat changes must pass through the full ZIP process, including the L1 approval and delay stages, before the ProtocolUpgradeHandler sends the corresponding L1-to-L2 call.
The L1 Security Council membership and the L2 council-seat list are separate. A change to one does not automatically update the other. Any membership change must update both systems where applicable.
12. Prerequisite Guardian-dissolution ZIP
This proposal assumes that a separate ZIP has already:
- assigned the ZKsync Foundation Safe to the
ProtocolUpgradeHandlerGuardian role; - deployed and activated an Emergency Upgrade Board that is composed of the Security Council plus Foundation, requiring both bodies; and
- retired the prior three-body Emergency Upgrade Board.
That prerequisite ZIP must execute before this optimistic-governance migration. Any corresponding changes to Guardian roles in the Token Governor and GovOps Governor must be handled separately through the applicable TPP and GAP processes.
13. Scope
This proposal applies only to the Protocol Upgrade Governor and its timelock. It does not change:
- the Token Governor or the affirmative Token Assembly vote required for TPPs;
- the GovOps Governor or the affirmative Token Assembly vote required for GAPs;
- the L1
ProtocolUpgradeHandlerapproval thresholds established by the prerequisite ZIP; - the Security Council’s existing freeze powers; or
- the Emergency Upgrade Board established by the prerequisite ZIP.
Execution Impact
Security Council
Each Security Council member entity will receive one seat held through its Safe on ZKsync Era. Any one member may sponsor a proposal and forward it to the Token Assembly veto stage. The Security Council will continue to act collectively during the L1 approval stage.
L2 seat custody is operationally separate from the existing L1 Security Council membership. The signer sets and membership records must be kept aligned.
Token Assembly
The Token Assembly will no longer need to reach affirmative quorum for every ZIP. Instead, every standard ZIP will enter a public veto period.
Delegates may stop a proposal with 630 million ZK in veto votes. A disputed veto may be reversed only through a separate Token Assembly vote with at least 1.26 billion ZK voting For and more For votes than Against votes.
This proposal does not change Token Assembly approval rights for TPPs or GAPs.
ZKsync Foundation
The Foundation may veto Pending or Active proposals through an L1-to-L2 transaction. Under the proposed implementation, the Token Assembly may reverse that veto through the same 1.26 billion ZK override process.
The Foundation retains the L1 fallback approval and legal-veto-extension functions established by the prerequisite Guardian-dissolution ZIP.
Governance interfaces and monitoring
The governance interface must support council proposal, council sponsorship, Token Assembly veto, veto extension, override proposal, override execution, Protocol Timelock, and L1 approval states.
All council proposals and vetoes should trigger public notifications to delegates, Security Council members, the Foundation, and the wider community. Interfaces should display the 630 million ZK veto threshold, the 315 million ZK extension threshold, the 1.26 billion ZK override requirement, and the applicable deadlines.
Governance Procedures
The ZKsync Governance Procedures must be amended to reflect Security Council proposal rights, the Token Assembly veto and override processes, the Foundation safety veto, and the revised role of the current Protocol Timelock and Protocol Governor.
Backwards Compatibility
This proposal changes the governance process for future ZIPs and is therefore not procedurally backwards compatible with the current affirmative-vote model.
After activation:
- ZIPs must be originated through the Council Governor;
- delegated ZK voting power will ordinarily be used to veto rather than affirmatively approve ZIPs;
- a separate higher-threshold Token Assembly process will govern veto overrides;
- the new Veto Governor will replace the current Protocol Governor as proposer, executor, and canceller on the existing Protocol Timelock; and
- governance interfaces and indexing services must support the council-to-veto and override lifecycles.
The proposal does not change application-facing transaction formats, smart contract interfaces, or validity rules for ordinary ZKsync transactions. The Token Governor and GovOps Governor proposal processes remain unchanged.
Any ZIP pending in the current Protocol Governor at the activation boundary must be handled under a published transition plan. No proposal should remain dependent on roles that are revoked during migration.
Security Considerations
The optimistic model allows a proposal to advance without affirmative Token Assembly participation. This improves liveness but makes public notice, monitoring, accessible technical materials, and a meaningful veto period essential. The seven-day veto period, late-veto extension, Foundation veto, Token Assembly override process, collective Security Council L1 approval, and existing L1 delays provide defense in depth.
The 1.26 billion ZK override protects against veto griefing and a unilateral Foundation denial of service, but it also means that a veto is not absolute. The override remains a Token Assembly decision: neither the Security Council, the Foundation, nor the administrator can invoke it without the required token vote. The feasibility of reaching 1.26 billion ZK in For votes should be assessed against historical participation before deployment.
As proposed, the override can reverse both a token-holder veto and a Foundation safety veto because both place the proposal in the Defeated state. Restricting the override to token-holder vetoes would require additional state tracking and a further modification to the audited code. The final implementation and documentation must make the selected behavior explicit.
If the Security Council cannot satisfy the L1 approval threshold, the Foundation may use the fallback approval path established by the prerequisite ZIP. If both bodies refuse or are unavailable, the upgrade will not execute. This is the intended two-body blocking property of the design.
The governorAdmin and council-token admin may change parameters and membership. Assigning these roles to the aliased ProtocolUpgradeHandler subjects their use to the full ZIP and L1 approval path, but also makes correct L1-to-L2 aliasing and cross-domain execution critical. All aliases and administrative calls must be tested on a fork.
The existing Protocol Timelock is retained because the ProtocolUpgradeHandler accepts messages only from that address. Incorrectly revoking the current governor’s roles before the Veto Governor is fully configured could make protocol governance inoperable. The role migration must be atomic where possible and verified against the final execution manifest.
The generic council-governance contracts were reviewed by Certora in December 2025 at commit 6680eb4, according to the supporting technical materials. The ZKsync-specific council counting, fixed veto-supply base, deployment parameters, override-governor integration, L1-to-L2 administration, and complete role migration require their own review before submission.