[TPP #] ZKsync Catalyst Program ("Catalyst")

Areta · January 24, 2025, 6:01pm

Hi all, thank you so much for the great engagement on this proposal! Below, we will address the key feedback that we have heard, including (I) Amendments / Actions, and (II) Clarifications.

Amendments / Actions

(I) Catalyst Review Committee Selection Process

Feedback: The CRC Selection Process is too centralised. How can we ensure these people don’t have a conflict of interest?

Pre-staffing of the Catalyst Review Committee (CRC) tasked with oversight of the program, incl. several veto and halting rights, raises questions of conflicts of interest. How can the TA be sure the council is free of these and that the CRC will follow its oversight function to act in the best interest of the ZKsync ecosystem.
There was an ask for a public council election process to staff the council via an open application process accessible to everyone. The final council seats would be determined by DAO votes.
This feedback was brought up by @lex_node, @Benido, and @Gabriel.

Amendment: Restructure the CRC + Implement DAO Advocate

Our initial approach to staffing the council prioritised skillsets. That is, we defined the skillsets needed for high-quality decision-making, incl. research, ecosystem growth, consumer VC, analytics, Token Assembly delegate, and BD for Matter Labs. We then engaged with community members and people in the wider network to fill these roles based on their skillsets.
Secondly, the Token Assembly currently does not have a process specifically for council elections, which is why we did not consider it for any function. While we sought the best people for the job, this approach is obviously subjective if there is no clear incentive alignment of committee members to the success of the program. I.e., every CRC member should feel the pain if the program is not performing and be incentivized to halt it.
Thirdly, we do believe in stronger alignment between the TA and its initiatives. E.g., through having a DAO advocate that is not pre-selected but put in place via election.
In response to the feedback received last week, we have restructured the committee to prioritize skin-in-the-game, match skillsets, and set up adjacent advisory roles connected to the DAO.

What we have done:

As we believe this is a core piece we went through multiple iterations. Ultimately, we are in the process of restructuring the committee. Each person has to have 100% skin in the game. Either their entire livelihood depends on ZKsync OR they are leaders in the specific skillset (e.g., Analytics).
There should not be a public election process that staffs this important committee with a mix of people with different subjective interests. The only interest we want to have is what is best for the ZKsync ecosystem.
Only this way we can guarantee 100% incentive alignment and take out the factor of the program designer potentially misstaffing the committee. If Catalyst should not add value the refined set of committee members will be the first to halt it and have a much stronger incentive to do so than elected delegates.
Parties who had solely advisory functions before should continue to be defined as such and explicitly hold a mandate with separate rights and responsibilities.
We have decided to establish an election process for a DAO advocate to be elected via Token Assembly vote. This will act as a monitoring mechanism and is part of the halting rights. As this can be any person, this person will naturally not be involved in the design mechanics of the program or define KPIs with ZK Chains.
Since the election process does not yet exist in the TA, we are currently identifying ways of implementing this feature for Wave 1 - the GAP governor does not allow for a multi-option feature at the moment and we are exploring how Snapshot or any other solutions can be used immediately in this context.
We will take up the responsibility of ensuring that an election takes place by including this commitment in the text for the onchain proposal. Specific adjustments to the current CRC will be announced in the amendments after full alignment with respective parties.

Disclaimer: After the initial post, this was re-edited on Jan 25th with trackable changes. Through several iterations, we transitioned from mere elections for council seats to ensuring that each member of the CRC has skin in the game, an additional DAO advocate seat, and moving advisory-only members out of the CRC.

(II) Governance Process Improvements for Strategy <> Technical Partner Matching

Feedback:

There was dissatisfaction around the matching of technical service providers with program designers and operators.
There was dissatisfaction with the general TPP process, with some calls for an RFC process to be put in place to match technical service providers with program designers and operators.
The technology provided by technical service providers should be subject to an RFC process.
This feedback was brought up by @lex_node, @benido, and @NathanVDH.

Amendment:

The Token Assembly needs to clarify the process of proposal formation. @theshelb has already commented here, and we plan to address this topic in a dedicated community call to ensure alignment. It came to our attention that technical providers are working on multiple ends - technical solutions, e.g., via grants, and directly on TPPs, and that there was a lack of transparency on the different possible routes to publishing a TPP.

Although proposal formation has been extensively discussed in community calls and ZKsync delegate meet-ups, there has not been much discussion around the incorporation of RFC processes in proposal formation. As such, TPP teams have formed organically without the demand for additional RFC processes. As @theshelb mentioned and @NathanVDH confirmed:

Our proposal exemplifies this approach. We first met Dr. Nick in the public community call, continued the conversations online, and ultimately met him on the ground in London and at a ZKsync delegate meet-up in Bangkok. We spent the time discussing TPPs, their innovative nature for capital allocation, and key avenues for the ZKsync ecosystem to grow. This ultimately led to the co-development of the Catalyst proposal over multiple months in alignment with the principle and goals of the TPP framework and also to the TPP priority of supporting Elastic Apps.

Moreover, as per Shelby’s second statement in our case, the authors of the proposal did have the ability to fulfil the technical requirements of developing the token mechanic, and have designed the Catalyst program around their technological capabilities and expertise, and are consequently able to fulfil the entire program’s technical requirements. Therefore, while an RFC process that separates proposal design from technology is an interesting discussion to have, we don’t believe it should be applied in this context because:

Our proposal wasn’t developed with such processes, and they aren’t a requirement of the Token Assembly - as Shelby said, “This was an intentional part of the design to allow for flexibility and minimize governance administration”.

Nonetheless, the feedback around RFC processes definitely merits further discussion. As delegates, we think this is an important topic to clarify and understand other delegates’ views on, and we plan on hosting a community call to discuss this topic and move it forward next week.
What Dr. Nick and Factory Labs bring to the table is far more than simply technological components and delivery.

It is important to clarify that Dr. Nick is not a mere technology provider for the Catalyst proposal. He is as much a co-author and designer of this proposal as Areta is, of the technical and mechanism design elements along with guidance and stakeholder management. It is also not that Areta is “just” doing the operations and management work for Catalyst - we also contribute significantly in defining how the technical components of Catalyst work from a conceptual and strategic perspective.

Therefore, the decision is not as simple as choosing a technology provider off the shelf; this entire process has been a true joint effort from both our parties, and Factory Labs is not “solely” a token distribution system or technical provider, but a 50/50 design and strategy partner in this proposal.

It is also presumptive to say that Factory Labs’ contracts do not have lindy. The contracts to be used for this proposal have been double audited by C4 and Consensys Diligence - you can find the information here. We of course appreciate that other providers believe that their solutions would work better in this context, as it is a competitive environment. However, we also believe that Factory Labs is the best party to execute Catalyst due to both, the design, strategy, and guidance elements and the technological elements.

Lastly, it is important to note that any technology developed as part of Catalyst will be in alignment with the TPP guidelines and specification: namely, “any new tech funded by the Token Assembly must be free use by ZKsync ecosystem”. Any IP developed will be public infrastructure that can be used by the Token Assembly across any other proposals without IP licensing or SaaS fees. The technology will be under a licensing framework that will grant full, open access to all technology developed for the TPP, including FL contracts, to all ZK Chains and Elastic Apps. This ensures that these contracts can be utilised and forked within the ZK ecosystem only, providing a significant competitive advantage and furthering the development of TPP infrastructure. As a tangible outcome, any project in the ecosystem will be able to permissionlessly distribute their tokens via airdrop or vesting arrangements using this infrastructure by Wave 2.

From our perspective, the avenues to grow this DAO and ecosystem are more numerous than the number of technology providers available to do so. There are a number of TPPs being worked on already which require strong technical partners - a case in point is the Blockchain Demand Boost proposal from StableLab. In a hyper-competitive blockchain ecosystem, an L2 like ZKsync can only gain mindspace and market share against its competitors when contributors come together to grow the pie, rather than fighting over the same small piece of land.

We have realised through this process that there is a gap in technical partners being connected with TPP authors, and want to play an active role as ZK Nation delegates in closing this gap. We will work closely together with the ZK Association to ensure matching between TPP authors and technical partners, and encourage DAO members to actively take part in creating their own TPPs that will advance this ecosystem.

What we will do:

We have realised that we all need to take more active responsibility in shaping the ecosystem as the Token Assembly, and as such, we will:

We will have an open discussion with the ZK Association and technical service providers on how the current TPP process can be collectively improved.
We will ask the ZK Association to bring together all the technical service providers that are currently part of the ecosystem together with current TPP teams and make this a more active approach.
We will establish bi-weekly Areta Office Hours where we can talk through any of these topics (and others that come up) on demand, to better fulfil our role as delegates.

(III) Difference to Ignite

Feedback: The proposal feels like it has an overlap with Ignite.

This feedback was brought up by @Gabriel.

Clarification: There is zero overlap with Ignite.

We designed the program specifically to be complementary. Ignite is targeted at apps on Era. This is focused on consumer apps on ZK Chains and there was no direct focus on ZK Chains for Ignite. Ignite makes Era a liquidity hub, which is very different.
This becomes clear if you look at the “Mission” section in the Abstract, where we say:

What we will do:

Add a chapter into the proposal to make the differences between Ignite and Catalyst crystal clear.

Clarifications

(IV) Inflation by Token Allocation

Feedback: Will the token allocation cause significant inflation?

This feedback was brought up by @Bucky.

Clarification:

Ignite and Catalyst manage token inflation in a controlled, non-harmful manner by mitigating risks, with OBL data showing effective incentives for Era as many funds are invested in DeFi protocols rather than frequently withdrawn.
Our goal is to build mindshare and sustainably promote ZK Chains and their applications by evolving traditional incentive mechanisms to balance sustainability and growth.
We are allocating 20 million tokens in Wave 1, aligning with your proposed approach, and look forward to collaborating on the distribution. We want to point out the possibility for you to stand for the 2 additional Catalyst Review Committee seats we will run elections for, to help drive this decision-making.
Additionally, we believe that long-term token allocations for growth initiatives are beneficial since token emission is limited by capped minters. We reward tokens monthly based on valuable onchain interactions and key performance indicators, ensuring that concerns about token inflation do not paralyse our ability to support large-scale ecosystem growth programs.
The wariness around inflation stems from a belief that all issued tokens will be sold, which is not true, and that there is a lack of ROI on token issuance. The goal of Catalyst, on the other hand, is to issue tokens to drive growth in a targeted, considered manner, in order to create value accrual across the whole network.
On a broader note, we think it is important to sustainably meet the ZKsync Token Program Priorities for 2025. You are indeed correct to be wary of inflation, and we are too. As such, this was a design decision we incorporated into the core of this proposal by ensuring multiple halting and review mechanisms, deliberation by experts around the “appropriate” amount of token allocations, and ensuring that tokens are only minted when valuable onchain interactions take place. It would be great to work closely together through the course of Catalyst to identify when token inflation is getting excessive and identify paths to mitigate it. As such, we also propose that a GAP is published in the near future to set the expected range of inflation for the next year or more.

(V) Premature Focus on ZK Chains

Feedback: ZK Chains are immature and Catalyst will not have the maximum impact by supporting them at the moment.

ZK Chains will naturally generate hype at launch, and most are backed by VCs and established names in the space. If a chain requires early support just to appear welcoming, it is a bearish signal.
Catalyst’s support should focus on apps with demonstrated potential to grow sustainably.
This feedback was brought up by @Bucky.

Clarification:

Catalyst does not directly reward ZK Chains; rather, it is directly targeted at sustainably rewarding the best-performing apps in the ZK Chain application layers via their growth programs. Each ZK Chain application will include details about the onchain interactions that they will aim to reward, and outline exactly how these interactions will feed into a top-line KPI defined by them and agreed upon in collaboration with the CRC. Based on the quantity of onchain interactions that have been achieved, each ZK Chain can “collect” its token allocation, which they must then distribute to the apps that have enabled these onchain interactions.
Therefore, Catalyst’s support is squarely on the apps with demonstrated potential to grow sustainably by maximally rewarding those apps that perform the best.
The intention of Catalyst is to ensure that ZK Chains stand up their own growth programs to support their application layers, with Catalyst acting as an enabler, guidance function, and reviewer of these growth programs. We do not want to hand out “free” money to ZK Chains at all. Catalyst will improve the performance of all growth programmes in the Elastic Chain and incentivise the creation of new ones, while ensuring that ZK as an asset is represented within ZK Chain ecosystems. This will ultimately improve both marketing for ZK and adoption of the token itself within ZK Chains.
More broadly, we want to iteratively improve these growth programs with the data we collect about “what is working” and “what’s not working”, both from a reward perspective, but also crucially from an anti-gaming perspective since each ZK Chain must implement anti-gaming measures in its growth program. As such:
- Catalyst will act as a “collective intelligence” by gathering empirical data about what works and what does not work in growth programs and anti-Sybil measures, and use this data to improve them across the ZKsync ecosystem, for both Chains and apps.
- Catalyst will create visibility via onchain data analysis of the performance of ZK Chains across the whole ecosystem, which provides crucial visibility for growth programs and their apps.
In conclusion, Catalyst will support the ZK Chain app layers before, during, and after their launch, maximising their chance of success. This could ultimately have a significant impact on the total valuation of ZK, which will be directly influenced by the valuations of the ZK Chains across the Elastic Chain ecosystem.

Next Steps

We are incorporating the proposal amendments as we speak.
Have open discussions with contributors who gave feedback to go through the amendments and iterate. We are reaching out to each individually.
We’ve reached out to the ZK Association to support a community call on the Governance Process topic.
We will use Snapshot or similar tooling for ZKsync to conduct elections for the additional committee members post the close of the onchain vote and prior to the start of Wave 1.

Our DMs remain open - we’re excited to move forward and continue iterating this in open! Thanks again for this amazing round of feedback, on and off the forum. We know mindspace in the current market is limited so we do appreciate you taking the time to digest our work and give quality feedback.