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

[Lesmith]

We really like this proposal!

Firstly, this programme is the natural evolution of Ignite. It builds on the liquidity that the Ignite programme captured and now looks to develop real usage of the chain by incentivising consumer application activity. Going further, the use of automated, KPI-based distributions of funds are likely the future of token distributions, whether they be grants or airdrops. I am very interested in seeing how it pans out and what lessons we can draw from it for future on-chain agreement and incentive programmes.

Secondly, this programme goes beyond simply providing incentives to grow the ecosystem, taking a proactive approach to support the projects in meeting their KPIs. This is primarily in supporting and promoting elastic applications to the broader ZKsync ecosystem. The VC-matching takes this even further, encouraging projects to build on and commit to elastic chains whilst providing them with additional capital to make it a success.

Lastly, the focus on metrics that grow the underlying chain are particularly interesting due to the positive flywheel effects it creates. (Grow the chains key metrics > attracts builders > dapps attract new users > grows the chains key metrics). Beyond the flywheel, it removes significant amounts of complexity and aligns incentives amongst all participants so that we can build together towards a common goal.

Overall, this is a forward-thinking, Web3-first approach to incentives focussing on the missing piece in the crypto puzzle: non-financial consumer applications that people actually use. We are very excited about the value this programme could bring to Sophon and the broader ZKsync ecosystem. We already have some great consumer applications in mind for the programme and are very excited about the potential impact it could have on our ecosystem.

[Areta]

Proposal Amendments

Hi all,

Thank you for your engagement so far, both on and off the forum. We’ve consolidated the feedback and are working on the following potential amendments. We’ve also received ten completed interest forms and are in touch with selected ZK Chains and apps to guide through the program elements.

We are currently testing assumptions behind these amendments and will present an update during the proposal call on Wednesday 22 January at 17.30 CET / 11.30 ET. Link here

Please continue to reach out for any feedback, questions, or ideas!

---

Potential Amendments

Please find below the detailed amendments currently in discussion.

1. Matching ZK Chain Incentive Programs

• We plan to amend the allocation mechanics to match ZK Chain growth programs so that ZK Chains also have skin in the game, versus rewarding apps directly. This approach would involve three levels of commitment, each with its own budget:
  — 1. Upfront Allocation – Provided upon acceptance
  — 2. Incentive Program Matching – For user activity
  — 3. VC Matching – For apps raising funds from a defined list of top 20 VCs
• Additionally, the distribution support component would stay as is to help spread awareness.

2. ZK Chain / App Participant Journeys

• ZK Chains: Building on the matching mechanic for ZK Chain Incentive programs, ZK Chains can apply for ZK token allocations by outlining:
  — 1. Program Structure – How their incentive program is organized
  — 2. Included Apps & KPIs – Which apps are involved and the metrics they aim to achieve
  — 3. Requested Allocation – The amount of ZK tokens they need
  — As before, the Catalyst program will work closely with these ZK Chains to refine their incentive programs and set KPIs.

• Elastic Apps: Apps included in the program can stream incentives to their users and developers through both the ZK Chains and Catalyst. They’ll also have access to distribution channels, such as marketing support, to help drive adoption.

3. VC Allocation

• On top of the matching allocation coming directly from the VC side for apps that are not yet part of the program, we think about amending the program for apps that are already part of the program.
• If an app within the program secures funding from one of the prioritized VCs, it will unlock a matching allocation. This adds an additional incentive for both apps and top VCs to participate.

---

Next steps

With the amendments in place and a perceived level of positive interest across the DAO, we aim to move Catalyst to an onchain vote by the end of the week.

We will be holding an AMA for the ZKsync ecosystem to walk through this proposal on Wednesday 22 January at 17.30 CET / 11.30 ET. Link here

We remain open for feedback on and off the forum - thanks for taking the time to engage!

---

Helpful links

• Catalyst Intro Thread: here
• Catalyst AMA Call 22 Jan: here

[Gabriel]

@Areta

The Catalyst Review Committee (CRC), acts as an oversight committee, structured in the same way as in Ignite, with decision-making and program-halting rights, including Gauntlet (Analytics Audit), Polar, Paul Dylan-Ennis (Researcher), Uniswap Builder Support, Aaron Lamphere (Ecosystem Growth), Matter Labs, Ivan Bogatyy (ZK Chain Ecosystem Support), Aleph_v, ZK Nation Security Council (Security), [TBC] (Consumer VC), [TBC] (Consumer VC) and [TBC] (Consumer VC). The CRC is responsible for reviewing the monthly payouts and has veto authority.

