| ZKsync Security Council Report | |
|---|---|
| Reporting Period | August 2024 – September 2025 |
| Prepared For | ZKsync Token Assembly |
| Prepared By | ZKsync Security Council |
| Date | October 2025 |
1. Executive Summary
The ZKsync Security Council (ZKSC) was created in August 2024. The first year of the ZKSC marked a critical phase in establishing operational maturity, procedural clarity, and community trust in the security model of the ZKsync governance system.
With support from the ZKsync Association, the ZKSC has evolved over the past 14 months to the position it is in today, ready to enter a second year of operations as an independent governance body within the ZKsync governance system.
Over the reporting period, the ZKSC successfully executed emergency upgrades, coordinated protocol upgrade approvals for ZIPs during the Risk Review Period, managed multisig transfers, and monitored token minting operations — all while operating under the oversight of the Token Assembly.
The ZKSC’s mandate has been to protect the ZKsync protocol and governance system. This report provides a comprehensive review of the actions, decisions, and structure of the ZKSC from creation in August 2024 through September 2025, and concludes with forward-looking recommendations to strengthen the system in the year ahead.
2. Mandate and Composition
The ZKsync Security Council is a 12-member governance body responsible for:
- Initiating and executing authorized emergency upgrades, in conjunction with Guardians and the ZKsync Foundation.
- Initiating and executing a freeze on the ZKsync protocol.
- Approving governance upgrades prior to execution.
- Serving as signers for Token Program Proposal (TPP) capped minters approved by the Token Assembly.
Membership
The Council’s inaugural term began in August 2024 with the following composition:
- 12 Members: a mix of four individuals and eight entities representing technical security experts, auditors, and governance contributors from the Ethereum community.
- For the first year of operations, from August 2024 - August 2025, there were three tiers of response time:
- 4 entities were on a 15 min response time; and
- 4 entities were on a 1 hour response time; and
- 4 individuals were on a 9 hour response time.
- With the passing of TPP-6 to fund the ZKSC for 12 months from August 2025, a new model for compensation and response time was put in place:
- 8 entities are on a 1 hour response time; and
- 4 individuals are on a 9 hour response time.
A full list of signers and entity details is maintained in Schedule 3 of the ZKsync Governance Procedures.
3. ZKsync Governance Participation
ZIP Approvals
Between August 2024 and September 2025, the ZKSC reviewed thirteen ZKsync Improvement Proposals (ZIPs). Eleven were approved and executed; two were withheld after issues were identified during the Risk Review Period, then resubmitted and successfully executed as new ZIPs.
Each ZIP underwent a standard governance flow:
- Risk Review Period (24–72 hours) initiated by the ZKsync Foundation and the Technical Committee.
- Review and verification by the ZKSC using the GovAuth interface and independent tooling.
- Approval through Council multisig within a 72-hour signing window.
- Deployment by the protocol upgrade executor.
In practice, all ZIP approvals met the defined service-level expectations for responsiveness. The Council maintained quorum and timeliness across all cycles, averaging under 36 hours per approval window.
Beyond signing, members independently verified onchain bytecode and upgrade integrity before approval, helping to establish best practices for protocol upgrade verification across the ecosystem.
Total number of upgrades approved by the ZKSC: 11
Total number of upgrades that progressed to execution: 9 (ZIPs 1 and 2 were resubmitted as ZIPs 3 and 4 respectively)
TPP Pauser Role
The ZKSC also holds the Pauser role for all Token Program Proposals (TPPs) approved by the Token Assembly, currently valued at over 100m ZK. This role grants the ZKSC authority to immediately halt token minting or disbursement under any active TPP in the event of an anomaly, exploit, or procedural breach.
By design, this safeguard ensures that millions of dollars in ZK allocations managed through capped minters remain secure even if an operational or contract-level issue arises.
The Pauser function has become a central part of ZKsync’s layered governance defense model, allowing the ZKSC to act swiftly to contain potential risks while maintaining oversight accountability to the Token Assembly.
4. Monitoring, Infrastructure, and Tooling
GovAuth Interface
Moonsong Labs built the GovAuth Interface, designed to facilitate coordination among governance bodies and enhance the verification process for protocol upgrades. The GovAuth app is the primary interface that the ZKSC uses in order to approve standard protocol upgrades (ZIPs) and Emergency Upgrades. Details about the creation of the GovAuth app are shared in this blog post by Moonsong Labs.
The GovAuth app worked successfully for every instance of an upgrade where it was required. Areas for improvement related to the dependence on centralized infrastructure (as is the case with all websites) and frequent connectivity issues when collecting signatures.
ZKsync Verification Tool
Through the process of reviewing protocol upgrades, members of the ZKSC proactively developed tooling and processes to verify protocol upgrades.
A notable example of such tooling is Cyfrin’s ZKsync Security Council verification tool.
Watch the walkthrough video on Youtube.
Hypernative Monitoring
Following the April 2025 exploit involving the unauthorized minting of unclaimed ZK airdrop tokens, the ZKSC implemented Hypernative as its dedicated monitoring platform. Matter Labs continues to rely on OpenZeppelin Defender for its internal systems, so introducing Hypernative provides architectural diversity across the broader ZKsync ecosystem. This reduces correlated risk from any single monitoring provider and ensures independent observability of critical onchain activity.
Hypernative offers continuous, AI-assisted surveillance of ZKsync Era, with native L2 integrations that enable the ZKSC to track token minting, upgrade executions, and contract-level configuration changes in real time. All monitored addresses and rules are maintained through a shared on-chain monitoring repository, ensuring data consistency and auditability.
Alerts are delivered to a dedicated Telegram channel continuously monitored by the ZKSC, allowing near-instant awareness of relevant transactions, including ZK token minting events, and rapid escalation in the event of anomalies. This implementation materially improves the independence, coverage, and responsiveness of the governance security framework.
5. Emergency Response
Emergency Upgrades
The ZKSC was activated four times in emergency conditions, three of which required direct execution of Emergency Upgrades. One additional planned exercise in March 2025 validated the system’s ability to handle critical interventions safely.
- March 2025: Planned emergency upgrade (ZIP-5). Successfully executed as a controlled test of emergency infrastructure. Forum link
- May 2025: Emergency Upgrade to resolve an unprovable batch on Abstract. Forum link
- May 2025: ZKsync X account compromise. No onchain action required; coordinated response and communication with the account owner.
- August 2025: Emergency Upgrade to patch a ZK circuits bug. Forum link
In all incidents, the ZKSC demonstrated swift coordination and adherence to predefined emergency procedures.
Exploit Recovery
In April 2025, a compromised admin account minted the remaining unclaimed tokens from the ZK token Merkle distributors used for the June 2024 airdrop, seizing 111,881,122 ZK tokens (~$5M).
The ZKSC issued a Safe Harbor offer leading to full recovery of the funds. The recovered tokens were converted back to ZK via GAP-3 and returned to the Token Governor Timelock. The Token Assembly sustained no losses.
A full post-mortem is available here.
6. Budget and Expenditure
From its creation until April 2025, the ZKSC was funded by a grant from the ZKsync Foundation. Governance-approved funding was pursued to cover operational expenses for the period from 1 May 2025.
| Date Executed | Funding Source | Funding Coverage | ZK Requested | USD Equivalent (0.04) | ZK Minted | Capped Minter Status |
|---|---|---|---|---|---|---|
| July | TPP-5 ZKSC Bridge Funding | 3 months | 10.87M ZK | $434,800 | 8,340,029 (77%) | Expired |
| August | TPP-6 ZKSC v2.0 Funding | 12 months | 27.7M ZK | $1,108,000 | 3,900,500 to date (14%) | Active |
Expenditure Breakdown
| Category | Allocation | Description |
|---|---|---|
| Signer Compensation | 80% | Currently 12 signers at $5k–$8k/mo equivalent |
| Entity Administration | 10% | Legal structure for contracting and compliance |
| Operational Costs | 5% | Tooling and emergency notification system |
| Reporting & Monitoring | 5% | Protocol and governance monitoring |
7. Learnings and Recommendations
The first year of ZKSC operations established a strong foundation for secure and transparent governance execution. Looking ahead, the focus shifts toward strengthening tooling resilience, cross-chain coordination, and operational readiness. The following priorities outline key areas for continued improvement in Year Two.
1. Tooling and Interface Improvements
The ZKSC’s experience using the GovAuth interface confirmed its effectiveness in coordinating multisig approvals and tracking protocol upgrades, but also highlighted limitations common to all web-based tools. Dependence on a single hosted front-end created occasional friction and introduced unnecessary reliance on centralized infrastructure.
To improve robustness, the ZKSC recommends expanding available signing pathways, such as CLI-based approval, to ensure continuity of operations even if web interfaces are temporarily unavailable. These additional pathways would also improve security for signers and enable more flexible response workflows during emergencies.
The ZKSC currently uses OpsGenie for emergency notifications.Atlassian has announced the deprecation of OpsGenie, so the ZKSC will migrate to an alternate notification system in the coming months.
2. Governance Transparency and L1/L2 Notification
Governance tracking currently spans multiple steps—vote delay, voting period, time lock, L2 execution, Guardian veto period, Risk Review Period, L1 time lock, and finally execution on L1. Bringing visibility to the entire ZIP process would be beneficial for both ZKSC signers and Delegates/community observers.
The ZKSC recommends the development of a unified event and notification system that surfaces upgrade progress from initiation on L2 through to final execution on L1. This would provide a clear, verifiable record of every stage in the governance lifecycle and make the execution of ZIPs easier to audit, monitor, and communicate.
3. ZKsync Chain Upgrade Support
As more ZKsync-based chains deploy using the ZK Stack, support and coordination for downstream upgrades becomes critical. Once an upgrade is executed on L1, ZK Chains must replicate those changes safely and consistently.
The ZKSC recommends building shared resources and procedures to assist ZK chains in performing these post-upgrade integrations. This may include documentation templates, versioning standards, recommended testing practices, and a coordination channel for participating operators. Over time, this could evolve into a standardized “ZKsync Chain Upgrade Framework,” enabling the ecosystem to scale protocol governance while maintaining technical coherence across deployments.
4. Responsiveness and Testing
While the ZKSC demonstrated consistent responsiveness during live incidents, maintaining that standard requires continuous validation. The ZKSC plans to introduce “war game” exercises to simulate emergency conditions, including signer unavailability, delayed notifications, or interface downtime. These drills will help refine escalation procedures and test redundancy in tooling and communication.
Additionally, the ZKSC may benefit from quarterly liveness tests. These liveness tests could be simple, non-disruptive signing simulations that confirm readiness across all tiers of response times. These operational checks will help ensure the ZKSC remains responsive, auditable, and capable of swift, coordinated action in any scenario.
8. Appendix
- Schedule 3 – ZKsync Security Council (Governance Procedures)
- ZKsync Era Safe Multisig Address:
zksync:0xB5edBf47fC5eF24a7b7FE1F31f24fD2768Ea2C67