[TPP-19] ZKsync Security Council Funding 2026/2027

Proposal information Details
Title ZKsync Security Council 2026–2027 Funding
Proposal Type TPP
One Sentence Summary This proposal funds ZKsync Security Council operations from 1 August 2026 to 31 July 2027 using ZK already held in the treasury.
Proposal Author ZKsync Security Council
Proposal Sponsor TBC
Date Created August 2026
Version v1.0
Summary of Action Approve the transfer of 59,714,286 ZK ($418k USD at 0.007) to the Security Council multisig for the funding period specified in this proposal from Token Governor Timelock.
Link to Proposal Discussion TBC

Abstract

This Token Program Proposal seeks approval to fund the ZKsync Security Council for 12 months from 1 August 2026 to 31 July 2027 with ZK tokens currently held in the Token Govenor Timelock. A total of 59,714,286 ZK is requested ($418k USD at 0.007) to fund an eight-member Security Council along with the entity’s legal, administrative and operational obligations.

This proposal does not approve a capped minter, confer any minting rights or result in the minting of additional ZK.

Motivation

The ZKsync Security Council provides an independent technical check within the ZKsync governance system.

Its core responsibilities, as set out in the Governance Procedures, are:

  1. Reviewing and approving protocol upgrades during the Risk Review period, including verification of the relevant ZKsync Improvement Proposal specifications; and
  2. Responding to time-sensitive protocol security matters in accordance with the ZKsync Governance Procedures.

The Security Council must maintain the technical capability, secure signing infrastructure, organizational coordination and member availability required to perform these responsibilities. This standing capability must be maintained throughout the funding period, regardless of the number of upgrades or security matters that arise.

ZIP-15, passed in May 2026, established the current eight-member structure and the terms under which its members serve. The Security Council also requires an operating entity through which member agreements, payments, director responsibilities, accounting, compliance and other administrative obligations can be managed.

The proposed funding reflects the Council’s current size and operating requirements. It is intended to preserve the Security Council’s essential functions through a lean and sustainable structure that recognizes current market conditions.

Specification

Funding Parameters

Parameter Value
Annual operating budget $418,000 USD
Funding source ZK already held in the Token Govenor Timelock
Reference price used to calculate the allocation $0.007 per ZK
Allocation 59,714,286 ZK
Token Governor Timelock 0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d
Security Council Multisig 0xB5edBf47fC5eF24a7b7FE1F31f24fD2768Ea2C67

Budget Allocation

Budget component Basis Annual amount
Member fees Eight members at 3k USDC/month, as approved under ZIP-15 $288,000
Director fees Governance and oversight of the operating entity $80,000
Entity fees Legal, accounting, compliance, administration and operations $50,000

Member fees support the protocol review, signing, availability and response responsibilities associated with serving on the Security Council. The remaining costs support the entity required to administer and maintain the Council.

Token Mechanic

No capped minter will be deployed and no minter role will be granted for this proposal.

This proposal approves a direct transfer of ZK already held in the treasury, subject to the funding parameters above.

The allocation was calculated using the stated reference price. The budget and the Security Council’s underlying obligations are denominated in USD, while the realized value of the transferred ZK may change with the market price.

The Security Council may convert the allocated ZK into USDC or another suitable operating asset as reasonably required to meet the obligations approved under this proposal.

Rationale

This proposal continues funding for the Security Council structure approved under ZIP-15. It does not expand the Council’s mandate, membership or existing member terms.

The request is limited to maintaining the Council’s technical review, signing and response capabilities and the entity required to support those functions. It represents a materially lower annual operating budget than the previous funding period and reflects the need for careful management of token resources under current market conditions.

Accountability

The allocation will be transferred to the Security Council multisig.

  • The multisig balance and transaction history will be publicly visible onchain.
  • Any funds remaining at the end of the funding period will be returned to the Token Assembly.

Since this funding covers a full year, could the community receive simple periodic updates on how the budget is being used and what work was completed? A short quarterly summary would make it easier for token holders to follow the Council’s contribution and accountability.

Appreciate the suggestion @Anzus_GemWallet. A report summarising SC actions and budget allocations for the 12 months of funding approved under TPP-6 will be posted in the forum in the coming days.

1 Like

Thanks for confirming. A forum report covering both the Security Council’s work and budget allocations will be very helpful for community transparency. I’ll look forward to reading it.

While I appreciate the intent to keep operations lean, there are critical execution and pricing issues in this proposal that must be resolved:

  1. Arbitrary Reference Price ($0.007 vs $0.009): The proposal calculates the required token amount using a reference price of $0.007, requesting 59.7M ZK. However, ZK was trading around $0.009 when this draft was published. Underpricing the reference token extracts roughly 13M+ extra ZK (~28% excess) from the treasury upfront. Why wasn’t a standard 7-day or 14-day TWAP used at the time of submission?

  2. Execution & Market Impact: Converting a $418k budget worth of ZK into USDC on the open market will create unnecessary spot slippage for holders. The proposal must explicitly state that conversions will use structured OTC or TWAP execution rather than direct market liquidation.

  3. Lump-Sum vs. Streaming: Transferring 12 months worth of tokens all at once directly to a multisig is an outdated practice. This allocation should be disbursed via time-based streaming (e.g., Sablier / LlamaPay) or quarterly tranches.

  4. Itemized Entity Costs: Over $130,000 (31% of the entire budget) is allocated to director and entity administrative fees. A clear, itemized breakdown of these legal, compliance, and director costs should be provided.

  5. Mandatory Quarterly Reporting: The proposal should include an explicit commitment to publish quarterly updates covering token conversion execution, operational expenses, and protocol review activity.

