Catalyst: Incentivising Network Growth with Token Programs

Token Mechanics
1

Introduction

This post was prepared and published by @drnick in his capacity as a delegate. It introduces a collaborative effort with @Areta under his role as CEO of Factory Labs, Ltd, outlining a new TPP called Catalyst. We are seeking community feedback, consensus, and expressions of interest for participation. A full and detailed proposal will follow.

In my previous post, I discussed how we could leverage the governance structure of ZKsync to build out a path towards a cybernetic governance structure. In short, the idea is that we should use cybernetic principles and “Token Program Proposals” (TPPs), on-chain data, and a stack of mechanisms to route capital directly from the token contracts to where it’s needed most across the Elastic Chain ecosystem.

In this post, we will expand on that approach and propose a program of action that directly targets the application layer. We map out a vision for hyper-efficient capital allocation that can be systematized across the network, removing humans from the loop and structurally applying incentives to create maximally fertile ground for innovation and network growth.

Network Growth

Market Context

ZKsync sits among the leaders in a burgeoning “Ethereum-Aligned” EVM L2 ecosystem. Within this pack, it competes with Polygon, Optimism, and Arbitrum to become the premier ‘chain-of-chain’ ecosystem. Over the next year, a pipeline of ZK Chains will be coming online with a state of the art technical roadmap.

The market context has shifted, and it’s highly likely that market beta will push the entire ecosystem upward for a prolonged period, driven by both a maturing technological landscape and significant policy changes.

For the first time, our industry can showcase more than just raw technology or speculative markets. Scalability breakthroughs and account abstraction have matured to the point where crypto can be presented to the world in a genuinely usable manner.

ZKsync is poised to lead this wave of adoption, with projects like Abstract, Sophon, and Lens providing engaging experiences using Web3 rails.

To truly capitalize on this moment, we need a consistent flow of high-quality, consumer-focused applications launching one after another, increasing in frequency across the Elastic Chain.

It’s All About Network Effects

The classic notion of network effects says a network’s value rises quadratically with its number of participants. This was true in the telephone era, when each node corresponded to a single individual. Today, nodes might be users with hundreds of wallets, industrial Sybil farms, smart contracts, automated agents, or airdrop farmers.

In crypto, not all transactions are the same. Hidden in the noise, there are real humans performing high-engagement transactions, genuinely using applications for meaningful activities. That is where real network effects arise—people discovering tangible value and telling their friends.

In modern cryptonetworks Metcalfe’s Law has additional factors: network clustering (DAOs and communities can drastically accelerate network effects), transaction quality, and, in the Elastic Chain’s context, the significance of linking different network hubs (ZK Chains). Transactions from the application layer will accelerate network effects more than others.

The Missing Application Layer

Demonstrably, the market as it’s currently structured doesn’t incentivise much innovation at the application layer. It’s often been more profitable (+EV) to spin up new blockchains rather funding apps. As a result, we have ample blockspace but not enough meaningful use cases filling it.

This gap is also a massive opportunity. As shown by projects like Polymarket and pump.fun, consumer-facing dApps can generate tremendous value and hype simply by delivering a non-payments, non-infrastructural experiences that leverage crypto’s unique properties. These apps highlighted that the consumer layer is where significant value lies. Not only do they bring new users, but they also produce fees and revenue—driving a genuine network economy.

In short, ZKsync has the potential to become a leader in the consumer space, spurring high-value, high-engagement transactions that accelerate network effects and network value.

Towards Network Economics Design

The truth is, most protocols haven’t found the optimal mechanisms to leverage their often formidable token treasuries for network growth. Many have spent heavily without demonstrable impact, while others sit on hundreds of millions or billions in token value and do nothing.

The promise of token programs is to establish mechanisms that direct capital toward the most impactful areas within an expanding network of chains—automatically and efficiently—to achieve real value accrual. If you consider how ecosystems like ZKsync could evolve in coming years, they could reach a kind of nation-state complexity, with hundreds or even thousands of interlinked network economies channeling liquidity through ZKsync Era as a central liquidity hub.