I think you should include independent delegates instead of Areta friends in the committee. We need more decentralization and oversight from independent parties. There are a lot of very well-prepared individuals here.

[sid_areta]

Hi @Gabriel,

Thank you for the feedback!

The intention behind this composition of the CRC was to gather a group of experts in ecosystem growth, consumer crypto, mechanism design, onchain analysis, and security, along with including expertise from Matter Labs on understanding the technical capabilities of the ZK Stack.

Three of the committee members (Polar, Aleph_v, and Ivan) are already intimately involved with the ZK ecosystem as delegates, members of the Security Council, and at Matter Labs respectively, while Aaron and Gauntlet bring significant expertise in ecosystem growth, onchain analysis, and mechanism design. We also plan on rounding the CRC off with experts from the top consumer crypto VCs in the space, and we’re confident that this committee has the right mix of skills to be able to best guide the Catalyst program.

[Bernard_Areta]

Hi @PGov,

Thanks for taking the time to go through the full proposal. You’ve highlighted some important design choices we’ve made:

1. Aligning rewards with on-chain performance is a key element of the program. Every distributed token should be tied to value generated for the elastic chain. By allocating funds to ZK Chain programs and cascading them to recipients for on-chain activity—while we serve as a guiding and monitoring node—we will learn over time how to value different KPIs and understand their ultimate impact on the ecosystem.
2. Regarding anti-gaming measures, the reputational risk of exploiting the system is central. By allocating tokens to ZK Chains only if they implement advanced anti-farming mechanisms, we incentivize them to set up robust programs that promote sustainable activity. We will act as an analytics function, publicly reporting any potential breaches.
3. Reflection periods and halting mechanisms are at the core of this program, which we believe is essential looking at how ambitious the mission is. We need these baked in checkpoints to steer the program based on the learnings and to de-risk allocation if the expected value does not materialize.

Again, thanks for your time and feedback!

[Benido]

First of all thank you for the work that has been put into this. If it takes me half an hour to only read, I don’t want to know how long it took you to draft!

Some remarks:

Unlike in anonymous airdrops, app builders are doxxed and apps seeking to use fake activity expose themselves to reputation risk and the possibility of not receiving long-term support from the ZK Chain they are building on (and the wider ZK ecosystem).
Everything is public. We will look into the transactions and how KPIs are achieved. If there is suspicious activity, we will publicly highlight it on the website dashboard and inform the DAO / ZK Chains.
This will result in (1) funds not being paid out due to the veto right of the review committee, and (2) reputational damage for the app in question in the community and on its home ZK Chain, which the app would, in all likelihood, want to avoid at all costs.

Especially MAUs, but also trading volume can and will be faked and gamed. The industry has not found a way to exclude airdrop hunters, I expect similar results here. I understand the difference between apps and users, but that’s the first plausible argument for any app (“why would we risk that?”) and proving faked metrics will likely only be possible with whistle blowers.

Also it will be hard for the committee and its members to accuse business partners of fraud. So I expect this veto right to be of theoretical nature.

We might see a little less gaming, but I sadly doubt this will be enough to not be exploited in the end.

Membership
Members of the CRC in Wave 1, to be ratified by the Token Assembly upon proposal approval, are:
Polar, Paul Dylan-Ennis** — Researcher
Gauntlet, Trevor Normandi**— Analytics Audit
Uniswap Ecosystem Growth, Aaron Lamphere** — Ecosystem Growth / Builder Support
Matter Labs, Ivan Bogatyy** — VP Engineering
Aleph_v,** ZK Nation Security Council — Security
[Confirming] TBD** — Consumer Crypto VC Expert

I would like to echo @Gabriel’s opinion here that at least one, best case 3 independent delegates should be part of the CRC.

I raised that concern as a feedback for the Ignite Program

1. I hope we can find a more decentralized approach with more Token Assembly involvement for future proposals. […]
   tl;dr: I am okay with taking a pragmatic approach here, but for future proposals the bar would be higher and I hope the values zksync shared won’t be aspirational forever.

I understand there are is one delegate - but as stated in the Ignite thread the process on how to pick the delegate is important too. From everything I have read Polar is a brilliant pick, but I would like to add e.g. 2 more delegates that were not proposed by you, but picked purely by the TA.

Since there is no time pressure for this proposal I don’t think that should be an issue, especially since the VC experts aren’t defined either.

[Bernard_Areta]

Hi @Lesmith,

Appreciate you reading the proposal and granting feedback! Find some reactions on the points below:

1. Moving from liquidity incentives to growing the app layer
   This is exactly our goal while we develop a true TPP with automated dynamics and fewer humans in the loop over time. By focusing on ZK Chain growth programs, we distribute funding to foster on-chain activity while ensuring the chains themselves have skin in the game.