Hi @cobinus, please note the proposal was revised to cover six months. The onchain request is now 32,714,286 ZK ($229,000 USD at 0.007).

  1. The average ZK price during the 30 days before the proposal was posted to the forum was approximately $0.008. The $0.007 reference price provides a 12.5% buffer for fluctuations between approval, execution and conversion. This is modest given ZK’s volatility since the last funding request was approved and the need to ensure that the Security Council, as an essential governance body, can meet its USD-denominated commitments.

  2. The Security Council will continue to be mindful of market impact when converting ZK into stablecoins. If more than $50,000 worth of ZK is proposed to be converted within a 24 hour period, OTC execution will be explored.

  3. Tools such as Sablier and LlamaPay can make sense when governance disburses tokens to individual contributors. Here, funding will be managed by the Security Council entity, an established ZKsync governance body. As such, an outright outright transfer was determined as appropriate.

  4. The percentage of the proposal represented by Director and entity administrative costs compared to the total budget is not a meaningful measure of whether those costs are appropriate. They are fixed costs associated with maintaining an active Cayman entity and are separate from the request for signer compensation. Further details regarding the administrative costs will be included in the annual report.

  5. Going forward, the Security Council will align reporting with the funding cadence and is happy to commit to six-monthly reporting.

Appreciate the response and the move to a 6-month timeline. That’s definitely a step in the right direction, but looking at where the market and numbers stand right now, there are still a few practical issues that need to be addressed before this goes onchain:

  • 1. Spot price vs. Hardcoded $0.007:

    • ZK is currently trading around $0.011. Sending 32.7M ZK means the multisig would pull roughly $360k out of the treasury for a $229k budget—which is about $130k (+57%) over target.

    • A hardcoded $0.007 isn’t acting as a 12.5% safety buffer anymore; it’s just a massive upfront over-allocation.

    • The transfer should either be calculated dynamically using a 7-day TWAP + buffer at the time of execution, or there needs to be an explicit rule stating that once the $229,000 USD is converted, all leftover ZK tokens are sent straight back to the treasury immediately, rather than sitting in the multisig for 6 months.

  • 2. The $50k daily OTC threshold:

    • Saying OTC “will be explored” for conversions over $50k/day is too loose to serve as a real guardrail.

    • $50,000 is over 21% of the entire 6-month budget. Doing a couple of $45k–$49k spot market sales over consecutive days would completely bypass that rule and hit order books with heavy slippage.

    • This needs a binding commitment to execution standards—either a designated OTC partner or automated TWAP execution.

  • 3. Lump-sum vs. Tranches:

    • Being a Cayman entity doesn’t prevent receiving funds in tranches.

    • Standard treasury management across Web3 foundations and working groups uses quarterly tranches or streaming precisely to avoid idle capital exposure and maintain basic accountability. Handing over 6 months of volatile tokens upfront shouldn’t be the default just because an entity is involved.

  • 4. Upfront cost breakdown for the Cayman entity:

    • No one is arguing against the legal need for a Cayman Foundation (signer liability protection, D&O insurance, tax neutrality, and independence from the Austrian association).

    • However, pushing the cost breakdown ($80k director fees + $50k admin) to a future annual report defeats the entire point of a governance review. Trust firms and corporate directors provide clear annual fee quotes before taking on an entity.

    • Token holders should see those high-level quotes (director retainers, registered agent, D&O insurance, compliance) before voting to approve the budget, not a year after the money has left the treasury.

Adding dynamic pricing, a binding rule to return excess tokens immediately, and sharing the quote estimates beforehand will make this proposal much easier for the community and delegates to get behind.

1 Like

Axia supports TPP-19. The Security Council is necessary governance-security infrastructure, and this six-month request maintains the eight-member structure and compensation framework approved under ZIP-15 without expanding its mandate. The reduced funding period gives the Token Assembly an earlier opportunity to reassess costs; Axia expects the Council to publish its committed six-month report covering security-review activity, spending, token conversions, and any remaining balance returned to the Assembly.

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We voted FOR.

We think it makes sense to fund the ZKsync Security Council for another six months. The Council is an important part of ZKsync’s security setup, and this request is much leaner than previous funding cycles.

We also appreciate that the proposal does not rely on new minting or a capped minter, and instead uses existing funds already held by governance.

The main point we looked into was the share of director and entity costs in the budget. After speaking with members of the Security Council, we understand that these are annual costs, and that part of this category also serves as a buffer for unexpected legal expenses or other issues that may arise during emergency situations. Given the experience around last year’s airdrop exploit and the volatility of the ZK token, we think that explanation is reasonable.

Overall, we voted FOR because the Security Council remains important for ZKsync, and this request is limited enough to support while still giving the Token Assembly a chance to reassess the structure in the next funding cycle.