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

Token Mechanics Draft TPPs
18

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!

1 Like
19

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.

2 Likes
20

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.

1 Like
21

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.

image
image717×639 65.2 KB

2 Likes
22

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).

3 Likes
23

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.

5 Likes
24

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.

7 Likes
25

I’m hearing “this can actually be a real DAO now, just take your proposals directly to the forums!”

Good! That’s how it should be.

For context, though, this is very much not the vibe I got while participating in the governance tooling grant program. The vibe/messaging was that this was going to be a highly coordinated process where the teams that participated in the governance tooling grant program would be escalated to a next level where they are paired with TPP providers by the governance team, would all receive roughly similar compensation/opportunity at roughly the same time because the Association wants multiple redundant governance tooling providers and doesn’t want a winner-take-all result, etc. There was even a specific monetization strategy proposed as part of this–namely, some TBD % of each capped minter that ends up being connected with a governance team’s solution.

Therefore–despite, frankly, not thinking that this level of redundancy makes any sense–we built what was asked, demo’d in private, and sat patiently waiting for the coordinated process to unfold as promised. In the meantime it appears if we had just been building nothing while directly promoting ourselves in the forum, we would’ve been at the front of the line for what will indeed be a winner-take-all result, as the Token Assembly is certainly not going to want to pay ~6 different teams $600k each to all build roughly the same thing (which most of them have already built for $20k they have not yet been paid).

But, hey, I am all for having a real DAO and taking our case directly to the people. I am glad this is on the right track now. Code is law, and I guess we never should’ve relied on unenforceable social-layer promises as to how this will go, no matter how convincingly they were presented. We will go straight to the Token Assembly, and our proposal will involve trust-minimizing TPPs from day one both onchain and offchain instead of yeeting millions of dollars to a team that picks its own supervisors and needs a year and a minimum of $600k to rebuild trust-minimization tools that have already been built multiple times by multiple teams in accordance with the very specific instructions of the governance coordination team. A benefit is that we never really thought that was the ideal design anyway, and now we can feel free to propose exactly what we think is best for the community.

26

Hi Gabriel, good that you ask. This chapter might have been confusing.

Let me rephrase what the following means:

(1) In case Areta has to come on board and has to support with the awareness sprint, we will need to get the CRC approval first. This is merely a scope consideration, b/c its not part of the initial scope.

This would happen at no additional cost to the DAO. I.e., Areta would not charge additionally for this.

You can find the details of our role regarding steering of the marketing stream here:

(2) The 5M that is earmarked includes a significant contingency. I.e., its not “$1M for marketing and website”. All it does provide leeway for the case market should pick up / marketing shows an exceptional ROI / or similar in which case the CRC might want to decide to spend more. See here.

(3) We will work together with the ML marketing team to run a process to find the marketing partner for the deliverables below:

Appreciate you taking the time for feedback!

27

Thanks so much for the responses everyone. Glad to see the level of engagement and ideas on the core elements of our proposal.

I think there are some interesting points to discuss here and also some more ‘meta’ conversations about how the proposal formation process should take place. I want to shine some light on our design choicese

You are absolutely correct that we have yet to find good mechanisms for mitigating sybil games at scale and it will be a central component of this programme to support ZK Chains in the development of their incentive programmes for the app layer. A few key points that I think are truisms here:

  • Crypto runs on incentive schemes, from miners, to validators, to app layer incentives. It is the game and in fact is the key affordance of Web3 that will potentially facilitate extremely rapid growth in applications if we get it right.
  • We have no choice but to play that game, it is what tokens are for and all of the ZK Chains (if they have a token) are going to play it.
  • Some incentive programmes are better than others, there are practices and approaches to building them that make them more or less effective.

A big part of the goal of Catalyst is to support the development of effective growth programmes that maximises the value of token incentives for application layer growth at the Elastic Chain level. Importantly, all of the decisions of the CRC will be public and open for Token Assembly review, as will the data and mechanisms. I think that will diffuse the dynamic you’re talking about there about judging whether teams themselves have gamed the system. We will be operating this programme totally transparently so actors in the DAO, such as yourself, are able to hold this programme fully accountable.

Regarding the collaboration between Areta and Factory Labs. Our entire arrangement is on this proposal and completely public. Catalyst has been a 50/50 co-creation between the two entities. Furthermore, Areta has no stake in Factory Labs, or visa versa.

