Catalyst: Incentivising Network Growth with Token Programs

[Semo]

I understand that ZKsync should help ZK chains with incentives
But will these ZK chains give some value to $ZK?!
It’s easy to give them $ZK tokens, but in return they should reward ZKsync users/holders
Let’s say Abstract will get some $ZK incentives
But they don’t give a fk about rewarding $ZK community/holders
Then these incentives have no value
I will be clear: ZK chains should allocate some of their tokens to reward ZKsync/$ZK community, by doing this … you are giving great value to ZKsync/$ZK , which will increase the value of $ZK incentives.

[sid_areta]

Hi Cap,

Thanks for the comments! On these one by one:

@cap

Is there a way to prove whether it’s apps themselves farming or individuals/users of that ecosystem… or even coordinated farming between multiple parties?

Good point! In the case of Sybil farming, identifying the exact sources can be challenging. Of course, there is always the possibility that an app - or even a ZK chain - could engage in fraudulent behaviour by faking transactions to inflate activity metrics. This would be considered gross fraudulent activity, as it significantly misleads investors and the chains on which they are deployed, constituting gross misconduct.

We plan to work closely with ZK chains in a guiding capacity on KPIs and growth programs that include robust anti-farming measures. We will also analyse the behaviour of participants in these growth programs to help ensure their legitimacy.

@cap

One comment – putting the responsibility of having only quality/real users on certain dapps creates an ‘attack vector’. Others could inflict damage to the specific dapp by orchestrating bot (or AI agent) farms to ‘game the system’ knowing it will be harmful to them.

That’s a valid point. We assume that current activity levels on ZK Chains likely won’t prompt coordinated takedown attacks by other protocols solely to disrupt participation in the Catalyst program - and have the downside risk limited through our mechanisms. The key is to define KPIs and systems that are difficult to farm, combined with post-mortem analysis of transactions. Since the number of targeted ZK Chain programs is limited, we believe this manual approach will provide the most valuable insights. Even if such scenarios do arise, our monthly reward mechanisms - along with manual reviews and veto rights - significantly limit the risk of collateral damage.

@cap

A definition of what constitutes suspicious activity is desirable. But if/when we define that, then there won’t be a need to have people overseeing that. Requiring people to oversee that brings more operational overhead for you guys and adds more complexity to the whole program.

–

As I said earlier, without even the simplest reputation system built into the mechanics of every program that aims to automate token distributions based on onchain activity/KPIs, would be a struggle.

With the basic onchain reputation system, every user (wallet) who contributes to making the dapp eligible for ZK tokens, is automatically assigned an onchain value based on which ZK tokens distributed to that dapp can be calculated.

Heard you on this one. For the program launch, we will use a reputation system fed by on-chain analysis (traffic lights). For the next iteration, our goal is to reduce overhead and automate most processes. Initially, we aim to be as practical as possible, allowing both us and the system to learn. Every minute spent on analysis helps us optimise the program.

Thanks a lot for your thoughtful feedback again, Cap - it’s much appreciated!

[Bernard_Areta]

Thanks, @Semo, for reviewing the proposal!

That’s very valid feedback. In the proposal call later today and amendments posted in the proposal thread, you’ll see that we’ve tweaked the distribution mechanics to prioritize ZK Chain programs where the ultimate recipients of rewards are users and developers. With this more targeted approach, rather than broad rewards for apps, both the community and developers will have direct participation when generating activity.

You can find more details in the amendments and updated proposal in the proposal thread.

Thanks again for taking the time to read and provide feedback!

[Areta]

Shift to Catalyst Proposal Thread

Hi all,

Thank you for your engagement and all the helpful comments so far, both on and off the forum. As you know, we posted the proposal and presented it during our last community call. We now have another opportunity to discuss any outstanding questions and feedback, and to walk you through the revised mechanisms in today’s collective AMA (details below). To keep the threads organized, we’ve also included links to the proposal below, where we can continue the discussion.

Looking forward to the discussions and to hearing your thoughts!

---

Links

• Official Catalyst Proposal Thread: here
• Catalyst AMA Call 22 Jan - 17:30 CET / 11:30 ET: here

[nanostrategy.eth]

Hello.
I have reviewed your proposal, and it all seems quite logical, especially the idea of rewarding key applications. However, don’t you think that the first priority should be to make the ZK token valuable so that people want to buy and hold it? If the only value of the ZK token is governance voting, it will follow the fate of the ARB token, falling into an endless decline.

I propose to first establish some intrinsic value for the ZK token by:

1. Launching a staking system.
2. Integrating the ZK token into the economy of applications.
3. Implementing ve-tokenomics.
4. Supporting long-term stakers with additional rewards.

[lex_node]

I have to be honest, the proposal is very abstract, vague, jargony and hard to understand. I don’t feel comfortable evaluating it at this stage.

I like the idea of using onchain automation as much as possible but as some have pointed out, concrete metrics are easy to game. This seems to be accounted for with reference to continuing authority of multisigs–but if multisigs are involved there should be considerable detail about designing them properly as they may end up as the ultimate authorities despite the automation the proposal spends most of its time dwelling on.

Hats and MetaLeX are two software stacks/approaches for designing DAO-adjacent multisigs properly. I think substantial detail with these really needs to be baked into the proposal and am happy to assist thinking it through.