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 vulnerability resolutions 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. However, 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 Emergency Upgrade Board. An Instant Upgrade is not voted on by the Token Assembly.

The governance process itself is unchanged. Only the terminology, classification, and disclosure requirements used to communicate the upgrade are updated.

Every Instant Upgrade shall be classified as one of the following:

• Category 1: Security Patch
• Category 2: Emergency Response

The classification shall be determined based on the circumstances known at the time the upgrade is approved.

If material new information changes the basis on which an upgrade was classified, the relevant public communications shall be updated and, where appropriate, the upgrade shall be reclassified.

Disclosure Framework

Each Instant Upgrade shall be disclosed through two publications:

1. a Notice, published as soon as reasonably practicable following execution of the upgrade, containing the information then available about the upgrade and its practical impact; and
2. a Report, published when sufficient relevant information is available and the Security Council determines that its disclosure no longer creates a material security risk.

For a Category 1 upgrade, the Report shall be titled Security Patch Report. For a Category 2 upgrade, the Report shall be titled Incident Report.

This process ensures that stakeholders receive timely operational information through the Notice and a fuller account through the Report, while allowing sensitive information to be withheld until it can be disclosed safely.

Notice

The Notice shall be published on the ZK Nation documentation website and identify the applicable classification.

The scope and content of the Notice shall be determined by the Security Council in light of the circumstances, the information then available, and any applicable security considerations. The Notice may address, as applicable:

• the reason the Instant Upgrade mechanism was used and whether the underlying issue has been remediated or remains under investigation;
• whether there is evidence of active exploitation;
• whether user funds are believed to be at risk;
• any effect on transactions, deposits, withdrawals, finalization, or other protocol operations; and
• any action required by users or ecosystem participants and the expected timing of the Report, if known.

Information that has not yet been established may be identified as “under assessment”. Information that cannot safely be published may be identified as “temporarily withheld for security reasons”.

Report

The scope and content of the Report shall be determined by the Security Council in light of the circumstances, the information available at the time, and any applicable security considerations. Subject to responsible disclosure and any continuing security constraints, the Report may address the following, as applicable:

• a summary of the vulnerability or security event, including how it was identified and its underlying cause;
• a timeline of material events and response actions;
• the affected protocol components and networks, including any actual or potential impact and whether exploitation occurred;
• the remediation implemented through the Instant Upgrade, the applicable approval process, and any additional mitigation or monitoring measures; and
• relevant lessons, further actions, or preventative improvements.

Technical details may be temporarily withheld where the Security Council determines that publication would create a material security risk, including where similar vulnerabilities may remain exploitable in other protocol components or systems.

Information withheld on this basis should be disclosed once the Security Council determines that publication no longer creates a material security risk.

If the Report cannot yet be published safely, a status update may state that publication remains deferred for security reasons.

Category 1: Security Patch

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.

Category 2: Emergency Response

An Instant Upgrade responding to an active security event.

Typical use cases include:

• active exploits;
• critical protocol failures; and
• ongoing attacks requiring immediate intervention.

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 that process would expose the protocol to an unacceptable level of risk.

The existing governance framework remains unchanged.

Implementation

If approved, this terminology, classification, and disclosure framework 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;
• incorporate the “Security Patch” and “Emergency Response” classification framework; and
• publish a Notice and Report for each Instant Upgrade.