Regarding the call to separate out conceptual development of a proposal and technical delivery. I personally, don’t think that makes sense as a process, since it collapses technical partners into a very Web2-esque SaaS model that I think devalues the capabilities of not just us, but other excellent players in the space, who are well rounded teams of creators and builders. Personally, I would like to see TPPs that are ground up collaborations that expand the set of people who build in the space and work in the DAO ecosystem. A model like that will collapse the entire DAO service industry into a handful of players who can race to the bottom on costs, or even run at huge losses to capture DAOs and make them dependent on their technology. I am well aware that there are many token distribution systems out there. I am sure we will see proposals from them in the future. As it stands, there is nothing stopping future proposals opting for that approach if they want to. Beyond, that if the Token Assembly wanted to forumalise a procurement process, it could do so via a GAP.

Regarding the council formation process the people on the CRC have exactly the right competencies, skill sets and access to the industry that this programme needs to be of maximise it’s probability of success. I genuinely don’t think that it would be possible to arrive at that outcome with a totally open election process, which would essentially be pseudo-random popularity contest. Having said that, I am not averse at all to expanding the group to include additional members via an election process if the proposal passes.

It is completely untrue to say that Factory Labs has no tech. We have been building in this industry for years, dozens of audited smart contracts. There are clear short term deliverables on this programme that would be impossible to hit if we were cold starting.

We will ship good software that the Token Assembly and wider ecosystem can use in the very short term and if we don’t the DAO can activate the halting mechanisms and stop us from getting paid. If we simply default to small handful of players that are already well established then we get a highly centralised industry, limited innovation and a mindset stops the pie growing to include new entrants, who we think have a huge amount to offer to this ecosystem. You are right that I have built up a presence and reputation in this industry, being one of the only people in this industry who has never waivered on their belief in DAOs. It would be frankly insane for me to burn all that to zero, by proposing to deliver something that I didn’t think we could comfortably achieve.

To be absolutely clear, we are building on a stack of technology that we have been working on for years. We are not building from scratch, we are not building for 12 months and coming back with something. Our first deliverables being immediately supporting deployment of initial payments to app teams, major shipping moments on month 3, with the major automation work completed by month 6.

We will be taking all of this feedback onboard and will update the proposal in time for going onchain. We will provide full details of any movements here in advance of that. We will also append our audits and relevant contracts that we’ll be building on for this programme, as well as profiles of key team members

Thanks again everyone and please do keep the feedback and comments coming.

1 Like
28

First, thanks to Areta and Factory DAO for taking the time to put together such an extensive proposal.

Regarding an RFP:

First, I understand and support @lex_nodes request for an RFP proposal. The reality is, that it is most definitely in the interest of the DAO to do an RFP process. Both for cost and the best outcome. I believe some of the contention comes from the fact the proposer, albiet a great person and community member, is a delegate. I want to insist that I don’t blame Areta or Factory DAO for not going through an RFP process, they had no incentive to do so and there is no rule in the DAO pushing them to do so, as @theshelb noted. As a representative of Aragon, we would most definitely have participated in an RFP process and would have happily worked with many of the organizations mentioned including MetaLex, Hats, or Factory DAO.

If this was any other proposal, I’d gladly support the initiative being taken. This one however will dictate the structure and the success of the Zksync DAO for the next few years, so I believe it’s worth properly crossing the t’s. If there won’t be an RFP process, I hope to see many teams competing in order to make sure the DAO gets the best deal.

Regarding the merits of the proposal:

I do want to echo some of the issues raised in the thread and focus on one in particular: timing & security. The development of these TPPs represent a major risk to the DAO, from the lack of lindy from new smart contracts, to potential delays in development, the necessary lengthy audits that such critical smart contracts will need etc. ZKsync needs a solution like this quickly and cannot compromise on lindy.

This is where I believe Aragon can help deliver a faster and more secure solution. TPPs as described here (Token Program Proposals (TPPs) | ZK Nation) would work out of the box on our solution that has been audited and is ready to be used through our frontend. We don’t have some of the features described in this particular proposal ready now, but the core part of the infrastructure is available and audited.

That being said, future improvements to the TPP process as described in the proposal are extremely interesting and would certainly be outside the current scope of our product, and we’re more than happy to help deliver a solution faster based on a governance framework with a lot of lindy and built purposefully to support a variety of funding mechanisms through a unified governor and interface - this includes cooperation with other service providers who have been deeply involved on this subject already.

