[TPP-001] ZKsync Ignite Program (the "Ignite Program")

Token Mechanics Active TPPs
63

9 months is too long can it be reduced to 3-6 months?

64

TL:DR : Not healthy in the long term, I am gonna vote NO

Hi !!! First of all thank, you for such a detailed and well thought proposal, really appreciate the amount of work and wisdom poured in it.

I am a very small delegate, which represents nearly 600k tokens from 847 holders, but Zksync is the only network where I am a delegate. Sorry to be (one of) the dissenting voices but I do not consider this proposal to be driving organise / healthy growth that provides long term value to the network.

While the zkSync Ignite Program aims to boost short-term liquidity by deploying large token subsidies, such approaches tend to create unsustainable growth patterns. Once the 9-month incentive period ends, the liquidity might plummet, leaving the network in a precarious position.

This approach can artificially inflate the total value locked (TVL) and token price, but without organic growth or genuine engagement from users, zkSync risks creating a dependency on such incentives.

Subsidizing liquidity provision is akin to competing on price by offering an artificial discount. While this may attract opportunistic actors in the short term, it fails to address the core issue of long-term sustainability. This approach doesn’t strengthen zkSync’s fundamental value proposition, nor does it build a genuine commitment from its users. If we consider zkSync as a network state, this would be like paying citizens to join, rather than fostering an intrinsic value that attracts them to join (and stay) voluntarily.

This model might appeal to stakeholders seeking short-term gains but risks undermining the long-term health and autonomy of zkSync. A more sustainable approach would be to focus on bolstering zkSync’s value in a way that naturally attracts participation, rather than relying on temporary subsidies to artificially increase the TVL and token price.

The pattern of airdrops and liquidity incentives leading to short-term engagement followed by sharp declines is well-documented across several networks.

The systematic decrease in activity on networks after the initial airdrop distribution and liquidity programs show us that liquidity incentives, while effective in the short term, are not sustainable for long-term network health. This is why simply incentivising liquidity can inflate metrics like TVL but doesn’t create the strong, lasting engagement needed for sustainable growth.

In opposition, I am a firm believer in targeting the ecosystem development for creating long term value, which while might not be interesting to short term speculative $ZK holders is definitely the most appropriate option for holders really committed to zksync its long term value and sustainability.

Support for Protocol Development:

Networks thrive through protocols that offer value to users, creating the foundation for network effects. Instead of offering such a massive amount of tokens for temporary liquidity incentives, zkSync could focus its treasury on supporting competent teams that develop / migrate innovative, useful protocols on its platform.

By helping these protocols gain traction, they can organically distribute their own tokens to their user communities.

This approach aligns long-term incentives by empowering protocols to develop real value within the network. As these protocols grow and gain users, they naturally share that value with end users through token distribution, allowing for a more direct and sustainable value flow. The main focus should be on fostering an ecosystem where meaningful services create organic demand and sustainable growth.

  1. Protocol Incubation Grants: Allocate treasury funds to identify and support promising protocol teams, particularly those solving unique challenges or creating value that draws in long-term users.
  2. Infrastructure and Tools: zkSync could provide shared resources like developer tools, security audits, or integration support to make it easier for protocols to build robust and scalable solutions.
  3. Community-led Growth: Protocols should be encouraged to grow their own communities. By supporting the creation of organic user bases, zkSync’s network effects would become much more sustainable.
  4. Aligning Incentives: As protocols develop, they distribute their tokens in a natural, merit-based manner to their users, incentivizing real engagement and long-term participation. This avoids artificially inflating network metrics like TVL and focuses on genuine network value.

This strategy would ensure zkSync’s treasury supports protocols that are key to long-term ecosystem growth, and empowers both protocols and users to create a more sustainable network where value flows naturally.

I know that incentivizing users and protocols is not mutually exclusive and I am sure that proposals aligned with value creation via protocols are in the way, but I don’t want ZKsync to jump in the train of the " Deploy liquidity here, you will receive some tokens" as it is imho not only not beneficial but harmful for the network.

I am conscious that I am on the unpopular side , but I do not care , even being a small delegate I take very seriously my activity as delegator , and want the best for the long term vision of ZKsync.

If you agree with my thesis of long term value creation vs short terms artificial value creation delegate to me and your voice will be represented in the vote .

8 Likes
65

IMHO admin costs too high, should be cut.

1 Like
66

This rocks! We’re early, right?

67

so how do we vote for this proposal?

68

Probably a bit excessive

1 Like
69

Ummmmm, to increase liquidity for DeFi is great

70

Major steps!
Keep building :+1:
Can I vote if my token are already delegated?
I guess not

