[GAP-1] ZKsync Token Program Priorities 2025 Endorsement

Name Description
Proposal Title ZKsync Token Program Priorities 2025 v1.0
One Sentence Summary This proposal ratifies the ZKsync Token Program Priorities for 2025, facilitating better impact and effectiveness for ZK token allocations by the Token Assembly.
Proposal Author @rafa, on behalf of ZKsync Governance Team
Proposal Sponsor @Polar
Date Created 20-December-2024
Version 1.0
Summary of Action Ratify Document
Link to contracts Not Applicable

Purpose

The purpose of this proposal is to ratify the Token Assembly’s 2025 ZK token allocation priorities:

All ZK token allocations will prioritize bringing to reality ZKsync’s elastic network, an ever-expanding network of customizable chains. This includes three components: accelerating ZKsync protocol development, establishing the network of ZK Chains, and creating the home for Elastic Apps powered by ZKsync.

Abstract

Drawing on the insights shared by Alex Gluchowski on the ZKsync technical vision and roadmap, the ZKsync Governance Team proposes the Token Assembly adopt the ZKsync Token Program Priorities 2025. These priorities will help ensure the impactful and effective allocation of ZK tokens throughout the next year.

Motivation

Ensure impactful and effective allocations of ZK tokens in 2025, in alignment with the public ZKsync technical roadmap and values of the ZK Credo.

Specification

ZKsync Token Program Priorities 2025 v1.0

All ZK token allocations will prioritize bringing to reality ZKsync’s elastic network, an ever-expanding network of customizable chains. This includes three components: accelerating ZKsync protocol development, establishing the network of ZK Chains, and creating the home for Elastic Apps powered by ZKsync.*

1: Accelerate ZKsync Protocol Development

The vision of ZKsync requires a step-change advancement in protocol architecture. The protocol must have best-in-class security, developer experience, user experience, and interconnected public and private chains.

The Token Assembly should allocate ZK to accelerate ongoing research, development, and deployment. Specific technical components include EVM equivalence, decentralization, privacy, throughput scale, fee reduction, and interoperability.

2: Establish A Network of ZK Chains

ZK Chains are powered by ZKsync’s cryptographically-secured interop. As a network, they create a positive sum game: the more chains join, the higher the benefit for all other ZK Chains and their users. The Token Assembly should allocate ZK to accelerate and facilitate the adoption of ZK Chains by removing barriers to recruitment and activation. Furthermore, the Token Assembly should reward the pioneers powered by ZKsync, the initial elastic network that others expand.

3: Create the Home of Elastic Apps

ZKsync allows builders to create new Elastic Apps using unique offerings such as native account abstraction and interoperability. The Token Assembly should allocate ZK to reward the next generation of apps powered by ZKsync. Specifically, ZK allocations should accelerate the adoption of unique ZKsync features such as ZKsync SSO, interoperability, and privacy.

Rationale

This Governance Advisory Proposal (GAP) seeks to provide this context by presenting a prioritized set of ZK token allocation priorities for 2025, which, should they be ratified, will enable a clear and actionable path forward for the Token Assembly to evaluate Token Program Proposals.

The strategic priorities serve as a reference for the year to come. They can be updated or changed at any time to align with changing circumstances. They should not be considered a strict requirement for proposal approvals by the Token Assembly. Instead, the priorities serve as a cornerstone of ideation and evaluation by the Token Assembly, helping community members focus on what’s most important.

Revisions to these strategic priorities may be requested by another GAP and require the approval of the Token Assembly.

Why prioritize ZKsync protocol development?

ZKsync means technical excellence. The Token Assembly should reinforce this by supporting continuous research and development, pushing the boundary of what Ethereum protocols can do today. This improves ZKsync and maintains its offering at the cutting edge.