2. Manual guidance of Catalyst for ZK Chains
   We see the ZK Chains in the driver’s seat and want them to act flexibly, with our support as needed. Through collaboration with key ZK Chains, we’ll provide guidance and help establish benchmarks for value creation. We plan to use these insights to optimize their programs and support the growth of their app ecosystems. This means also supporting program creation and KPI setting support.

3. Simplicity of reward mechanisms
   Although we still rely on human oversight to facilitate learning and optimize the program, the token mechanics and flow are designed to function as naturally as possible. By aligning incentives among participants (ZK Chains, apps, and users) and ensuring ZK Chains have skin in the game, we aim for the system to become self-sustaining. Catalyst will maintain a steering and oversight role, and the CRC will participate with review and veto rights to stabilize the system.

We look forward to moving this forward and potentially working with you!

[bucky]

Thank you to everyone involved in crafting this comprehensive proposal. I see Catalyst as a promising complement to Ignite by focusing on Elastic Chains and the applications themselves. Since ZKsync’s core value proposition revolves around delivering a superior user experience at every level of interaction, enabling apps to shine will have a net-positive effect on the overall ecosystem.

The VC matching initiative is particularly intriguing and, in my opinion, could become one of the most effective components of Catalyst. By requiring apps to undergo extensive due diligence (DD) from top-tier VCs, this approach ensures that only high-potential projects receive funding and support. Additionally, it will likely attract more attention to ZKsync-focused apps from the broader VC ecosystem, creating a clear win-win scenario for both developers and the network.

That said, I have a few questions about the selection criteria for ZK Chains and Apps. Beyond Era, most ZK Chains are in their early stages, and their associated apps and ecosystems may not yet meet the eligibility requirements. However, I agree that identifying the best ways to support and grow apps and user bases during these formative stages could yield significant long-term benefits.

I’ll attend the AMA later today to address my questions. If they remain unresolved, I’ll revisit the discussion here with further thoughts.

[Gabriel]

Hi @sid_areta, your response seems like a restatement of your initial post. I still stand by my opinion that Areta isn’t contributing to a more decentralized DAO if you’re just selecting your own council preferred delegates.

Electing council members through a transparent process is the best practice, and bypassing this step feels like cutting corners.

p.d I do think polar is a great delegate and would be a great addition to the council.

[lex_node]

@Gabriel

I think you should include independent delegates instead of Areta friends in the committee. We need more decentralization and oversight from independent parties. There are a lot of very well-prepared individuals here.

Agreed. Just in general it feels too many things are ‘bundled’ together in this proposal with little discussion and little ongoing ability of tokenholders/delegates to have meaningful influence after the proposal is approved.

[lex_node]

As a delegate I’ll be voting no on this. The design is too centralized into companies and committees who have no clear lines of accountability or transparency back to tokenholders, and the way the proposal was prepared was not really done transparently or in active consultation with tokenholders or delegates. Many aspects of the design seem arbitrary, centralized and poorly justified. I also do not like the way that this was ‘bundled’ into ignite itself such that one could not approve Ignite without also approving this empowerment of Areta and Factory, who did not engage in any kind of RFP or bidding process for this work against other potential players in the ecosystem who might be interested in making proposals for how such a program can work. It’s also unclear to me how much these entities are getting paid for this work, on what payout schedule, and with what potential clawback mechanisms if they underperform.

[Bernard_Areta]

Hi @Gabriel, and @lex_node,

Thanks for your time reading the proposal! As both of you tackle a similar point on RFC processes for council staffing I’ll answer both here:

We find it an interesting conversation to unfold. Appreciate the ideas here. We’re curious, why you think there should be RFC processes as default for a proposal that DAO contributors want to implement?

The process of proposal formation was discussed many times on community calls and on the ground in DevCon at the ZKsync meet-ups. Haven’t heard anything that we need more RFC processes yet, as all the contributors forming teams seem to have met organically in the forum or community calls. But interesting to hear your view, I find it a genuinely interesting discussion.

To shine light on how this proposal came to fruition, is what I think should be an example for TPPs to form. The proposal originated out of discussions we had on early community calls and has been baked by the community itself. Dr.Nick and us got to know each other over discussions about ZKsync and then met on a ZKsync delegate meetup in Bangkok to detail it out.

The council seats were staffed in a skillset first manner. We need capable people covering different angles (growth, ZK Chain knowledge, capital allocation knowledge, analytics) etc. - for this we worked with the community to pick these names. We’re not married to the process, if the token assembly is largely aligned that they want an RFC process to staff seats, we’re happy to consider this.