To govern economies on that scale, we need to think in terms of network economics design, akin to how real-world countries craft tax incentives or enterprise zones to attract businesses. Just as nations use policy to encourage investors or entrepreneurs to relocate and build, we can use Token Programme Proposals to send structural economic signals to developers and users worldwide that ZKsync is the place for consumer-facing apps.

Structural Incentives

A key question is how to architect incentive systems that scale to vast and complex network topologies. Traditional grant frameworks—so far, heavily inspired by real-world institutions—simply don’t scale well for rapid ecosystem-level growth. Instead, we can think more like nation-states, setting robust incentives, and supportive economic conditions for projects that choose to build on ZKsync.

This calls for a more macroeconomic perspective, where structural carefully calibrated incentives encourage projects to stay, build, and expand. By adopting this mindset, we can create an economic program that strongly signals to global builders: ZKsync is the destination for consumer-app innovation.

Hyper Efficient Capital Allocation

Although cryptonetworks could scale akin to nation-states, it doesn’t rely on real-world government infrastructure. Instead, we can user ZKsync and its on-chain capabilities to directly route capital from the Token Assembly to the appropriate targets. Once these pipelines are established, we can dial in structural incentives that spur “accelerative” network expansion—without the overhead of manually run grants.

How to Do It - A New TPP: Catalyst

Factory Labs and Areta have spent three months designing Catalyst, a comprehensive economic program poised to make ZKsync a leader in the consumer layer. Our approach to this is called Catalyst.

It has the following design principles:

Data Aggregation and KPI Oracles

The end goal is to boost network growth driven by high-engagement transactions. That means we need thorough insight into transaction types across the Elastic Chain. By aggregating data from individual dApps (user retention, bridging volumes, etc.) and network-level metrics (TVL, overall transaction counts), we can define KPI oracles. These oracles automatically unlock token flows when certain thresholds are reached, such as generating new capped minters, distributing tokens to active users, or funding DAOs and foundations.

Mechanism Governance

To enable these structures to evolve, we must go beyond the idea of merely putting real-world council models on-chain. Instead, governors should govern smart contracts directly. In practice, this involves “mechanism dialing and balancing,” where governance steps in at defined intervals to tweak parameters based on on-chain data. A single decision moment can trigger cascading value creation, sparing us from committees approving every minor change.

Risk Management

Because these systems may involve substantial token flows, risk management is critical. We can build in emergency pause functions, kill switches, and multi-sig oversight to halt or re-evaluate incentives if manipulation or oracle failure occurs. Time-delayed execution can also allow the community to veto suspicious actions, minimizing manual governance while still safeguarding the treasury from exploitation.

Automation Waves

Ongoing innovations, like the capped minter framework and evolving council/role designs, can integrate with mechanized decision-making. Progressive automation unfolds in sequential “waves,” each reflection point nudging humans further out of the loop and shifting more processes to KPI-triggered on-chain actions. Over time, automated agents will sit at the center, directing information flows, activating on-chain payments, and adapting based on historical human decisions.