1 Like
71

lfg guys good job keep it up :heart_eyes:

1 Like
72

This proposal is well written :rocket:

73

I love this proposal, users come first and this is a great way to show it! Let us vote!

74

Please do I need to delegate or stake for the upcoming proposal?
If I’m to stake my ZK to be eligible to vote where can I do that please :pray:t3:

75

good its great for zk community

76

I don’t like it, incentives are important but it is essential to give ZK a utility FIRST. Users (Elastic Chain) will dump it. It is not good for the value of ZK.

If Elastic Chains would pass on a portion of the fees generated to ZK holders, this incentive proposal would be a good one.

1 Like
79

have you considered allocating some portion of the funds retrospectively?

people who have not sold their airdrop and are token holders are valuable to the community. Alex G. also wrote about this earlier.

if some part of the 300 million zk could go to users who actively participate in defi with their tokens - it would be nice for them and would allow them to keep believing in the rightness of their actions.

4 Likes
80

ZKsync Ignite will boost DeFi liquidity on Elastic Chain, driving growth and innovation within the ZKsync ecosystem.

1 Like
82

Great questions, we need transparency on this.

1 Like
84

Hey Everyone!

As a web3 user acquisition team that works with ecosystems (eg. Arbitrum, Polkadot - also similar programs there) and has analyzed LTIPP data, I’d love to share our thoughts about this proposal:

  1. TVL shouldn’t be the only KPI - STIP & LTIPP programs in Arbitrum clearly showed that designing an incentive program only around TVL-related metrics produces short-term results that don’t bring enough value to the ecosystem to make the program sustainable. In most cases of LTIPP projects, TVL dropped right after the incentives stopped. Of course, it is important but shouldn’t be the only metric.

  2. Focusing only on DeFi protocols - LTIPP included other types of projects (especially bridges) which was a great idea. Judging from our analysis - incentivising bridges brings much better results for the ecosystem long-term. You can take a look at users that were acquired during LTIPP through Across bridge (click here) :fire: - they were over-averagely active and brought in huge volume in stablecoins that hasn’t left the ecosystem since.

  3. Sybil & Mercenary users - this was analysed very well by OpenBlock Labs in the STIP program (predecessor of LTIPP) and by our knowledge, there has been no solution to identifying this type of users. We can identify sybil users (mainly bots managing EOA accounts) but there’s still no solution to identify mercenary users - who are farming rewards in order to boost their APR and then leave the ecosystem. Much harder to be done with incentivising bridges.

Incentivising users is important but we think incorporating lessons and insights from other ecosystems (such as Arbitrum) is a must here. It can save zkSync from spending millions of ZK coins on a very narrow group of users that may be then immediately dumped on the market, driving ZK / USDT price down.

Decision if this program goes through in its current form is up to the community. If it does, we’re open to assist with points 1-3 - of course if such help is taken into account.

Cheers!
Kamil | Patterns.build

2 Likes
85

I think for UX, the constant stream every block is more enticing to users. Waiting a week can be a putoff for smaller users who may be more likely to be sticky. Seeing that Merkl is involved that may not be possible, but the way their snapshots work would be fine since users on other L2s are used to the mechanism.

I’d have to second this. Definitely should be thought out closer to the front end before we’re dealing with a large part of the supply released and having to work backwards to fix an issue. vemodel suggested is good for this

Other than that, i think the other delegates have brought up every issue i would have with it. Excited to see where it goes.

86

Consolidated Questions/Answers

Thank you everyone for your questions and comments. We have reviewed them over the weekend and have identified a few common questions and themes. We try to address all concerns and questions in the list below.

Program Design and Mechanics:

The design of the Ignite Program is centered around rapid iteration and being data-driven with clear success metrics to create maximum efficiency and long-term sustainability. Every 2 weeks, several experiments will be running concurrently across different assets, pools, routes, and apps, with the incentive amount roughly proportional to the experiment’s confidence level. Earlier experiments which have the least amount of backtesting will also distribute the least amount of incentives. As a result, we suspect the first season to index more on information gathering and for the program’s allocation to likely be back-weighted. Initially, we will focus on blue-chip asset pools, strategic trading pairs, ZKsync-native asset pools, and stablecoin pools to establish a balanced and robust liquidity foundation, alongside some “shots on goal” with assets that have nascent demand which may offer strategic differentiation vs. other ecosystems. It is important to note that we cannot be 100% forthcoming about what exact assets will be incentivized in order to prevent sybils/bots/nefarious actors from ‘gaming the system’. The experimental design minimizes contamination between experiments to learn about multiple outcomes, thereby maximizing the insights gained from each iteration.