What would your ideal process here be? What would you change in how the token assembly and association operate so far?

Curious to get your views here or via dm in TG!

[lex_node]

@Bernard_Areta

elf. Dr.Nick and us got to know each other over discussions about ZKsync and then met on a ZKsync delegate meetup in Bangkok to detail it out.

The council seats were staffed in a skillset first manner. We need capable people covering different angles (growth, ZK Chain knowledge, capital allocation knowledge, analytics) etc. - for this we worked with the community to pick these names. We’re not married to the process, if the token assembly is largely aligned that they want an RFC process to staff seats, we’re happy to consider this.

What would your ideal process here be? What would you change in how the token assembly and association operate so far?

Curious to get your views here or via dm in TG!

I think there should be RFPs for major governance mechanism design jobs so that the DAO can consider alternative possibilities and providers. Factory Labs is run by a respected person in the community but the grant to them is currently worth $600k and could end up being worth much more since denominated in ZK–essentially, we are funding a new governance start-up with no existing tech and no track record of delivering software. This occurred without discussion of alternative potential providers or alternative potential designs. Frankly, it feels rigged–out of nowhere. Doesn’t make sense to me not to let other players such as Hats, MetaLeX, Aragon, and others compete for this work.

[Bernard_Areta]

I totally understand your angle to want to see more RFCs in the DAO space. We fundamentally agree, and would also love to save the months of conceptualizing and doing all the (unpaid) footwork that goes into a larger proposal. In this case, the way we see it is that the DAO should be an open space for coming up with ideas and propositions to implement them, and not limit this via processes, this includes mechanisms but also give freedom to the team who designs a program to execute it.

In our case, we have met Nick and shared the same vision and developed an organic collaboration work model. We took part in the ZKsync delegate workshop at Devcon together, moved the idea forward, met a couple of times and iterated this over months since we talked about it for the first time on a community call (all public). After multiple months of iteration, I would find it very inorganic to then say - look here is our program that our two parties have been working on for months, iterated with ZK chains, delegates, ML, community call etc. - so who wants to do the work now? I don’t believe this is how it should / and can work. Where would these ideas then come from? Or would all people just wait for ready to deliver RFCs? This would limit innovation massively. Imo it’s a different discussion if the foundation decides to put out these type of missions and contributors can raise their hand to pitch who wants to “execute”.

On the flipside of all of this, the way we see it there is still a lot of design space to take TPPs further. I know there are multiple other groups currently working on similar programs. E.g., Stable Lab (CC @rspa_StableLab) are still looking for a Technical Lead for their program. I believe its a scarce resource in our DAO, so I am sure he would be happy if you want to take on the job with MetaLeX, or if Aragon or Hats raise their hands.

I’m sure you’ve met many of the teams, if not, happy to put you in touch - otherwise, might also be good to check in on a community call to get a status who is working on what. I know a lot of people would love to have you on board for their proposals!

[lex_node]

The economic aspects of the proposal should be un-bundled from the tech provider & mechanism design aspect

The tech provider aspect should be open to RFP by all governance tooling companies and should not involve basically funding a brand-new governance startup

Areta and Factory should disclose all agreements between them and whether Areta will have any equity or other interest in Factory, etc.

I really do not like the process for this proposal.

There was an entire ZKsync grant program for governance tooling projects to submit designs and tech for TPPs. MetaLeX, Hats and others put substantial work into that (the grants were small compared to the work, and the suggestion was that good designs would be rewarded by support for being full TPP providers later) to build out a bunch of stuff that is ready to go. I don’t understand why all that work is just being ignored/cast aside in favor of funding Dr. Nick’s startup and re-starting from scratch without any sort of comparison of alternative providers or designs.

MetaLeX alone put in probably a month of work on audited smart contracts, complete webapp functionality, etc., for a mere $20k or less grant that we have not even been paid yet (need to go back and calculate based on current ZK price how much it’s worth currently). To see a company that doesn’t even have tech yet getting $600k to build out from-scratch stuff based on vague forum posts feels very bad for MetaLeX (I’m sure Hats et al would feel similar re: the work they put in) while also not being a great deal for the DAO as they will be relying on a completely unproven tech provider with no prior / independent VC backing and no real existing team etc.

Here is a link to MetaLeX’s demo of a full automated TPP setup on ZKsync testnet. Our setup could be deployed much more quickly and cheaply and–because we are able to set up enforceable legal covenants for every fuzzy " we will do x, y, and z" statement in the proposal and can give the Token Assembly member management and other direct oversight and remedial capabilities–in a much more trust-minimized fashion. Our tech is not vaporware–we have fully audited smart contracts, a great web app, and a full tech team that has already been building on ZKsync for months now.