And is structured as follows:

  1. What It Catalyst?

    Catalyst is a Token Program Proposal (TPP) specifically tailored to incentivize and grow consumer-facing apps on ZKsync-powered chains. It aligns rewards with on-chain performance, ensuring that only apps delivering real engagement and adoption unlock further tokens.

  2. Catalyst Aims To

    • Support Elastic Apps with Capital and Distribution.
    • Support ZK Chains by Strengthening their Business Development Muscle.
    • Accelerate the Adoption of Unique ZKsync Features, such as ZKsync SSO, Interoperability, and Privacy.

  3. How It Operates

    • An Initial Allocation: Following the application process, nominated apps are given an initial allocation to manage to boost their growth how they see fit.
    • A Milestone-Based Distribution: Catalyst uses verifiable KPIs—like active users, transaction volume, or cross-chain synergies—to trigger automatic token unlocks for the remaining allocation per app.
    • A Performance-Based Distribution: Once apps have hit their milestones they will compete for a performance distribution that compares their performance KPIs across the whole Elastic Chain ecosystem.
    • Core Oversight & Automation: An oversight committee sets guardrails, while smart contracts release funds without needing repeated governance approvals.
    • Progressive Scalability: Over time, Catalyst will leverage automation principles to reduce manual overhead and increase efficiency, lowering the cost of capital distribution and increasing effective spend dramatically.

  4. How It Realizes the Vision Outlined in This Post

    • Structural Market Incentives: Catalyst embodies the nation-state-like incentives concept by systematically channeling capital to apps that drive genuine network effects.
    • Data-Driven, Evidence-Based Spend: Successful apps automatically receive funding upon meeting defined benchmarks, preventing wasted resources on underperforming initiatives.
    • Consumer-Layer Focus: By emphasizing user-facing dApps, Catalyst ensures that real people experience the tangible benefits of ZKsync’s scalability and account abstraction.

Summary

Perhaps the biggest opportunity that crypto has ever presented lies directly in front of us. The industry is finally infra-structurally prepared to deliver consumer experiences to a global market, yet the current market structure doesn’t naturally encourage true innovation at the application layer. ZKSync, with its technological capabilities and market advantage, is perfectly positioned to capitalize on this market dislocation.

By creating structural application-layer incentives at Elastic Chain scale, we can foster sustained network growth through high-engagement transactions. Through allocating capital to promising dApps as they emerge—and scaling support proportionally to their performance—we establish a powerful economic signal: building consumer apps on the Elastic Chain is not only feasible but highly rewarding.

:white_check_mark: ZK Chains / Apps - Please signal your interest in Catalyst:

This expression of interest is a non-binding step to ensure you stay informed about program progress and upcoming launches. We may reach out to gather your feedback on program elements prior to launch.

16 Likes
2

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?

4 Likes
3

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.

1 Like
4

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.

3 Likes
5

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.

4 Likes
6

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.

3 Likes
7

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)

3 Likes
8

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.

3 Likes
9

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:

  • Emphasis on Onchain Data: Adopting novel KPI oracles is a welcome addition to this program and represents an advancement in onchain and metric-driven grants. Something that has been explored perhaps most prominently at Optimism (RPGF and KPI-Based Partnerships) and Blast Gold. The automation of token flows using oracles is a novel operational improvement that is worth exploring.
  • Optimistic Funding: Risk management will play a critical role; we believe Areta has done significant work safeguarding these grants with multi-sig oversight to pause, delay, and veto them once they are launched. A committee that can evaluate grantees and set sophisticated and custom KPIs for grantees will be critical.

Most importantly, we believe that the focus on building consumer apps on the Elastic Network is important and deserves attention.

3 Likes
10

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

2 Likes
11

I really enjoyed reading about this program you’re proposing @drnick!

I really like this! :fist:

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. :saluting_face:

2 Likes
12

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.

3 Likes
13

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.

3 Likes
14

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.

3 Likes
15

The Catalyst program will definitely allow Abstract and ZK Nation to accelerate the onboarding of global brands and millions of users onchain!!

4 Likes
16

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:

  • Identify a list of 10-20 of the top VCs, accelerators, and crowd-fund platforms that specialize in consumer applications
  • For every Seed, Pre-Seed, or Series A startup that they fund and commits to launch exclusively on the Elastic Network, Catalyst matches the investment up to a certain % (details tbd)
  • In return take either nothing or only a small fraction of future tokens at time of TGE. The latter part I think would take some thinking through and we could possibly leverage the Borg model to create an entity that just holds and executes on token warrants. The tokens from these investments could then be streamed to ZK stakers. We would then also most likely want the chain that is receiving this benefit to also probably commit something as an investment from themselves too so they also have skin in the game