2 Likes
29

While I really appreciate the effort and thought behind the Catalyst proposal, my current sentiment is negative. This is not solely due to the mechanics discussed above but because of fundamental concerns that are important to token holders.

Here’s a short summary of my thoughts:

  • Inflation Concerns:

Ignite is already distributing 10-20M ZK tokens every two weeks, and the markets are currently underperforming. While I previously supported Ignite’s inflation as a necessary step for Era’s liquidity and survival, I believe we cannot afford additional inflation at this time.

I understand the argument that a potential bull market could positively impact ZK before this proposal begins to spend significant amounts. However, from a token holder’s perspective, the “no unlock till June” sentiment has been a strong reassurance. I’d prefer to maintain this status quo rather than introduce further uncertainty.

  • Premature Focus on ZK Chains:

I don’t think putting ZK Chains in charge at this stage is the right move. Their ecosystems are still immature, and while Catalyst could provide a boost, I don’t believe it would have the maximum effect right now. ZK Chains will naturally generate hype at launch. I would prefer to first observe how they perform, identify standout chains and apps, and then deploy Catalyst to sustain momentum after the initial hype wanes.

While the success of ZK Chains is beneficial for ZKsync as a network and general sentiment, I am skeptical about the immediate impact on the ZK token. Token holders should not bear the cost of boosting ZK Chains today before revenue generation takes place for them or there is a high probability of success.

  • VC Matching Program:

The VC matching initiative stands out as the most effective and promising component of Catalyst. It’s an excellent mechanism to attract high-quality, due-diligence-vetted builders and draw greater VC attention to the ecosystem.

If this initiative were presented as a separate proposal, I would support it. It is more likely to succeed, requires a relatively small allocation, and inherently brings additional capital and high-potential apps to Elastic Chains, creating immediate value for the ecosystem.

My kinda middleway suggestion:

As a more cautious approach, maybe it worth to discuss testing Catalyst within Ignite (by allocation 10M ZK) by targeting a few flagship apps from different ZK Chains. This could provide valuable insights into the program’s impact on app growth, ecosystem activity, and token performance without introducing unnecessary inflation or committing to the full program prematurely. If we see value then we can discuss this proposal as a individual one and maybe with right mechanics which can take place in time.

I’d also suggest proceed cautiously by reducing Catalyst’s initial allocation to 10M-20M ZK (or a similar amount) and evaluating its performance over a smaller timeframe.

Lastly,

I’ll closely follow all discussions surrounding this proposal. If the points raised during these discussions and subsequent evidence address my concerns regarding inflation and the current status of ZK Chains, I’m open to revisiting and adjusting my stance. My goal is to ensure that any decisions align with the best interests of both the ecosystem and token holders.

3 Likes
30

@bucky In regards to the bi weekly ZK inflation/distributions from Ignite, we are actively tracking what users are doing with those ZK rewards at OBL. Here is a dashboard with that data: OpenBlock Labs