Protocol innovation goes hand-in-hand with protocol security. The ZKsync ecosystem has invested more than any other in security over the years, including by being a pioneer of protocol Security Councils. The Token Assembly should work on supporting this effort and incentivize strong security best principles to be applied.

These two focuses, development and security, are reflected in the first purpose of ZKsync governance: to secure, support, and improve the protocol. As a result, the strategic priorities begin with ZKsync Protocol Development. This includes foundational components such as EVM equivalence, Stage 1 Decentralization, throughput scale, fee reductions, and seamless interoperability. Once these pieces are in place, the Token Assembly can more easily and effectively grow ZKsync through new chains and apps.

Why prioritize a network of ZK Chains?

ZKsync interoperability built with zero-knowledge proofs is the best way to achieve horizontal scalability, offer seamless UX to users, and share liquidity across ZK Chains. It allows the ecosystem to feel like a single chain while enabling scale and customizability.

Yet the benefits of interoperability rely on a sizable network. The more chains that join, the more users can be reached through all the connected ZK Chains; the more tools and apps deploy on these ZK Chains, the more utility users will have regardless of which chain they join. The Token Assembly must help remove current barriers to launch, such as high infrastructure costs, and reward ZK Chain first-movers.

Why prioritize Elastic Apps?

While the ZKsync protocol development and establishing a network of ZK Chains are a key priority as they form the foundation for apps, fostering an environment that promotes usage and experimentation with ZKsync’s interoperability, native account abstraction, and other unique features is essential for the ecosystem’s short and long-term growth. The Token Assembly should focus on attracting, supporting, and helping apps that unlock the unique power of ZKsync.

Implementation Plan

Upon proposal approval, priorities will be used as guide for Token Program Proposal evaluation and added as a reference in relevant governance documentation.

9 Likes

I thoroughly support this agenda!

However, I do not support this proposal in its current form and think these types of proposals are very dangerous.

AFAICT the delegates or token assembly cannot ‘ratify’ anything–a legal concept with a very specific meaning. I do not think the token assembly should vote on things that can neither be executed onchain nor enforced on a binding basis offchain.

This would be better framed as voting to “express current support for these priorities” or something rather than by using faux-legal concepts.

4 Likes

That makes sense. I think the proposal could be revised handily enough to reflect that it’s not meant in some legally-binding manner.

2 Likes

This is really good! Let’s include this in the next Delegate call. It might also be helpful to organize a separate discussion focused on the types of proposals and ideas we’d like to see, and encourage, across the DAO, that align with this framework.

Regarding @lex_node’s point, perhaps we should consider introducing two different voting mechanisms:

  • Onchain: for stuff like protocol-related upgrades, or anything involving TPPs or token distributions.

  • Offchain: for stuff like amendments to the Code of Conduct, Proposal Guidelines, or creation of additional councils or workgroups, defining roles and responsibilities, accountability measures, or adding legal documents such as bylaws or a constitution, etc. Just giving random examples.

That way, we can keep the more critical or high-stakes decisions fully onchain while keeping others offchain as a formality.

Thoughts?

I agree with the proposal, especially the apps part. A lot of good work has been done so far on the protocol level, but now we need to shift focus more towards the top of the stack (apps) to attract (and retain) users and TVL.

“Ratify/ratification” can easily be replaced with other language (e.g. approval, confirmation, agreement) if folks are more comfortable with that.

@cap this separation already exists. While all proposal types are voted on onchain, ZIPs & TPPs have direct onchain executable actions where GAPs are for “offchain” decisions. The differences are broken down in more detail here in the docs. Or am I misunderstanding your point?

This is great feedback. I’ll amend the proposal to say “Endorse” instead. But will check with others to make sure we pick the right language.

[Draft-GAP] - Endorsement - ZKsync Token Program Priorities 2025 [AMENDED]