Upside:

  • The program will reach 99% of the best founders, giving them strong incentives to at least consider launching on the elastic network.
  • It will turn the top VCs into ZK advocates.
  • Due diligence is delegated to the world’s top experts. The program is completely deterministic, no judgement required from the managing committee
  • The program is diversified and acts as an index fund: even if 1% of the startups become the next big thing, it will be huge for ZK
  • Strong marketing story to catch visibility and own a mindshare category

Launchpad Idea:

  • we could change the grant to a very favourable investment: for example we would get only [10%/20%] of the Tokens that the VC gets
  • these tokens, as well as the token-match from the ZK Chains which are not Era are streamed (or airdropped) to ZK token stakers
  • this replicates the UX of Binance Launchpool:
    • you stake ZK and get regular rewards streamed in Projects and ZK Chain tokens
    • these are streamed so you are incentivised to stay for long
  • is it good for stakeholders?
    • projects: they can increase their fund raise but only costs them a relatively small token allocation relative to funds raised
    • VCs: their investment in de-risked (we will need to assess if this creates issues with crowding)
    • ZK Chains: they get new projects launching and only pay a small percentage of the costs
    • Stakers: they get yield and engagement and participate to the growth of the ecosystem
    • This will also create a positive narrative for the token

Marketing:

  • There should also be a budget within this program for marketing. We should make sure that apps that get selected in this program are given ample amplification along with the program itself and all onchain success is properly given exposure
  • Time and time again we hear from the best founders that a key drive for their decision is whether an ecosystem is able to give them proper exposure and marketing support
  • Other ecosystems can copy this program so it’s key that we are first movers, come up with a catchy name and own the category for these programs - just like how OP own “Publig Goods Funding (PGF)”
4 Likes
17

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.

What I Like:

  • Initial Allocations: Providing approved apps with an initial allocation upfront sends a strong signal that ZKsync is open for business and ready to support innovation.
  • Milestone Payments to Apps: This looks likely to reduce the risk of Sybil attacks since there is no direct incentive flow to end users. Instead, funds can be utilized by the apps for initiatives like gas-less account abstractions, growth marketing, tournaments and prizes as they best see fit to drive growth. Empowering apps to make allocation decisions looks likely to improve the return on capital, as apps know best. However, I’d be interested to know if there will be any restrictions on how apps can use their allocated milestone payments.

Considerations:

  • Selection Process: As @Omar mentioned, I’d like to see a structured approach to approval/selection, where apps must meet predefined criteria or thresholds to be eligible. This would help avoid perceptions of politics in the selection process.
  • Design Simplicity: How can the program remain sufficiently simple given the diversity of ways apps might trigger “high-engagement transactions”?.
  • Gas Rebate: We considered a gas-rebate program as an effective method to divert funds to applications seeing significant volume. However, noting that with such low gas fees the “juice might not be worth the squeeze”
  • High-Value Users vs. Transactions: Instead of focusing metrics solely on “high-value transactions,” consider shifting the focus to “high-value users. Apps could be rewarded based on their ability to attract and retain “high value users”, with rewards potentially divided across several tiers based on their degree of activity across the ZKsync ecosystem.
  • Incentives for Cross-App Collaboration: Introducing a multiplier reward for users active across multiple applications could encourage cross-pollination and collaboration among apps.

I am excited to see work continue on this initiative and to understand more of the specifics on both app and chain incentives.

5 Likes
18

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.

5 Likes
19

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:

  • If Apps use fake activity to hit KPIs, this is to the detriment of the ZK Chains that they are building on.
  • The big difference between airdrop farming is that this is not anonymous, and it therefore exposes them to reputation risk and the possibility of not receiving long-term support from the ZK Chain (and the wider ZK ecosystem).
  • Everything is public. We will look into the transactions and how KPIs are achieved. If there is suspicious activity, we will publicly highlight it on the website dashboard and inform the DAO / ZK Chains.
  • This will result in (1) funds not being paid out due to the veto right of the review committee, and (2) reputational damage for you as an app in the community and on the ZK Chain that is your home - something you definitely don’t want.

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.

2 Likes
20

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.