Great post. I am super glad we will see more incentive programs for builders on ZK.
I am interested to learn what are the next steps here? Since the budget or size of grants, KPIs, grant criteria, etc. are not mentioned at all, when can we expect to learn more about it? Is there a timeline for when the final proposal will be posted?
I somewhat agree with the general framing of the challenge (not sure we need to focus already on managing a large and complex economy and focusing on the scalability of programs when zkSync is still small but anyhow, that’s not the critical concern).
My critical concern is that the proposed design seems very prone to increase farming and other forms of gaming the system or creating unsustainable growth through vanity metrics. I mention this as in essence this creates a too similar mechanism to Arbitrum STIP and LTIP programs where each protocol defined how they’d use the incentives and this generally led to increases in the metrics but the increase largely disappeared once the incentive dried up. The key difference of giving more funds based on milestones in an automated manner does not solve the above concern IMO but by automating it could make it more severe than with Arbitrum incentive programs.
The merit I do see is as a research initiative (enabling experimentation) and something that might be discovered could be impactful in advancing our understanding of what type of incentivised growth strategies are effective (a useful but perhaps not top priority goal?). If the proposal was reframed as such discovery/research initative, I could be supportive with the following caveat: STIP/LTIP was largely unable to provide learnings because analysing the variety of mechanisms used was prohibitively expensive and I’m not sure how the setup here would avoid that pitfall.
Thanks! Yes this is really just a “teaser” for the proposal, we’re just finalising the details (on pretty much those points) and will publish the full thing and run a dedicated session on the delegate calls to go through it with the assembly. Look forward to sharing it with you.
It’s not going to be small for long, there are good number of ZKChains coming online imminently – a number of which are explicitly consumer focussed. Also, this kind of structural system takes time to build and iterate into. It’s really about building a token programme that the token assembly can capitalise in an ongoing fashion. It’s not designed to be a one shot project but the development of a structural incentive programme that can be utilised in an ongoing fashion to support a market segment that has largely been neglected. And in any case, even in its early iterations it gets capital quickly to application teams in their early stages, which are largely radically underfunded in the current context.
We want the answer to the question “where should I build my app?” to be ZKSync, because it’s where apps are desirable and are structurally supported.
Regarding the gaming aspect. We of course recognise this. I’ve studied the Sybil problem for years and understand how mechanisms can be gamed. The entire point of this is to build a dynamic and evolutionary system that can evolve as mechanisms ‘play out’. Airdrops for example, worked brilliantly for a period of time, before the industrial sybils moved in and captured the basic mechanism. Neverthless, airdrops have been, and remain, a major dynamic in the space and have shown that they can evolve and work incredibly effectively (see, hyperliquid).
As @dennisonbertram.eth said on the delegate call, there are metrics that have financial skin in the game where gaming is far less of a problem, because there is an implied cost. These are the KPIs we would focus on.
Research implies lack of action. Fair enough in a bear market, but this is the time for accelerative growth. This is a hyper competitive landscape and there is a very likely a limited time window to make maximal impact. User numbers drop off dramatically in a bear market. We need to be making the best use of the context where rising market beta brings in a broader user base. That time is now and frankly waiting until the point where no one wants network inflation to actually do this would be a bad idea.
Additionally, each app will have their own approach for how they engage their users onchain and the effectiveness of any incentive scheme will be contextual and variable across the apps. The only way to know will be to do it and through practice we will discover KPIs that work and one’s that don’t and that’s what we’re designing the system to do very similar to how OBL are iterating ignite. Also, the programme will of course have ample opportunity wind out of the approach if it is proving to be obviously ineffective in the same manner that ignite is doing.
Unlike STIP the programme itself manages and approves which KPIs are utilised and tracked via the KPI Oracle system as part of the onboarding process, with clear waypoints for evolving them as they stop working, or become obviously good metrics we want to incentivise. This approach incorporates the evolutionary governance system that that one was missing. But on this point, can we please stop using STIP/LTIP as some benchmark for whether incentive schemes work or not, it was a terribly unsophisticated programme from end-to-end. Understandable at the time, but it is really no indicator of whether another (very different) approach will work.
Hello folks,
I am supportive of this proposal. I think it’s fair to say that with Ignite we have created the conditions for strong support for DeFi. This is excellent, but DeFi is probably not strong enough a differentiator to many other L2s.
There is furthermore a tendency to neglect consumer dApps, Social dApps, etc., which I think is part of Crypto’s wider self-limiting in recent times.
As a cypherpunk-oriented chain we really should be encouraging a sovereign tech mindset that expands beyond finance.
I also think this would benefit us culturally since Consumer Crypto folks tend to be among the more interesting ones, helping us to cultivate a little bit of emergent culture, which I think we somewhat lack at the moment beyond core believers.
Hey @drnick
It’s nice to see discussion around the application layer and research-based growth incentive systems!
At @CryptoMazeApp , we’ve spent 2+ years on ZKSync, building around consumer/gaming & entertainment.
We have also experimented with different reward/incentive designs.
For example, we have built the first Gassless on-chain game-roulette on ZK with VRF randomness that rewards players of the game, distributing different NFTs, coins, ZK assets, and merch (you name it). A part of the bigger vision for seamless onboarding of new people to web3 … think this + SSO …
Or a merit-based Discord system for retroactively rewarding meaningful participation.
I’d be happy to share learnings, and thoughts and participate in the discussion.
At the moment we are working on a viral AI consumer app (aimed at onboarding normie users to web3/zk) and a live multiplayer gaming experience around Moody Madness game.
Thanks (also gave you a follow on Twitter)
Thank you for this initiative.
I am curious about the details of this, so looking forward to the following publishings. It’s going to be interesting to see how you want to deal with the gaming/ farming issues, which tbh is likely my biggest concern after reading your proposal.
Just one though I would like to add which is connected to
This calls for a more macroeconomic perspective, where structural carefully calibrated incentives encourage projects to stay, build, and expand.
This immediately made me think about terms like “tax (cuts)”, “rate (cuts)”, “subsidies” etc. so basically a lof of the stuff nation states can influence to create growth.
I would highly appreciate if you could “translate” the different ideas/ mechanisms of the Catalyst program into real world examples.
Gauntlet has peripherally discussed this program and shares the belief that grant programs for new chains represent an important value-add for partners building on the Elastic Network and simultaneously serves an important BD function in attracting builders that otherwise might be attracted to competitors in the L2 space. The “signal” to the market that the ZK Nation aggressively supports Elastic Network builders should not be understated. A couple of aspects here are worth noting:
Most importantly, we believe that the focus on building consumer apps on the Elastic Network is important and deserves attention.
I think it’s a good idea/proposal. As I mentioned in the call on Tuesday, one of the ways to prevent farming would be to use a reputation score e.g. OpenRank. Of course, as @drnick noted, farming/gaming the system cannot be fully prevented, but such reputation score mechanism can at least lower the impact of bad actors (sybil attackers).
I really enjoyed reading about this program you’re proposing @drnick!
I really like this! 
So if I understand this correctly, we’ll have a KPI Oracles that will serve as predefined ‘goals’ that once hit will perform certain actions such as unlocking/minting/releasing/transferring/etc. tokens to someone. Theoretically speaking, I like this design and the thinking behind it. I wonder if this can be built to be standardized in a way that is easily reusable by other protocols and apps. Because this is one of the missing pieces to build an autonomous self-executing TPP.
One hiccup I see is that this TPP can build KPI-based token flows based on app success metrics in general. I wonder if we’ll need a variety of KPI oracles for different apps because different apps in different industries measure different things as indicators of their success. Maybe I’m overthinking it here; I’m just sharing my thoughts.
One more thing – it will be difficult to put this to practice without some basic form of onchain reputation to safeguard against gaming the system. Building Sybil-resistant mechanisms and automating them as planned here is a major major feat that I see as something that needs to be addressed. Even the simplest Sybil reputation design like the age of the wallet, tx count, tx volume, etc. would go a long way. Definitely looking forward to seeing what you have planned for this in the final version of the proposal.
–
Contrarian take
I agree with and support 99% of this program. However, I want to add a contrarian take because these can be generally used as valuable feedback – this proposal is a combination of some generally difficult things to execute (such as the entire cycle of grant management, from application to performance tracking) and some generally unknown and untested things such as Oracle KPIs, self-executing KPI-based contract mechanics for token flows, etc. that need a lot of work and a lot of iteration. I worry that it can become burdensome and I would encourage people behind it to think in terms of minimum viable ‘anyConcept’ when building it and start from something simple.
Once again, I support the proposal and I’m glad to see you guys focusing on network growth by incentivizing builders to build on the application layer, especially with what we all expect 2025 to be – a pivotal year for (consumer) crypto. 
Great to see the vision of cybernetic governance be translated into reality.
My one callout is that the program is very broad and catch-all. How does it differentiate from Ignite? Are there specific focus areas or initial KPI oracles you have planned?
What I’m trying to say is that I would love a more tangible roadmap.
This is great, lots of good thinking and couldn’t imagine better actors than you and @Areta here.
Excited for what you’re planning to ship.
Want to echo many of the points above. We don’t see any real concerns here and think the team behind this is both strong and incredibly qualified to execute this at a high level.
Very supportive of this initiative.
Particularly a fan of the focus on KPI-triggered on-chain actions for automation and transparency, as well as establishing a system that will be compatible with automated agents in the long-run.
Can’t wait to see the full proposal.
The Catalyst program will definitely allow Abstract and ZK Nation to accelerate the onboarding of global brands and millions of users onchain!!
I’d like to start by thanking the team for all the work and thinking done here on this proposal. I think this is a great step forward and something we should definitely experiment with to better understand incentive mechanics and design that lead to long term growth and attract the best developers to come and build their apps on ZKsync. I also think that thinking at the macro level and working directly with the different L2s on ZKsync is the right level to work on rather than going directly to the apps themselves. It allows for more experimentation and helps with decentralization and autonomy.
With that said, I think there is also room to additional room to experiment with the process of app selection itself. In this program it is up to the chains to decide which app to nominate which is great. With 20+ chains it’ll lead to potentially interesting and differing strategies and results when it comes to which apps get selected as each chain optimizes for their own respective GTM. However, I think it still leads to potential for gaming and adverse selection and leaves too much overhead for the selection committee which might not have all the necessary capabilities for due diligence or a keen view of the broader crypto economy and emerging trends. Our goal should be to minimize downside risk of investing in bad apps while having more shots on goals to increase the probability that some of these apps become breakout successes.
On this end I think it might be beneficial to also consider a separate, or additional, selection criteria. One that removes the burden of selection from the program and relies instead on the power of the investment markets and allocators to pick the best potential builders and incentivizing them to build on any of the chains within the Elastic Network.
In summary here is a potential idea. This can be done in parallel to the existing selection criteria and KPI based payouts.
Delegate the app selection decision-making to VCs, accelerators, and crowd funding platforms such as Echo:
Upside:
Launchpad Idea:
Marketing:
There is so much to appreciate about this proposal. I want to extend my thanks to Areta and Nick for their concise, thoughtful, and eloquent piece of work.
The Treasure Delegate Council (TDC) has been reflecting deeply on token incentive programs. We would like to see the Token Assembly implement a program that is clean, simple and straightforward, as true inspiration often lies in simplicity.
I am excited to see work continue on this initiative and to understand more of the specifics on both app and chain incentives.
Thanks so much for the support and comments, it’s great to see major delegates (such as @PGov @rspa_StableLab and @Gauntlet) and ZKChains (Sophon, Abstract, Treasure) here. I really appreciate the thoughtful engagement.
We will be releasing the full proposal very soon and will be discussing the full programme in the Proposal Review call later today.
@cap raises an excellent point here about the nature of the KPIs and their necessary individuality to certain products, particularly at the consumer end of the spectrum where apps will have a large variety of onchain outcomes that best articulate growth (as opposed to DeFi for example, which is heavily TVL driven). This is why we (Factory Labs), will be working with the app teams directly to understand their contracts and build bespoke mechanisms with the teams that we think will best capture the growth of their apps. As the programme progresses, we want to find ways of making these KPIs comparable across apps and we’re looking to build out a taxonomy of metrics to facilitate that standardisation over time.
You’re right that this is both a technical challenge and operational challenge, which is why it’s a partnership between us (Factory Labs) and @Areta who are specialists in programme management like this in a Web3 context. This will allow us to fully concentrate on building out and deploying the technical architecture, whilst Areta manage the programme and relationships across all of the stakeholders. We have been working on this for a few months together now and it’s been fantastically productive. In fact generally, I would advise teams thinking about similar TPPs to forge similar partnerships.
Thanks @Joe_McKenzie excellent comments. This sums it up perfectly. Our goal is to move towards (as far as possible) the autonomous budgeting paradigm, where teams have as much control as possible to spend the capital as they see fit. This is largely to accommodate the fact that what teams actually need to spend money on at the frontier of decentralised app development is highly emergent and unknown territory and we don’t want to limit responsive action as much as possible. Having said that, we want the teams to spend it on “growth”, with the kinds of spend you suggest being perfect examples of what we’d like to see. So the programme will monitor spend from the teams as part of the reflective review and reporting cycles and if necessary add more conditions onto the spend if we feel it would improve programme spend efficacy.
Again, excellent points. As far as possible we want to empower ZKChain teams to select the applications from their ecosystems that they think would benefit the most from Catalyst the most, however there is a decision making structure that will sense-check this process to make sure it is objective as possible and we will be including VC expertise in there to facilitate this.
Regarding programme complexity, our goal is to use automation to drive towards simplicity. To remove humans from the loop the system necessarily needs to trend towards extreme simplicity over time. There will be diversity in data sources from the app contracts, but ultimately this needs to collapse down to a distribution mechanism that needs to be simple, automated and transparent. Very much the point of this is to discover mechanisms that gets capital to where its needed most in the most efficient manner possible and you don’t get hyper-efficiency with complexity. So completely onboard with your point.
I think your point on “high value users” is great and that kind of user-centric philosophy is exactly what we need in the ecosystem. I think you raise an excellent point about user retention and I think that’s exactly the kind of metric that would be an excellent KPI for the programme to track. I picked transactions as a focus to recognise the challenges of tracking pseudonymous accounts, but you are right it is users that really matter.
Finally, cross-app collaboration will be in! We want to build mechanisms that encourage the activitiy we want to see from with the Elastic app ecosystem and cross-app and cross-ZKChain interop transactions will be highly desirable and something we should be building into the mechanisms to encourage.
Hi Omar,
First of all thanks for the detailed response and taking the time to digest. Appreciate your support and help in iterating this, especially given that you have a deep view on the Elastic Chain ecosystem and its needs.
On: Working directly with the ZK Chains
We agree with the approach of working directly with the ZK Chains and giving them autonomy to allocate capital effectively. This is a key mechanism of Catalyst - we want to build on the knowledge that sits within the ecosystem rather than centralizing decision-making power in an external committee — which often does not produce ideal allocation outcomes. We’ll work closely with the ZK Chains to collaborate on bringing the best of both worlds into the system (focus on ecosystem growth, deep knowledge of the elastic app ecosystem, and easier information exchange).
On: Potential for gaming the system
This idea obviously comes a lot from all of our experiences of seeing airdrops being farmed. But in reality, it is not that big of a problem for the program. Why?
In essence, what do we mean when we talk about gaming the system? Apps farm with fake activity to hit KPIs, i.e., apps are abusing the system and trust of ZK Chains.
In our context, the problem is not that big in itself due to program dynamics. Let me explain:
On: Optimizing decision-making (minimize downside risk of investing in bad apps, increase probability of breakout successes)
We agree and hear you on that. You’ll see in the proposal, that we have 3 seats on the review committee allocated to top consumer VCs with deep market knowledge and the ability to evaluate emerging trends both within and beyond the ZK ecosystem. Ultimately, we need experts whose decisions can increase the likelihood of selecting winning applications for the program and rewarding breakout successes. We have developed an initial list of those consumer VCs and would love to float it with you.
A secondary effect of this setup is bringing these selected VCs closer to the ecosystem, which also increases the visibility of participating apps for potential VC funding.
On: VC capital matching mechanism
We believe that leveraging top VCs as a funnel for the Elastic Chain ecosystem is a great idea worth exploring. We do see the upside around bringing top VCs closer to the ecosystem, increasing our exposure to expert-vetted ventures, increasing the attractiveness of the Elastic Chain ecosystem for builders, and using this as a valuable marketing element. We’ve reached out to select VCs to test this and discuss potential structures (e.g., matching amounts, exclusivity considerations).
We would like to include it in the proposal with a dedicated VC matching allocation. Ultimately, it is a risk-free bet because the capped minter’s funds will only be spent if VCs bring applications that build exclusively on ZK Chains to the ecosystem. If they do not, it will act as a “free experiment” for the community and at least boost awareness of the ecosystem.
On: Receiving a token allocation (as part of the matching mechanism) and launchpad / token investment Idea
We love the idea and do think it is worth exploring. That being said, probably one to check outside of the remits of this program. Main blocker here is that there is currently no legal framework in place for this, as the Token Assembly does not have a mandate (yet) to engage in equity swaps or investments. For the time being these financial transactions are best handled through direct negotiations with the Foundation. Setting up these structures is a super exciting topic for us as Areta, i.e., “how do we enable a DAO to hold equity?”. We will message Rafa to discuss the potential impact and explore it further.
On: Need for marketing budget
Aligned. We see distribution as a major challenge for builders in the Elastic Chain ecosystem. To address this, we plan to run dedicated awareness campaigns (through partners or in-house), collaborate with partners to create a program website as an additional discovery channel, and build further distribution channels for top apps in alignment with the ZK Chain’s local strategy. Any apps participating in the program will also be automatically considered for inclusion on the canonical ecosystem page, as well as for general ZKsync marketing.
Next steps
Next to posting the proposal, where we’ll have the spots for Consumer VCs included, we are designing a VC matching allocation mechanic and are testing the viability internally and with consumer VCs. Similarly, we are talking to Rafa on the future-oriented topics.
Thanks again for this contribution - we’ll reach out to discuss some of the details.
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?
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.
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.
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.