At the end of every two weeks, results will be measured that include 1) supply-side performance of incentives, 2) demand-side performance and dynamics, and 3) user segmentation to distinguish between speculative and long-term investors. This will allow us to learn what works (and equally importantly, what doesn’t), and “double down” on the experiments that meet the program’s goals by increasing allocation. Additionally, the design will aim to predict user retention and weight TVL by expected user lifetime to help achieve sustainable growth over short-term gains.

This approach is in contrast to previous programs such as STIP, which distributed rewards directly to applications who were then asked to redirect those rewards to users. We believe this design will optimize for program efficacy both towards meeting key metrics and also long-term sustainability.

The rewards that users earn by interacting with participating protocols will then be streamed via the Merkl distributor contract and can be claimed (current plan) on a weekly basis. Rewards are directly distributed to users without needing dApp protocols who may or may not have the correct infrastructure in place to have to worry about doing proper rewards calculations and distributions.

Program Duration:

Why start with 3 seasons over 9 months vs one first season?

As detailed above, the methodology of the Ignite Program is to run many experiments concurrently, and then double down on what is working based on results. This methodology requires sufficient runway to gather learnings and then increase allocation amounts accordingly. Furthermore, having this proposal run for one season would require an additional governance vote for follow-on seasons, which would ensure a multi-week pause to pass a subsequent proposal, and risks losing momentum. The 3 season structure proposed for the Ignite program allows the DSC or the Token Assembly to review and cancel the remaining seasons if the first season is ineffective, while allowing a seamless transaction to further seasons if the first season is successful.

Program Goals:

Re Target Projects: The primary goal of the program is to increase DeFi TVL (primary metric) and liquidity depth of strategic DeFi assets (ZK, ETH, stablecoins, etc) for both existing and new DeFi projects on ZKsync Era. As stated in the dApp application guidelines, this program mandates all participating DeFi apps/protocols must be currently live on ZKsync Era with at least $1m USD in TVL, and will be enforced for the 1st season (1st 3 months) of the program. As we near the conclusion of season 1 and approach season 2, the DSC will consider additional applicants to apply for Season 2 of the program, which can include new DeFi applications that have since launched and meet the guideline criteria (this will be similar for the transition between Season 2 → 3).

Program Automation:

We have provided feedback to the ZKsync Association governance team on possible improvements. Something to highlight is that this proposal has already accelerated the development of new necessary infrastructure for automation. This includes the ZkCappedMinterFactory (0x4dBBd2dE17F811B5281a79275a66f4a8aFbc7bc7) and the development of a new legal entity (ZKsync Governance Program Service) that will help organize multisig participants. Also, the design has highlighted opportunities to improve the ZkCappedMinter, which the Association has documented.

All of these are part of the development process and our feedback. For this specific TPP, tokens are planned to be minted directly into a Merkl distributor, already a significant improvement on current standards.

That being said, the ambition is to find ways to automate further. We have amended the proposal to include an allocation of 250k ZK, allocated to complete a report due at the end of Season 1 and have a working example of automation opportunities.

Service Provider & Committee Selection:

All positions have been agreed by the proposers in advance. In taking from learnings of prior programs, such as the Arbitrum LTIPP, the council members have been preselected, and the program operators/managers have been preselected as well. This is to ensure a smooth and effective program run in service of the main goal of the proposal. The responsibilities of all of these service providers and individuals are available in the proposal. There are provisions in the proposal for the pausing or cancellation of the program at any time by the Token Assembly if the community is unhappy with how the program is being run.

Program Eligibility:

Re Eligibility Criteria: Eligibility criteria for program participants (DeFI protocols) are outlined in the Defi Protocol Participation Requirements section of the proposal.

Re Selection Process: The dApp/protocol application process was created based off of learnings from prior programs, namely the Arbitrum STIP program. In that program, every single protocol needed to be publicly viewed, commented on and voted on before entry. This led to delays and confusion where many protocols felt unfairly represented, guided and evaluated.

In response, the Ignite program is set up so that all protocols may apply and will be evaluated by OpenBlock Labs based on the requirements listed in the proposal. OpenBlock Labs will propose recommendations for which protocols/apps should be included in the program to the DSC, which has final veto power. All of these decisions will be transparently and openly relayed to the community, ensuring that the community is aware of how & why protocols are being accepted.

Re KYC requirement: No users will need to KYC to participate in this program. The DSC must complete KYC as an entity via ZKsync Governance Program Services (ZKsync GPS) in order to be eligible for compensation. Any protocols who would like to qualify for bonuses at the end of the program will also have to KYC but it is not mandatory for DeFi protocols to KYC at the beginning or to be included in the program.