Name Description
Proposal Title ZKsync Token Program Priorities 2025
One Sentence Summary This proposal endorses the ZKsync Token Program Priorities for 2025, facilitating better impact and effectiveness for ZK token allocations by the Token Assembly.
Proposal Author @rafa, on behalf of ZKsync Governance Team
Proposal Sponsor @Polar
Date Created 20-December-2024
Version 2.0
Summary of Action Endorse Document
Link to contracts Not Applicable

Purpose

The purpose of this proposal is to endorse the Token Assembly’s 2025 ZK token allocation priorities:

All ZK token allocations will prioritize bringing to reality ZKsync’s elastic network, an ever-expanding network of customizable chains. This includes three components: accelerating ZKsync protocol development, establishing the network of ZK Chains, and creating the home for Elastic Apps powered by ZKsync.

Abstract

Drawing on the insights shared by Alex Gluchowski on the ZKsync technical vision and roadmap, the ZKsync Governance Team proposes the Token Assembly endorse the ZKsync Token Program Priorities 2025. These priorities will help ensure the impactful and effective allocation of ZK tokens throughout the next year.

Motivation

Ensure impactful and effective allocations of ZK tokens in 2025, in alignment with the public ZKsync technical roadmap and values of the ZK Credo.

Specification

ZKsync Token Program Priorities 2025 v1.0

All ZK token allocations will prioritize bringing to reality ZKsync’s elastic network, an ever-expanding network of customizable chains. This includes three components: accelerating ZKsync protocol development, establishing the network of ZK Chains, and creating the home for Elastic Apps powered by ZKsync.*

1: Accelerate ZKsync Protocol Development

The vision of ZKsync requires a step-change advancement in protocol architecture. The protocol must have best-in-class security, developer experience, user experience, and interconnected public and private chains.

The Token Assembly should allocate ZK to accelerate ongoing research, development, and deployment. Specific technical components include EVM equivalence, decentralization, privacy, throughput scale, fee reduction, and interoperability.

2: Establish A Network of ZK Chains

ZK Chains are powered by ZKsync’s cryptographically-secured interop. As a network, they create a positive sum game: the more chains join, the higher the benefit for all other ZK Chains and their users. The Token Assembly should allocate ZK to accelerate and facilitate the adoption of ZK Chains by removing barriers to recruitment and activation. Furthermore, the Token Assembly should reward the pioneers powered by ZKsync, the initial elastic network that others expand.

3: Create the Home of Elastic Apps

ZKsync allows builders to create new Elastic Apps using unique offerings such as native account abstraction and interoperability. The Token Assembly should allocate ZK to reward the next generation of apps powered by ZKsync. Specifically, ZK allocations should accelerate the adoption of unique ZKsync features such as ZKsync SSO, interoperability, and privacy.

Rationale

This Governance Advisory Proposal (GAP) seeks to provide this context by presenting a prioritized set of ZK token allocation priorities for 2025, which, should they be endorsed, will enable a clear and actionable path forward for the Token Assembly to evaluate Token Program Proposals.

The strategic priorities serve as a reference for the year to come. They can be updated or changed at any time to align with changing circumstances. They should not be considered a strict requirement for proposal approvals by the Token Assembly. Instead, the priorities serve as a cornerstone of ideation and evaluation by the Token Assembly, helping community members focus on what’s most important.

Revisions to these strategic priorities may be requested by another GAP and require the approval of the Token Assembly.

Why prioritize ZKsync protocol development?

ZKsync means technical excellence. The Token Assembly should reinforce this by supporting continuous research and development, pushing the boundary of what Ethereum protocols can do today. This improves ZKsync and maintains its offering at the cutting edge.

Protocol innovation goes hand-in-hand with protocol security. The ZKsync ecosystem has invested more than any other in security over the years, including by being a pioneer of protocol Security Councils. The Token Assembly should work on supporting this effort and incentivize strong security best principles to be applied.