So far what we have seen is that ~30% of claimed tokens sold on Dexes/transferred to Cexes and about 32% of claimed tokens being re-deployed into Defi. In addition, only about 50% of eligible ZK has been claimed (3.3M) which seems consistent with the 12M ZK still left in the Merkl distributor (the other 3M unclaimed from period 1 and the 9M from period 2 that hasn’t been made eligible to claim yet. (https://era.zksync.network/address/0xe117ed7Ef16d3c28fCBA7eC49AFAD77f451a6a21)

We are missing the amount of ZK that users have left in their wallets (it’s not necessarily the remaining ~38%) due to an oversight on the dashboard, but will get that added soon.

Please let us know if there are any additional metrics in regards to claims that you would like to see and we can work on adding them.

2 Likes
31

Hi Baki, thanks a lot for the comments. Appreciate your openness to iterate together - this is exactly what we can work with. Sid reached out for a call - keen to work on the kinda middleway suggestion together.

See below our initial reactions, looking forward to take these further:

(1) On Inflation:

  • Essentially, Ignite and Catalyst are ensuring that token inflation occurs in a managed / non-harmful manner. We have de-risked much of it, and OBL data shows that the incentives are working for Era, where many of the incentives are deposited into DeFi protocols and not frequently cashed out. The aim is to use this period to generate mindshare and promote ZK chains and their applications sustainably. Catalyst is an evolution of incentive mechanisms, which traditionally just handed out capital and tokens. We are striving to balance both sustainability and gaining mindshare, which is admittedly a difficult task to juggle. However, we believe it will ultimately have a net positive impact on the ecosystem, and that is all we are aiming for.
  • Also, we start by allocating 20 million tokens in Wave 1, which aligns with the approach you are proposing - would love to think through the split together and see if we can hammer this out more.
  • Lastly, we see tokens toward growth initiatives over a long time scale to be beneficial because token emission is constrained by the capped minters. We are only rewarding tokens on a monthly basis, and they are tied to the achievement of actual useful onchain interactions and key performance indicators (KPIs). If we stick to the argument that token inflation prevents us from funding anything, we will be stuck in paralysis and unable to support large-scale programs to grow the ecosystem.

(2) On if the focus on ZK Chains is right:

  • Good challenge. It’s true that ZK Chains are doing their own marketing, however we see this as an awareness play across ecosystems. We heavily target increasing mindshare and raising awareness among users and builders to join the Elastic Chain ecosystem - thus also the large focus on marketing. The Elastic Chain ecosystems need support because it’s a competitive environment; if we don’t help builders acquire users, they’ll simply move to ecosystems that do provide that support. ZK Chains also can’t generate revenue by themselves and benefit from a network effect between each other that we must work to enable from the ground up. I would love to discuss your thoughts on where you see the biggest value levers here.

There are examples of this everywhere, where builders move not only because of the tech stack, but also due to the support offered to the builders. This here is the replica of these larger handshake deals on foundation levels, but on a transparent level for smaller sized ecosystems. Guess we all can think of examples of this (without calling out names).

Moreover, it’s less about providing ZK Chains with “free” capital, but more about targeting apps and users with rewards by helping them identify growth programs and valuable onchain interactions, rewarding them only when these interactions occur. This way we prevent unchecked capital allocation, which can lead to higher emissions and inflation. The CRC and our experts evaluate which onchain interactions are valuable using a data-driven approach that assesses how these interactions contribute to top-line KPIs over time. This allows us to iteratively improve capital allocation mechanisms for ZKsync and the broader ecosystem.

(3) On Wave approach / Middleway suggestion:

  • Fully agree with your view here, and this is also a key design decision for us. Based on current feedback, we are considering ways to include delegate and token holder representation in halting mechanisms to guarantee a clear separation between the waves. Additionally, we think its key to make these de-risked waves more transparent and ensure they genuinely function as de-risked mechanisms. Would love to get your granular views on this during a call.

Thanks again and looking forward to catching up!

1 Like
32

Thank you Nick for your explanations. I am with you that given the competition, nature of the industry etc. we have to play the game. I just believe that a metric like MAUs is worth next to nothing cause it can be gamed so easily. Even in the case of consumer applications (which we likely want to be a mass consumer product) I believe there are better metrics (that have real cost, like the mentioned TVL and fees generated). So I would not lean into mechanics that can be easily gamed (MAU, to a certain degree tx/ trading volume). With regards to

I think that will diffuse the dynamic you’re talking about there about judging whether teams themselves have gamed the system.

I hope you are right, but if I consider the dynamics I still believe it will be gamed mostly because it’s so hard to come up with evidence of gaming and accusations based on chance is not too good in a business context where parties know each other.

Also as an idea, I am not a dev, so I am not sure if it’s technically feasible, but according to L2beat zksync the cost per tx are an order of magnitude higher than e.g. Base

  • Base: 0.008 USD
  • zksync Era: 0.07 USD
  • Arbitrum: 0.03 USD
  • OP: 0.05 USD

If zksync managed to attract a breakout consumer app, the tx cost would likely rise substantially. Hence my gut feeling is that something that would really help attract apps is assurance that tx cost stay low to make sure users don’t find alternatives in other, cheaper ecosystems.

zksync offers account abstraction and e.g. in the case of claiming the airdrop was able to offer gas free tx/ claiming and delegation.

Wouldn’t it be great if we could cut tx cost only for successful apps by offering decreased gas cost or even free tx for those apps?
→ zksync USP playing out in the wild
→ users profit directly
→ popular apps profit indirectly, but have certainty with regards to “scaling”
→ sequencer still make money, it’s just coming out of the TA budget (tbd if we could even funnel money back to the TA?)

I think that $ZK incentives are good, but are in the zksync context not the only mechanism and we should think about other ways to give app developers strong assurances that the zk ecosystem is the one they should choose (again: if AA allows the kind of tx cost cuts I describe)

1 Like
33

And to keep the different topics a little separate, a second reply in the context of process and governance:

I think it is fine to bundle conceptual development and technical delivery, but I don’t think it has to be that way. I would even argue that delegates should question bundles more because as stated by @NathanVDH it’s likely that there are either more cost effective implementations or better implementations possible if there’s competition for the implementation. The same applies for the creation of the concept of course.

Generally speaking: If there are bundled proposals I expect those to be stopped more often before they are even voted or latests when voting starts onchain. It’s a good thing if not all proposals pass, independent of stage.

With regards to the council members:
I don’t think all members (in this case and generally) should be voted on. It’s okay if the proposal contains a set of members including reasons why those are the best fit for the council. At the same time I would love to see spots for independent governance representatives that the TA can pick, both in this case, but also in general. If those spots are missing than I expect those proposals to be stopped more often, because it is in the interest of the DAO to have a more direct line of oversight than just the halting mechanism.

2 Likes
35

Hey Benido,

Yes, this is a great idea and can be easily implemented by DApps through integrating a paymaster and sponsoring gas. For over a year, at Zyfi, we’ve been supporting DApps in this area by offering gas grants on ZKsync Era with the support of Matter Labs.

So far, we’ve helped over 30 DApps create gasless experiences, enabling them to sponsor gas or allow their users to pay gas with any token. This has been made possible thanks to ZKsync’s native Account Abstraction (AA), which seamlessly facilitates wallet interactions with paymasters.

We’ve been exploring ways to expand this initiative and have put together a proposal to scale gas grants further.

Our goals are to:

  • Lower gas costs and make transactions more accessible.
  • Showcase the advantages of ZKsync’s native AA to attract more developers and inspire the creation of consumer-focused applications.
  • Support growth in user activity and transaction volumes.

ZKsync’s native AA has so much potential to enhance user experience and bring more attention to the ecosystem. With new ZK chains and DApps launching all the time, it feels like the right moment to take action. We’ve noticed that many developers are still navigating the complexities of integration, and there’s an opportunity to simplify things and highlight the tools ZKsync offers.

We’d love to share more about the proposal and hear your thoughts. Let me know if you’d be open to a chat!

2 Likes
36

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.

:white_check_mark: 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:

  1. 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.

  2. 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.

:bulb: 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_track_button: 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.

7 Likes
37

How will this (and other promises you are making) be enforced if you do not follow through with them? This is my question about many forward-looking statements in your proposal.

Can the DAO sue you? How will this work?

38

This comment is posted on behalf of the Treasure Delegate Council (TDC)

This proposal is well-crafted and insightful, showcasing the authors’ professionalism and deep expertise.

Given how expansive the Catalyst is, we have focused our comment on the following areas.

Yes to VC Matching, No to Exclusivity

We see VC Matching as a smart idea with strong win-win potential and fully support this aspect of the proposal, whether integrated into a broader framework or pursued independently. However, we recognize that requiring exclusivity to ZKsync may pose challenges, as many applications have long-term multi-chain ambitions. Additionally, restricting apps solely to ZKsync may not be in its best interest either, as cross-chain presence can serve as a gateway to attract more users. We advocate for a more flexible approach—one that prioritizes ZKsync as an app’s primary hub and main base of operations rather than enforcing strict exclusivity.

Significant Active User KPIs Preferred to Transaction-Focused KPIs

We believe aligning KPIs with rewards is crucial and we appreciate the positive flywheel this approach can generate. However, we acknowledge the complexities in setting effective KPIs, especially given the diverse performance outcomes across different apps. Our preference remains to anchor rewards on “# of significant active users” rather than “transaction” focused metrics such as TVL, Trading Volume and Fees. We believe this would simplify evaluation and ensure consistent treatment across varied applications. That said, if the proposing team is confident in executing a transaction-KPI-based approach effectively, we are open to supporting their vision.

Is Direct User Incentive a good vehicle for growth?

We generally remain sceptical about the effectiveness of direct user incentive programs. While the risk of apps fraudulently inflating their own metrics is low, tying user incentives directly to on-chain actions introduces challenges in mitigating farming and low-value activity. Even if payments are routed through the app, the risk persists if they ultimately reach users via direct incentives. That said, we appreciate the focus on anti-farming safeguards and some principles of ensuring participants have real skin in the game. We are particularly supportive of incentives being directed toward cross-chain interactions, gas-free transactions, and account abstraction—mechanisms that lower barriers to entry and allocate funds to areas that are inherently resistant to exploitation.

Priority, growth!

We are comfortable with the budget or level of inflation. The L1/L2 landscape is highly competitive, and testing an app-focused incentive program that aligns well with the 2025 Token Priorities seems generative. At this stage, the focus of ZKsync should be on rapid growth, and we feel this proposal supports that.

No RFP, let them cook!

We are pleased with the proposal ideation process and the level of community input solicited by Areta and Factory Labs. We believe that early-stage proposal development is most effective when structured rather than an open-ended free-for-all, and we appreciate the team’s clear communication thus so far.

We have evaluated the advantages of a Request for Proposals (RFP) approach versus engaging a Single Service Provider. RFPs are often considered best practice, promoting competition, enhancing impact, and improving price discovery. We believe this can be particularly valuable for decentralized organizations given their particular challenge in effectively negotiating contracts with service providers. In such cases, RFPs can provide meaningful benefits.

However, these advantages are most applicable to standardized service contracts rather than strategically integrated programs such as this. For that reason, we do not believe an RFP is appropriate for this proposal, as its success depends on the deep strategic involvement and vision of Areta and Factory Labs. Their role is not interchangeable in the way a standard service provider might be.

Additionally, to our knowledge, no RFP was conducted for Ignite, despite OBL’s role being one that could have been handled by other providers—making the call for an RFP in this instance feel inconsistent with past precedent.

For all these reasons, we support this team and their continued progression and leadership of this incentive program.

A 10% administration fee seems right

As mentioned above, compensation setting and negotiation with a decentralized organisation is tricky, and it is hard to independently and accurately evaluate the fairness of the proposed compensation for this program.

Admin/ops spend breaks down as follows:

  • 3.9M - Founder Factory
  • 4.3M - Areta
  • 5M - Marketing
  • 1.155 million ZK Tokens for CRCs operation

Zooming out, we feel a ~10% overall management fee seems reasonable for a program of this scale, and so we are willing to support it. However, we would appreciate more clearly outlined finances for the program. At this size, a more detailed, well-documented, and easily navigable breakdown should be available

Selection vs Election

We believe full elections often serve as poor mechanisms for forming a diverse and merit-based group of individuals. We are comfortable with the proposal author nominating council members directly but are open to a community election for an independent overseer aligned with the updated proposal. Considering the qualifications of the currently nominated individuals, we do not believe a full election process would add any real value to the program’s overall success. This feedback aligns with the updated changes within this proposal.

Eligibility Criteria

The rapidly evolving nature of chains and tokens within the ZKsync ecosystem makes it challenging to set eligibility criteria that will take effect weeks or months from now. At present, our initial research shows only three chains meet the 100M FDV threshold. While it’s possible that more chains will launch, markets will improve, and additional tokens will be released, basing eligibility on speculated token prices may be unwise.

Additionally, some chains operate effectively without a token and may not introduce one in the near future. We belive excluding them solely for lacking a token would be an unnecessary limitation. Finally, we believe the float requirement of 15% could result in an uneven playing field given chains with lower circulating supply often will have a lower effective eligibility threshold, especially when unlocks are spread over an extended period.

We believe a more practical approach would be to lower this requirement, consider circulating market cap instead of FDV, and explore alternative criteria, such as alignment with program KPIs. That said, our preference would be to remove rigid criteria altogether and instead use them as guidelines for council discretion, given the manageable number of chains under review (N = 15) and the relatively recent deployment of most ZK chains.

Regarding dApp eligibility (10M FDV or 5,000 verifiable users), it would be helpful to understand the reasoning, research, and methodology behind these figures. Additionally, there is no clear guidance on when these criteria should be met—whether at the time of approval, as an average over a multi-month period, or another benchmark.

We conducted additional research on eligibility, which we have shared below for other delegates to peruse.

Summary

Metrics (market cap, fully diluted valuation & total value staked) as per 30-01-2025.

On the whole we are happy with the direction of travel for this proposal, and look forward to seeing it progress.

3 Likes