Re Reward Claiming Cadence: Once bi-weekly is suggested by the proposal, but we’ve explicitly asked for community feedback on this (“The current proposal is to allow pending rewards to be claimed from the Ignite website on a weekly basis, however we would like community input on this point…”) . If there is community interest to distribute rewards more often, we will update the proposal to reflect this.

Program Fees and Budget:

Re Overall Admin fees: There was a lot of feedback shared regarding the total sum of fees (25M ZK) for admin costs required to run the program. Firstly, the overall admin fees includes 1) paying the analytics vendor (OpenBlock Labs) and technology provider (Merkl) for both man hours and access to their proprietary technology platforms, 2) marketing budget to ensure the program reaches its desired metrics, as strongly recommended by key contributors of previous programs such as Arbitrum STIP, 3) the DSC for its work to administer the program, 4) SC members to mitigate security and opsec risk, 5) making the Ignite website gas-less to streamline UX, 6) discretionary bonus for exceptional performance from 3P vendors or applications, 7) budget for a third-party auditor to review the performance of each season, and 8) buffer for any unforeseen administrative costs.

Secondly, the Ignite program is carefully designed with the best interest of token holders in mind. As mentioned above, a core element of the design is for the analytics vendor to be continuously designing experiments, monitoring results, and using those results to inform the next set of experiments – every 2 weeks. Experiments will be crafted in a way to learn with also one eye towards the long-term goals of the program and ecosystem sustainability (retained TVL). Results will not only include metrics from both the demand and supply sides, but also a deep contextual understanding of the user personas who are participating in the ecosystem and how we can retain high-value users and LPs. To do this work properly requires incremental effort (and as a result, more fees) and we strongly believe this is the right long-term investment for the ZKsync ecosystem.

Finally, one detail that was missed in the initial post that has been added in the latest version: the fees for man hours for OpenBlock Labs and Merkl were calculated using the 30D MA of ZK at the date of the proposal being posted on the forum. To protect both vendors from downside price volatility and token holders in case of upward price movement, fees for man hours will be re-computed at the start of season 2 and 3 based on the 30D MA of ZK and will be included as part of any renewal recommendation sent to the DSC.

Re: Service Provider Fee Breakdown

Compensation for each contributor is discussed under the Contributor section, or you can find the details here. Please toggle down each section to find details regarding each contributor. You can also find a breakdown of contributor allocations in this table, including fees of OBL.

Re Token allocation and bonuses

Bonus allocations are already shared (they are included in the 25M ZK for admin fees), but the exact thresholds still need to be determined. The DSC is committed to sharing these thresholds publicly with the TA before the start of the program and any amendments based on market trends afterwards.

Re SaaS fees

The SaaS fees cover technological infrastructure that enable comprehensive data analytics, performance monitoring, user rewards calculation and distribution, reporting, and other advanced tooling which are essential for optimizing the program’s effectiveness. Specifically, this includes:

  • Access to a centralized dashboard offering visibility into the performance of each protocol, including complex analytics such as market depth, price execution, and user engagement.
  • Dynamic user rewards (APY) computation based on user participation with API for display on Ignite website and DeFi app front-ends.
  • Access to advanced analytics and heuristic to prevent Sybils and other commonly used farming techniques (eg recursive borrowing, etc)
  • Adding support for reward calculation of all eligible protocols in the Merkl engine
  • Distribution of rewards through battle-tested and audited smart contract distributor
  • Hosting of several isolated dispute bots to prevent anyone from compromising the merkle root responsible for the rewards
  • Detailed reporting for each vertical (DEXs, Money Markets, Perpetuals, etc.), allowing ZKsync to assess the efficacy of incentives and whether they’re driving desired outcomes.
  • Access to software that facilitates increased contextualization of users, such as this

Re: Fund Management for Capped Minters:

The funds that are proposed are all assigned to separate cap minters and for specific purposes to prevent misuse. The only funds that are left to the discretion of the DSC are the “discretionary funds”, which are specifically assigned to unforeseen circumstances that may occur over the 9 month long program.

Re: Support Services & ‘Unforeseen circumstances’:

This line item consists of the buffer we want to provide in case of such circumstances as unplanned technical or integration work needed, insufficient budget for marketing or gas credits, decreased ZK price which requires more tokens than anticipated to pay man hours fees for vendors, etc. No rewards are distributed to projects, only to users. As stated in the proposal, tokens will not be minted unless they are required for the program’s success.

Questions for DSC

Re DSC compensation:

