This proposal requests 10.87m ZK tokens to fund the operations of the ZKsync Security Council for June and July, prior to a revised Security Council funding request being put forward in August.
Proposal Author
ZKsync Security Council
Proposal Sponsor
TBC
Date Created
June 2025
Version
v1.0
Summary of Action
Approve minting rights for 10.87m ZK via a capped minter for the ZKsync Security Council, to cover operational costs for two months.
Link to proposal discussion
TBC
Abstract
This Token Program Proposal (TPP) requests 10.87m ZK tokens to fund the ZKsync Security Council (ZKSC) for two months, supporting its mandate to safeguard the protocol through both emergency and governance actions. During this two month period, the ZKSC will iterate on the existing Security Council parameters, to refine the model ahead of a longer-term funding request in August 2025. A single capped minter will facilitate disbursement, subject to cancellation by the Token Assembly. Accountability will be maintained via a public report at the end of the funding period.
Motivation
The ZKsync Security Council plays a foundational role in maintaining protocol security, continuity, and governance execution. From managing emergency upgrades to approving ZIPs (protocol upgrades) during the Risk Review Period, its responsibilities require high availability, deep technical expertise, and operational rigor.
Funding for the first 12-24 months of the ZKSC was bootstrapped by the ZKsync Foundation. As a result of the volatility of the token price, the ZKSC has exhausted all funds and is requesting ZK tokens to provide bridge funding in order to maintain operational responsiveness while the next iteration of the ZKSC is finalised.
Specification
The request for 10,866,500 ZK tokens is detailed below. Calculations are made with a token price of $0.040 to account for token volatility.
The capped minter will authorize up to 10.87M ZK tokens (10,866,500 ZK)
Any tokens that are not distributed by September 30th will be un-minted and returned to the ZK supply.
Minting is cancellable by the Token Assembly at any time prior to execution
Accountability
Annual Reports: The ZKSC will publish a report by 30th September annually, or otherwise required by any future governance guidance. The report will summarize:
Emergency freeze activity
Governance approvals and delays
SLA performance per member
Membership changes or recommendations
Governance Oversight: The Token Assembly may cancel the capped minter prior to execution. If there is a TPP submitted onchain, the ZKSC will refrain from minting tokens until the related cancellation vote has ended.
Participants
ZKsync Security Council: Administers funding and contracts for Security Council Members
Security Council Members: Technical operators responsible for onchain security actions and governance approvals
Token Assembly: Oversees minting and retains final authority to halt funding
This is a solid step forward in strengthening the zkSync ecosystem’s long-term security and decentralization. Establishing a well-funded Security Council with clear mandates is crucial — especially as we move toward greater community governance.
Appreciate the transparency and the thoughtful structure behind this proposal. Looking forward to seeing this implemented and watching the Council play a key role in safeguarding the protocol.
The Security Council’s role is critical for protocol health and cannot be delayed without significant risk.
The proposal includes appropriate accountability measures, such as public reporting requirements, Token Assembly oversight, and time-limited minting authority. It is a prudent interim measure while a more comprehensive long-term solution is developed.
Alisha talked about the proposal and also the importance of the ZKsync Security Council on our latest Twitter (X) Space last week! She also explained how the community can check the transparency of the ZKsync Security Council and how the will use the funds received if the proposal is approved.
We appreciate the proposal breakdown and follow up discussion regarding the overall scope of the Token Assembly regarding voting this proposal. We expect that responsability to be further clarified as per commented.
Although we definitely consider that Security Council should be compensated for their work and an extension is reasonable, we do have some questions regarding the compensation amount.
Perhaps some clarification on the scope or caveats for this 2-month extension could shed some light on why compensations rise well above the benchmark and, as mentioned, should go significantly down in the follow-up proposal for the next 12 months.
For additional context and notes, please find links to the call notes & recordings from the last two Proposal Review Calls that discuss this proposal below:
The compensation of Security Council Members is dictated by their Emergency Response time. There are three tiers of response time currently — 15 minutes, 1 hour, and 9 hours. A majority (60%) of the monthly expense for Security Council signers is related to the 15 min response tier.
As you can imagine, in order for entities to remain responsive within 15 mins 24 hours a day, 365 days a year, there is a meaningful amount of human resourcing that needs to be dedicated to monitoring. In addition, those “on-call” need to have a level of experience where they are confident responding to an emergency on the fly. The majority of SC members on the 15 min response tier commit signers who are company Founders or Head of Security.
The reduction in compensation for the SC V2 is driven by extending the response time, from 15-mins to a number yet to be confirmed (but likely to be greater than 4 hours). This doesn’t mean that SC members won’t respond within minutes in an emergency, as they have done over the past year. It means that the contractual obligation will not be considered in breach unless there is a failure to meet that response time.
I vote AGAINST.
There haven’t been any proposals over the past two months, meaning the security council has done nothing, yet they want to get paid for doing nothing.
According to my calculations, a security council member’s salary is $25000 per month. That’s a bit too much for this kind of work, especially when there are no proposals throughout the month and there’s nothing to do
Look into how much security council members earn in other protocols. The figures there are several times lower.
who are these security council? They are getting paid more than Nasa astronouts. Vov they have achieved so much in ZK I think. You made ZK top tier project and we are sitting on top of the world so you need to be paid this much? Smells like CORRUPTION to me.
1. Minting based on current token price vs requested price
A clarification was requested related to whether the entire ZK amount will be minted given the token price has increased compared to the value that the request was based on.
A total of $422,000 USD will be minted based the number of tokens required to each month. The amount of ZK distributed to SC members in a given month is based on he 30-day average of ZK for that month. As such, if the average price is 0.05c for June and 0.06c for July, then that is the rate at which tokens will be minted (not at 0.04c).
Only the amount of ZK tokens that meets the USD value of the request, based on the 30-day average of the months in question, will be minted from the capped minter.
2. The role of Security Council beyond governance proposals
A large component of the compensation paid to SC members, particularly those on the 15 min response contract, is related to those signers being available within 15 minutes 365 days a year, irrespective of governance proposals. In the past four months, the Security Council has responded to Emergencies on at least 3 occasions:
May incident which resulted in an Emergency Upgrade;
April incident which resulted in a safe harbour offer and successful recovery of 90% of exploited funds. The outstanding 10% happened to be made up by the increasing price of ETH after an approval for the SC to swap ETH back into ZK. The Token Assembly did not suffer any loss as a result of the incident.
The ZKsync X account was compromised in May, an event to which the SC responded internally as an Emergency. After ensuring that there were no related events onchain, no action was required to be taken by the SC related to that event.
I suspect that you either don’t know everything or are not telling the whole story.
When the April incident happened and 111,881,122 ZK tokens were stolen from the contract, the team only responded the next day even though people on Discord and Twitter started talking about it right when the tokens were stolen. But there was no reaction to their calls. So any claims about a 15-minute response time are simply false - the actual response took around 24 hours.
That’s why I believe the security council is not functioning properly and does not deserve such a high salary.
Zk should be community owned, taking action like that you will lose trust because you pay yourself and doing it super overpriced. at least 3x less should work too.
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.
After reviewing the proposal and discussing it with both the Security Council and the ZK Nation team, we gained a deeper understanding of the nuances involved in the structure of the Security Council and its funding shortfall.
The current setup was designed a long time ago, before the token TGE, and was based on several assumptions that later proved to be inaccurate. Furthermore, for security reasons, the setup was designed in a way that made it very inflexible and hard to modify (which was reasonable). Currently, modifying the existing design is not practical. We can either fund the bridge or not.
With the Security Council being a vital piece of ZKsync, we cannot afford not to have adequate funding in place to ensure the members adhere to their SLAs.
