This proposal requests approval of a capped minter to fund 12 months of ZKsync Security Council operations, up to a maximum of $1.108 million USD.
Proposal Author
ZKsync Security Council
Proposal Sponsor
TBC
Date Created
July 2025
Version
v1.0
Summary of Action
Approve a capped minter of up to 27.7 million ZK ($1,108,000 USD at $0.04 per ZK) to fund the next 12 months of Security Council operations.
Link to proposal discussion
TBC
Abstract
This Token Program Proposal (TPP) seeks approval for the restructured version of the ZKsync Security Council (ZKSC) to be funded for 12 months from 1 August 2025. The amount required is $1,108,000 USD, requested in the form of a capped minter with 27,700,000 ZK at a $0.04 token price.
Motivation
The first version of the ZKsync Security Council was deployed based on assumptions made prior to the launch of the ZK token. With 12 months of real-world data on token price, TVL, and operating costs, it is necessary to evolve the model into something leaner and more aligned with current protocol scale.
There are two core responsibilities carried out by the ZKsync Security Council:
Approve protocol upgrades (ZIPs) in the Risk Review period, which involves a thorough verification of all ZIP specifications; and
Respond in a timely manner to Emergency Scenarios that may require a (1) Soft Freeze, (2) Hard Freeze, or (3) Emergency Upgrade.
Specification
USD-Denominated Request
This ZKsync Security Council requests $1,108,000 USD to cover 12 months of operations from 1 August 2025.
ZK Capped Minter
This amount is requested via a capped minter with a ceiling of 27,700,000 ZK, which corresponds to a token price of $0.04 per ZK. The full cap will only be required if the token remains at or below this level.
ZK Price Increase Protection
This request is denominated in USD, not ZK. If the ZK token price exceeds $0.04 during disbursement, fewer tokens will be minted. The capped minter is intended to deliver a maximum of $1.108M USD in value, not a fixed quantity of ZK.
Security Council Structure (2025–2026)
12 Members Total
4 Individuals with a 9-hour SLA
8 Entities with a 6-hour SLA
Standard Operating Procedures (SOP)
The ZKSC will publish SOP to the Governance Forum prior to the end of the voting period of this proposal. The SOP will outline the day-to-day expectations of the ZKSC related to responsiveness in both emergency scenarios and for protocol upgrades approved by the Token Assembly.
An example of the content to be included is “emergency response times”. All members will be expected to respond to an emergency scenario within 60 minutes if online and/or available. This should provide the Token Assembly with some comfort that ZKSC members will endeavour to be responsive in emergencies irrespective of the timing prescribed in their SLA, which should be treated as the absolute maximum amount of time required for a response.
Funding Breakdown (USD-denominated; Max ZK @ $0.04)
Category
Count
Monthly Rate (USD)
Annual Total (USD)
Max ZK @ $0.04
Individual Signers
4
$5,000
$240,000
6,000,000 ZK
Entity Signers
8
$8,000
$768,000
19,200,000 ZK
Total Signer Compensation
$1,008,000
25,200,000 ZK
Legal & Operational Costs
—
—
$100,000
2,500,000 ZK
Total Request (Capped)
$1,108,000
27,700,000 ZK
Rationale
This proposal:
Brings total annual cost down by over 53% vs v1 which had an annual cost of approximately $2.4m USD.
Introduces longer SLAs (6h/9h) to reduce operational burden
Aligns cost with protocol-market-fit, while retaining rapid-response capability
Avoids over-minting by tying funding to real-time ZK/USD pricing
Provides price flexibility by capping token output at $0.04 equivalence
Accountability
Bi-annual public reporting on:
Emergency upgrade activity
Governance activity
SLA responsiveness
Budget utilization
Funding disbursed via capped minter will be able to be canceled by the Token Assembly
Any excess tokens will be returned to the Token Assembly
Looks like a solid step toward leaner, more accountable protocol security. Tying the minter to real-time ZK price helps avoid unnecessary dilution, and the cost reduction vs v1 is a strong signal of operational maturity. Curious to see how the new SLA structure performs in practice
Thank you for the proposal, that said, we would like to clarify on what will happen if the Service Level Agreements (SLAs) are not met, what will the consequences be?
The following reflects the views of L2BEAT’s governance team, composed of @kaereste, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We are voting FOR the proposal.
We recently stressed the importance of the Security Council. This group is the last line of defence for upgrades and emergencies; keeping it well funded and motivated is non-negotiable. Version 2 does that at half the price of last year and ties every minted token to a live USD cap, so inflation risk stays low.
I just have one question with regards to this point. Obviously longer SLAs reduce operational burden - but when it comes to security and potential actions shorter time frames are likely necessary and that’s even stated in the proposal (“60min reaction is expected”).
Why are there longer SLAs in the TPP? Or in other words: Why a hard longer SLA with a soft “but we expect” that we can’t enforce I guess?
What specific safeguards are in place to ensure no single Security Council member (or small group) can abuse their position, and how are they vetted/rotated to prevent insider threats?
Why are we budgeting over $1M/year in compensation for a role that may rarely be activated, and has no clear performance metrics? Could this be reduced, or made variable based on actual actions taken?