The DAO should not pay a fortune for a governance tech buildout proposal that is bundled with an economic incentives program proposal–especially since, by their own admission, the program would be running at least a year before the tech is ready. These are two very different things and should be handled separately.

[lex_node]

@Benido

I understand there are is one delegate - but as stated in the Ignite thread the process on how to pick the delegate is important too. From everything I have read Polar is a brilliant pick, but I would like to add e.g. 2 more delegates that were not proposed by you, but picked purely by the TA.

I like Polar but I’m not sure he should be assumed to be independent here. There isn’t some disclosure of how everyone is or is not affiliated or otherwise friendly.

[Gabriel]

I’m really impressed by how you can ask for $1M for marketing and website development, and then include the following paragraph: ‘If workstreams are proposed to be conducted in-house, Areta must obtain CRC sign-off.’

And Areta is choosing the CRC.

[Benido]

@Bernard_Areta

After multiple months of iteration, I would find it very inorganic to then say - look here is our program that our two parties have been working on for months, iterated with ZK chains, delegates, ML, community call etc. - so who wants to do the work now? I don’t believe this is how it should / and can work. Where would these ideas then come from?

Doesn’t this just mean that implemented ideas should be rewarded (retroactively)? Especially since concept and implementation are usually two very different things that need a distinct skill set?

I agree with you that you are obviously free to come up with ideas and that the process did not exclude other parties/ delegates/ etc. (at the same time not everyone was in e.g. Bangkok, so there were also some limits in likely important phases of the creation).

Still I agree with @lex_node that the implementation (and potentially design changes because cost/benefit of using existing tools) should be separate. Isn’t it also in your interest as a delegate that cost is as low as possible to minimize spending since ZK is limited down the road?

I truly believe that if an idea is greenlit by governance and hence later implemented there should be a (huge?) reward for the work that was being done. I don’t think that creating a concept means that you should do all the work all the time (and oversee that work on top).

[polar]

That’s a fair thing to inquire about. From my end I can disclose:

• I have never met or talked to anyone from Areta, was not involved in the creation of the proposal and was not at the zkSync DevCon meetup (or even at Devcon!).
• I am friendly with @drnick and we’ve met at a couple of conferences. Just before the proposal went live, Nick asked if I’d be happy to sit on the committee due to expertise in the social layer, which I am happy to do.

Will leave it to the DAO members judgment whether this constitutes independent/autonomous, though that is how I see myself in this case.

[theshelb]

Hey everyone! The Gov Team wanted to share a few clarifications on the TPP development process that are relevant to the discussion here.

Proposal development: Proposals are developed by proposal authors, who are in charge of outlining and designing Token Programs and associated mechanics. If the authors of a proposal do not have the ability to fulfill the technical requirements of developing a token mechanic, they are responsible for identifying and selecting a technical partner that can help support the proposal.

Formal Proposal Process: Currently, there is no requirement (on-or offchain) in the formal TPP process for authors to run a RFP to source or select technical partners. The decision of technical partners for proposals is up to the proposal author. This was an intentional part of the design to allow for flexibility and minimize governance administration.

TA Approval: The Token Assembly makes the ultimate decision of whether to approve or decline a proposal developed and posted by proposal authors.

As part of the governance design, Governance Advisory Proposals (GAPs) can be used to propose amendments to the guidelines and formal procedures available at docs.zknation.io.

Tips for sourcing Technical Partners:

• The ZKsync Association has a variety of connections with technical partners, and we are happy make introductions when requested. These include, but are not limited to ScopeLift, Hats, MetaLeX, Sablier, Hedgy, Drips, Tally, and others.
• The Gov Team regularly coordinates with technical partners when needed. For example, four of the partners listed above (Hats, Hedgey, Sablier, and MetaLeX) participated in an MVP exploration program to understand capped minter possibilities and test the Token Governor design. A summary of the program outputs will be shared in the coming week.
• Potential technical partners have already begun posting on the forum to showcase their work, which could be utilized in developing token mechanics (e.g., Drips, Tally). The Governance Team encourages all potential technical partners to share their work on the forum. To make these posts easier to locate, Shelby has created a new subcategory under Token Mechanics titled "TPP Builders.”

The Governance Team is monitoring these discussions and will try to use this to identify ways to improve the process.

Edit: A reminder of the role of the Governance Team and support that offered for proposal development can be found in the ZKsync Governance Team Overview post.