Each member of the DSC will be compensated 25,000 $ZK per month for their role & responsibilities. The DSC plays a pivotal role in acting as a veto power for the program (admissions, bi-weekly allocations, renewal, etc) as well as ensuring that the program is being run effectively.

Re Marketing:

Marketing for the Ignite Program will be primarily supported by an external marketing agency. This agency will be fully vetted and approved by the DSC before beginning operations. They will also get evaluated alongside the entire program every 3 months in a public report available to the community. The DSC is tasked with selecting the best partner to achieve the program’s objectives and any anything not spent will remain unminted.

Questions for OBL

Re Break down of hours:

You can find the detailed break-down of hours here. While not included in the 3,240 core hours, additional team members including Software Engineers, Analytics Engineers, Data Analysts, and Designers, provide support to the core team throughout the duration of the program

How can DeFi protocols ensure that they are being monitored by the analytics provider?

All participant protocols are required to onboard with OpenBlock Labs as part of the program’s requirements. By completing the onboarding process and integrating their data according to OpenBlock’s schemas, protocols ensure they are effectively monitored as is necessary for making bi-weekly token allocation recommendations.

What type of pools will the rewards be applied to?

Rewards will be applied to pools that align with the program’s goals and demonstrate meaningful results to the program’s key metrics. This includes:

  • Blue-Chip Asset Pools: Pools involving major assets like ETH, ZK, USDC, WETH and WBTC.
  • Strategic Trading Pairs: Key pairs such as ZK/ETH, ETH/USDC, ZK/USDC, and wsETH/ETH.
  • ZKsync-Native Asset Pools: Pools that support tokens native to the ZKsync ecosystem.
  • Stablecoin Pools: Attracts liquidity providers seeking lower-risk options
  • Nascent Asset Pools: Pools that support assets that show nascent demand and can offer unique differentiation to other ecosystems such as RWAs

Why is OBL better than veToken model (let the market decide the best protocols to allocate the liquidity to rather than centralized and potentially conflicted committees)

  • Objective Allocation: OpenBlock Labs uses data science models to make allocation recommendations based on empirical data and rapid iteration. This minimizes subjective decision-making and limits risks associated with influence by large holders in veToken models.
  • Goal Alignment: Ensures incentives remain aligned with program objectives, such as liquidity growth and slippage reduction, rather than being dictated by market speculation or concentration of voting power.
  • Enhanced Liquidity Growth: The veToken model imposes additional costs by requiring users to lock up their tokens for extended periods, introducing friction that deters participation and slows growth. This not only hinders liquidity providers’ decisions but also prevents the market from reaching equilibrium quickly. In contrast, a liquidity mining approach avoids these long-term commitments and extra costs, allowing faster growth than with the veToken model.
  • Accountability: The proposal includes oversight provisions that allow for the Analytics Manager to be changed under specific conditions, ensuring accountability
  • Specialized Expertise: OpenBlock Labs has extensive experience designing and managing programmatic incentive programs. This expertise enables OpenBlock to implement proven, data-driven models tailored to the specific goals of the ZKsync Ignite program.

Questions for Merkl

Re Break down of hours:

You can find the break-down of hours here. Merkl is committed to results on this engagement, this means that if it takes Merkl more hours, the budget will not be increased.

Why not allow the protocols to distribute the incentives directly?

  • Enable protocols to focus on their core features: many of the protocols that will be eligible to the program will not have an incentive system setup. Merkl will set it up for them to enable them to focus on marketing and their core product.
  • Improve UX: using a single tool for all rewards makes it possible to build a unified program app that will display and participate in all Ignite opportunities.
  • Facilitate incentives management: Running a large-scale liquidity event requires precision. If each protocol had rewards and distributed them via airdrops, the DSC would have to audit that $ZK rewards were properly distributed to the right recipients for each protocol. With Merkl, the DSC only has to audit a single system.
  • Avoid misuse of incentives: Either way, this approach lacks control. It’s similar to issuing grants, where there’s no guarantee the funds will be used as promised. Without proper oversight, misallocation becomes a real risk, leading to missed opportunities for maximizing liquidity and boosting TVL across the ZKSync Ecosystem.
  • Need for Transparency and Accountability: Ensuring that rewards are distributed transparently and can be tracked is essential. Without this, it’s difficult to build trust and measure the success of such incentivization efforts. While it is very easy to build decentralized reward system for ERC20 tokens (staking contracts), it’s much harder to do so for NFT based protocols (Concentrated Liquidity DEXes for example).

Change Log of Proposal Updates

  • Program Design
  • Automation note
  • Review period between seasons
  • Removal of KYC requirements for dApps
  • Removal of L2Beat requirements for dApps
2 Likes