| Name | Description |
|---|---|
| Proposal Title | Update “Emergency Upgrade” Terminology and Classification |
| One Sentence Summary | This proposal updates the terminology and classification of protocol upgrades currently communicated as Emergency Upgrades. |
| Proposal Author | ZKsync Security Council |
| Proposal Sponsor | TBC |
| Date Created | 12 August 2026 |
| Version | 1.0 |
| Summary of Action | Rename “Emergency Upgrade” to “Instant Upgrade” and introduce two-tier classification (Category 1) Security Patch and (Category 2) Emergency Response. |
| Link to contracts | Not Applicable |
Abstract
This proposal updates the terminology and classification of protocol upgrades currently communicated as Emergency Upgrades. It renames Emergency Upgrades to Instant Upgrades and introduces a two-category classification framework comprising Category 1: Security Patch and Category 2: Emergency Response. The objective is to distinguish preventative security updates from active security incidents while preserving the existing governance process, authorities and security controls.
Motivation
The software security landscape has evolved rapidly in 2026.
AI-assisted security research is fundamentally changing how software is secured across critical infrastructure, open-source software and blockchain protocols. Rather than waiting for vulnerabilities to be reported or exploited, engineering teams are increasingly identifying and remediating security issues proactively as part of normal software maintenance.
This shift is already being reflected across the industry. OpenZeppelin has described security as evolving from point-in-time reviews towards a continuous security model, while Nethermind has written about how AI is fundamentally reshaping Web3 security by accelerating both vulnerability discovery and defensive response. Both organisations are members of the ZKsync Security Council and bring that evolving perspective to protocol security.
For governance systems, this creates an important distinction.
Many vulnerabilities cannot safely proceed through the standard governance process. Public discussion, voting periods and timelocks can unintentionally disclose the existence of a vulnerability before a fix has been deployed. In other cases, the time required to complete the governance process may itself expose the protocol to an unacceptable level of risk. The emergency upgrade process therefore remains an essential security capability.
Increasingly, emergency upgrades are preventative. They are deployed to remediate vulnerabilities discovered internally or disclosed through bug bounty programs before they are exploited, rather than solely in response to an active security incident.
Today, every upgrade executed by Emergency Signers is communicated under the single term Emergency Upgrade. The term correctly identifies the governance mechanism under which the upgrade is executed, that is, an upgrade approved through the Emergency Upgrade process rather than the standard Token Assembly governance process. Currently, an Emergency Upgrade does not distinguish between a preventative security update, often described as a “patch,” and responding to an active security incident.
For token holders, integrators, exchanges, institutional counterparties and risk teams, an announcement of an Emergency Upgrade provides little indication as to whether the protocol is responding to an ongoing security event or proactively remediating a vulnerability before exploitation occurs.
This proposal separates those two concepts. Instant Upgrade identifies the governance mechanism through which the upgrade is executed, while the accompanying classification communicates the reason the mechanism was invoked. The result is a communication framework that more accurately reflects modern security practice while preserving the existing governance process.
Specification
This proposal replaces the public-facing term Emergency Upgrade with Instant Upgrade.
An Instant Upgrade is defined as any protocol upgrade executed with the approval of the Security Council, Guardians, and the ZKsync Foundation. An Instant Upgrade is not voted on by the Token Assembly. The governance process itself is unchanged. Only the terminology used to communicate the upgrade is updated.
Every Instant Upgrade shall be classified as one of the following.
Category 1: Security Patch
Definition
A preventative or precautionary security update deployed rapidly to remediate a vulnerability before exploitation or public disclosure.
At the time the upgrade is approved, there is no evidence of active exploitation of the vulnerability.
Typical use cases include:
- vulnerability remediation;
- defensive hardening;
- preventative security improvements; and
- operational fixes requiring rapid deployment.
Disclosure
Public communications made on the ZKsync governance forum and ZKnation documentation website shall identify the upgrade as:
Instant Upgrade — Category 1: Security Patch
Where appropriate, communications should state that there is no evidence of active exploitation at the time of deployment.
Technical details may continue to be withheld where responsible disclosure or protocol security requires confidentiality.
Category 2: Emergency Response
Definition
An instant upgrade responding to an active security event.
Typical use cases include:
- active exploits;
- critical protocol failures; and
- ongoing attacks requiring immediate intervention.
Disclosure
Public communications made on the ZKsync governance forum and ZKnation documentation website shall identify the upgrade as:
Instant Upgrade — Category 2: Emergency Response
Communications should indicate that the upgrade responds to an active security event while continuing to follow responsible disclosure practices regarding technical details until disclosure no longer creates additional protocol risk.
Governance
This proposal does not modify:
- the authority of the Emergency Upgrade Board;
- the responsibilities of the Security Council;
- governance approval thresholds;
- upgrade execution procedures; or
- existing protocol security controls.
Instant Upgrades will continue to be used only where following the standard governance process would materially increase protocol risk through the public disclosure of a vulnerability or where the time required to complete the governance process would expose the protocol to an unacceptable level of risk.
The existing governance framework remains unchanged.
Implementation
If approved, this terminology will become the standard for all Instant Upgrades communicated by the Security Council.
Existing governance procedures and relevant entity bylaws should be updated to replace references to Emergency Upgrade with Instant Upgrade, and to incorporate the Category 1 and Category 2 classification framework described in this proposal.