These two focuses, development and security, are reflected in the first purpose of ZKsync governance: to secure, support, and improve the protocol. As a result, the strategic priorities begin with ZKsync Protocol Development. This includes foundational components such as EVM equivalence, Stage 1 Decentralization, throughput scale, fee reductions, and seamless interoperability. Once these pieces are in place, the Token Assembly can more easily and effectively grow ZKsync through new chains and apps.

Why prioritize a network of ZK Chains?

ZKsync interoperability built with zero-knowledge proofs is the best way to achieve horizontal scalability, offer seamless UX to users, and share liquidity across ZK Chains. It allows the ecosystem to feel like a single chain while enabling scale and customizability.

Yet the benefits of interoperability rely on a sizable network. The more chains that join, the more users can be reached through all the connected ZK Chains; the more tools and apps deploy on these ZK Chains, the more utility users will have regardless of which chain they join. The Token Assembly must help remove current barriers to launch, such as high infrastructure costs, and reward ZK Chain first-movers.

Why prioritize Elastic Apps?

While the ZKsync protocol development and establishing a network of ZK Chains are a key priority as they form the foundation for apps, fostering an environment that promotes usage and experimentation with ZKsync’s interoperability, native account abstraction, and other unique features is essential for the ecosystem’s short and long-term growth. The Token Assembly should focus on attracting, supporting, and helping apps that unlock the unique power of ZKsync.

Implementation Plan

Upon proposal approval, priorities will be used as guide for Token Program Proposal evaluation and added as a reference in relevant governance documentation.

Thank you for the update, I also believe this is a great step forward. Maybe in a year or two we could even create a budget per priority and year so that it’s transparent from the beginning what and how things will be supported through the upcoming months.

I do have a question connected to e.g. the following statement:

The more chains that join, the more users can be reached through all the connected ZK Chains; […] The Token Assembly must help remove current barriers to launch, such as high infrastructure costs, and reward ZK Chain first-movers.

Matter Labs has a BD team/ is doing business development and likely also working towards this goal.

  1. do they have a zk budget they can offer ZK chain first-movers?
  2. how can we make sure we aren’t incentivizing the same projects twice/ are sharing infos with regards to chains?

The same applies for Elastic Apps.

1 Like

I’m going to look into this and let the ML team know about your question.

Hi Benido,

Thank you for the question. I think it’s a fair questions, and I will reply below

But before, I’d like to clarify a few points:

  1. Although the investors and employees of Matter Labs received ZK tokens, Matter Labs itself (the company) did not receive a token allocation. Additionally, Matter Labs investors and employees were not eligible to receive an airdrop

  2. The responsibility for doing Business Development for the ecosystem belongs to the ZKsync Foundation (ZKF) not Matter Labs. ZKF is currently working with multiple ZK Chains, applications, and ecosystem infrastructure partners. ZKF has its own supply of ZK tokens and engages third parties to assist with BD and marketing work, in addition to doing some of those activities itself (currently, it does engage Matter Labs among other parties to carry out some of that work, but as we grow the ZKF’s staff over time, we expect more of that work to be done directly by ZKF)

In response to your question, the ZKsync Foundation doesn’t have a program for ZK chain first-movers but - after speaking with Rafa - I think it could be useful to work on one or more TPP to support this

For instance, I saw recently a post by Dr. Nick and Areta that could help allocate tokens as well to the flagship Elastic Apps

Regarding your second question, I can confirm that the ZKF team monitors governance discussions and works with the ZKsync Association to ensure that parties who receive allocations from the Token Assembly do not also receive tokens from ZKF for the same purpose. This helps ensure that we avoid a scenario where tokens are distributed to the same parties twice for the same purpose

Hope this helps!

3 Likes

Thank you for this detailed response. I guess I was asking for BD / Matter Labs because of Golems twitter.

But if there’s no allocation for Matter labs but it’s the Foundations task, then basically my idea would be to coordinate with them as also suggested by you to make sure there aren’t two entities working on similar things without sharing infos.

2 Likes