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

Token Mechanics Archived TPPs
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

3 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
87

[TPP 001] ZKsync Ignite Program (the “Ignite Program”)

Title ZKsync Ignite Program
Proposal Type TPP
One Sentence Summary Allocate 325,000,000 ZK tokens over nine months to deploy a program designed to establish a DeFi liquidity hub on ZKsync Era, aimed at increasing DeFi TVL and improving liquidity across all interoperable ZK Chains (”Elastic Chain”).
Proposal Author Merkl
Proposal Sponsor Baki
Date Created 2024-10-17
Version v1.0
Summary of Action The Ignite program will allocate 325 million ZK tokens over nine months, with 300 million allocated to users via six capped minters (50 million each), and an additional 25 million tokens, managed by four capped minters, to cover administrative and unforeseen costs.
Link to contracts See “Proposal Code Specifications” section

Summary

  • Goals: The ZKsync Ignite program will allocate 325M ZK tokens over 9 months to establish a DeFi liquidity hub for the Elastic Chain on ZKsync Era. The primary metrics of the program are to increase DeFi liquidity and strategic asset depth to minimize slippage
  • Design: Every 2 weeks, token allocations will be defined and streamed towards specific pools/assets in participating DeFi apps/protocol at the recommendation of the program’s analytics provider (OpenBlock Labs), which is subject to review by an independent group of experts called the DeFi Steering Committee (DSC). This design enables the program to be iterative and strategic towards meeting its primary metrics.
  • UX: The Ignite website will allow users to view incentivized pools from participating DeFi apps/protocols and directly provide liquidity. Pending eligible ZK rewards will be updated every ~8 hours on the Ignite website. 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…
  • Performance: Primary metrics will be available on live public dashboards as well as in detailed reports at the conclusion of every season (3 months).
  • Oversight: The Token Assembly has the ability to cancel the program at any time by passing a proposal or revoking DSC admin authority. In addition, the DSC has the authority to cancel the program at the end of any season if primary metrics are not achieved.

Abstract

The goal of the Ignite Program is to establish a robust, unified source of liquidity on ZKsync Era in service of builders and users across the Elastic Chain who can access this liquidity via native interoperability.

This consolidation of liquidity forms a “liquidity hub”, which serves as foundational infrastructure to facilitate critical functions for builders and users including storing & exchanging assets, liquidity, and accessing a broad array of crypto-native and real-world assets in an economically efficient manner.

“Liquidity hub” refers to a decentralized, permissionless means for builders and users to access liquidity across ZK Chains via third-party apps/protocols that are deployed on ZKsync Era. It is not a single service but a collection of independent apps/protocols. There is no centralized control or provision of regulated crypto-asset services.

Why have a unified liquidity hub?
  1. Boost Innovation: builders can focus on finding product-market-fit without the burden of bootstrapping liquidity, accelerating time-to-market and impact,
  2. Seamless DeFi Asset Exchange: users benefit from low-slippage asset exchanges using proven DeFi protocols, creating a smooth and reliable experience, and
  3. Attracts Top Builders: with a strong liquidity hub, the Elastic Chain becomes a prime destination for innovative DeFi builders seeking a growing, diverse user base.
Why is ZKsync Era best positioned to serve as the liquidity hub for the Elastic Chain?
  1. Unmatched Security: as a ZK rollup on Ethereum, ZKsync Era offers the strongest security guarantees with ZK proofs and fast finality,
  2. Established DeFi Ecosystem: ZKsync Era has already integrated with key foundational primitives (including native USDC) and blue-chip DEX and lending protocols, and
  3. Fully Onchain Governance: The recent governance launch marks ZKsync Era’s commitment to full decentralization, ensuring long-term stability and trust.
How the Ignite Program powers this vision?
  1. Deep Liquidity: reducing slippage across volatile and stable assets such as: ETH, USDC, USDT, WBTC, etc.,
  2. Incentives for Participation: attracting liquidity, users, and builders through targeted rewards, and
  3. Yield Opportunities: establishing DeFi functions that allow liquidity providers to earn yield, and supporting the onchain expansion of related assets.

Ignite Program requests the right to mint 325,000,000 ZK tokens from the Token Assembly’s ZK Token allocation across ten capped minter contracts over the span of nine months of which:

  1. 300,000,000 ZK tokens distributed between 6 capped minters (containing 50,000,000 ZK tokens each) will be distributed to users as recognition for meaningful participation in selected DeFi apps/protocols.
  2. 25,000,000 ZK tokens distributed between 4 capped minters will cover the administration costs involved in deploying and managing the program over the nine month period, and includes a buffer for unforeseen circumstances. Any ZK tokens that are unused will remain unminted and the related capped minter smart contract will be destroyed upon conclusion of the program.

The Ignite Program operations will be structured as follows:

  • OpenBlock Labs will serve as the “analytics manager” and be responsible for:
    • Reviewing DeFi apps/protocols via an application process every season (3 months)
    • Recommending how ZK tokens are allocated, to be updated every two weeks based on observed data
    • Facilitating bi-weekly reviews of the program
    • Publishing comprehensive reports every 3 months on program performance, with renewal recommendations if necessary
  • Merkl will own technology and program operations, including:
    • Designing and implementing the Ignite website
    • Supporting day-to-day operations support to ensure successful execution of the program across participating teams and users
    • Calculation and distribution of user token rewards via the Ignite website
    • Advising on program marketing strategies
  • A DeFi Steering Committee (“DSC”) consisting of 5 members will have limited administrative powers (mostly veto power over key program decisions), including the power to veto:
    • Approval of participation eligibility for DeFi protocols/apps,
    • Proposed ZK token allocations
    • Proposed marketing strategies and operations,
    • Changes to program automation [Amendment 21-OCT-2024]
    • Renewal recommendation if the program underperforms based on predetermined metrics

:information_source: Note that while OpenBlock Labs, Merkl and the DSC administer the Ignite Program, they do not operate or control the “liquidity hub” or any apps or services on ZKsync Era.

Motivation

The purpose of the Ignite Program is informed by the following goal of the ZKsync governance system (as set forth in the ZK Nation Documentation HERE):

:star2: Expand Onchain Assets: The Elastic Chain has accessible, valuable, and diverse assets onchain, enabling a dynamic economy within and across ZK Chains.

Primary Metrics

The primary metrics of the Ignite Program will be measured by increasing DeFi TVL (both in absolute and relative to ETH terms), as well as strategic asset depth to minimize slippage. Other key metrics that will be measured include but are not limited to: price-adjusted DeFi TVL, natively minted TVL, DEX TVL, overall TVL, slippage on volatile and stable pairs, and sustainability metrics.

Specifications

:information_source: We recognize TPPs are a new concept that the community is experimenting with. Please note this is one interpretation of what a TPP can look like. The mechanism design had to take into account factors that are unique to running this DeFi incentives program.

Although it would be ideal for this program to be automated, that objective is not fully achievable due to the program’s complexity and commitment to following legal requirements such as KYC. Therefore, the qualification review and distribution mechanic of this program will be supported by OBL and Merkl, and the DSC will need to sign off on final transactions to distribute ZK tokens to recipients. While this introduces administrative oversight to the distribution mechanism, we have outlined the setup, operational processes, and contracts in detail to ensure full transparency. All transactions will be executed onchain.

NOTE: An amendment to this proposal has been included on 21-Oct-2024 to allocate tokens to support onchain automation. Please see the “Program Mechanic Automation” section for more details.

For further details on accountability of the service providers and the DSC, please refer to the “Accountability Framework” section at the end of the proposal. We hope to learn through this program what is necessary for automation in the future.

Program Design [Amendment 21-OCT-2024]

The design of the Ignite Program is rooted around rapid iteration and being data-driven with clear success metrics to create maximum efficiency and long-term sustainability. Every 2 weeks, OpenBlock Labs (“OBL”) will propose several experiments towill be running concurrently across different assets, pools, routes, and apps, with the incentive amount roughly proportional to 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. 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 which 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.

The program centers on user-centricity, and will fund a custom-designed website & dashboard that makes it simple for users to discover incentivized apps, directly participate, and view/claim rewards. The website & dashboard will be designed and operated by Merkl.

The design of this program incorporates learnings from both what has and hasn’t worked in similar programs that came before it, indexing on:

- Meritocracy + Rapid Iteration — Instead of pre-determining incentive amounts to participating DeFi protocols, the Analytics Manager (OpenBlock Labs) will propose recommendations for which assets, pools, and applications will receive ZK token allocations every two weeks. This allows the program to be fluid in its strategy and maximizes program effectiveness by assessing performance continually to deliver the highest growth potential possible.
- Being User-Centric — The program will fund a custom-designed website & dashboard that makes it simple for users to discover incentivized apps, directly participate, and view/claim rewards. The website & dashboard will be designed and operated by Merkl.
- Lessons from Prior Programs - The design of Ignite leverages learnings from programs such as Arbitrum STIP & LTIPP, Avalanche Rush, Sui Incentives, and Linea Surge to create a well-balanced approach that combines decentralized governance with structured and focused oversight via the DeFi Steering Committee (DSC) over participating DeFi apps/protocols.

Program Mechanics

Every two weeks, OpenBlock Labs (“OBL”) will propose specific ZK token allocations on a per pool basis to the DeFi Steering Committee (“DSC”) based on its analytics and data science models, and Merkl will prepare a transaction for the ZK token amount allocated for this period.

The DSC will need to sign a transaction of the ZK token amount from the “Ignite Program Distribution (“IP-Distro”) capped minter” to the Merkl distributor contract (not providing a signature is indication of a veto of this proposed recommendation). Merkl will create campaigns on a per pool basis based on the allocation methodology provided by OBL, and will dynamically compute rewards based on user actions and activity over the given period. Users will be able to see updated ZK token rewards every ~4-8 hours on the Ignite Program Dashboard, located on the Ignite Program website.

Merkl will update the distributor contract to reflect these rewards every week. Users will be able to claim their rewards directly from the Ignite Program Dashboard on a weekly basis. The corresponding ZK token rewards that users claim will be fully unlocked and sent directly to their wallet upon claiming.

:question:Feedback Request: How does the community feel about a weekly cadence for participants to claim rewards? Would another cadence make more sense from your perspective? Please share thoughts below.

This rapid two week iteration cycle enables the program to be very targeted in the behaviors it wants to incentivize in order to reach target effectiveness metrics, double-down on specific mechanisms/applications/areas which are working well, and have the ability to dynamically adjust throughout the program.

The DSC or Token Assembly can cancel the program at any time. Any ZK tokens that are unused will remain unminted and the related capped minter smart contract will be destroyed upon conclusion of the program.

Program Mechanic Automation [Amendment 21-OCT-2024]

During the first season of the Ignite Program, a research and development workstream lead by Dr.Nick and supported by the Governance Team of the ZKsync Association will specify how to evolve the technical design of Ignite to further automate the program. The scope of work will be as follows:

  1. Evaluate the current Ignite program design and write a specification for an automated and permissionless design, in line with TPP Guidelines, TPP FAQ, and Dr.Nick’s recent the TPP analysis and maturity model. The specification will include technical and operational design.
  2. Deploy a working end-to-end template of specification on testnet AND ZKsync Era mainnet (excluding audit) proving the specification works in practice.
  3. Deliver a written report, including links to relevant code in the ZKsync Association Github repository, to the ZKsync governance forum for improvement recommendations for Season 2 and Season 3 of Ignite program, as well as future TPPs.

Program Timeline

The ZKsync Ignite program will be executed in three seasons over nine months, with internal target metrics for each season set and approved by the DSC.

  1. Program Set-Up (~Oct 2024 → ~Nov 2024)
    1. Proposal posted on Forum (Oct 17th)
    2. Proposal vote (~Oct 23st)
    3. Proposal execution (~Nov 6th)
    4. Application Submission + Approval (~mid Nov)
    5. Application Integration with OpenBlock Labs and Merkl + QA (~mid Nov)
    6. Ignite Launch (~late Nov)
    1. Proposal posted on Forum (Oct 17th)
    2. Proposal submitted onchain (~Oct 29th)
    3. Proposal voting starts (~Nov 5th)
    4. Proposal execution (~Nov 20th)
    5. Application Submission + Approval (~mid/late Nov)
    6. Application Integration with OpenBlock Labs and Merkl + QA (~late Nov)
    7. Ignite Launch (~early Dec)
  2. Season 1 (~Nov 2024 → ~Feb 2025)
  3. Season 2 (~March 2025 → ~May 2025)
  4. Season 3 (~June 2025 → ~Aug 2025)

Metrics will be continuously monitored, with bi-weekly adjustments, monthly reviews, and three-month seasonal reviews ensuring the program adapts effectively to ecosystem needs. More information on the accountability framework related to metrics is set out below.

Towards the end of Seasons 1 and 2, DSC will review findings and re-open application submissions for participation in the subsequent season.

DeFi Protocol Participation Requirements

If this program is approved by the Token Assembly, there will be a one week application submission and approval period where DeFi applications are able to apply to be included in the program’s initial season. The final decision on the inclusion in the program sits with the DSC.

To participate in the Ignite Program, all DeFi apps/protocols must:

  • Complete and submit a ZKsync Ignite Program Application
  • [AMENDMENT 21-10-2024] Complete KYC with the ZKsync Association before the start of the program
  • Be live on ZKsync Era Mainnet
  • Must have a minimum $1MM DeFi TVL (as measured by DeFi Llama) at the time of the application submission
  • Maintain an integration with [AMENDMENT 21-10-2024] both L2Beat and DeFi Llama
  • Fully cooperate and integrate relevant APIs, data streams, and platforms with the program providers: OpenBlock Labs & Merkl
  • Must not encourage or participate (directly or indirectly) in sybil farming, spoofing metrics (such as TVL, users, etc), or other activities that are abusive or inconsistent with the purposes of the program
  • Actively assist in the administration of the program where necessary or advisable, for instance by helping with co-marketing and collaboration for the program

Failure to comply with these guidelines or any other regulatory or compliance concerns may result in the DSC removing participants from the program at any point in time.

Failure to meaningfully participate towards the specified goals during the program may result in the DSC removing under-performing apps/protocols.

The program will span 3 seasons, as such, protocols that do not qualify for a particular season of the program can re-apply for the subsequent season. More information will be released about how new DeFi protocols can apply to the program near the conclusion of each season.

Infrastructure

These components are essential for deploying and managing the program. The code created will be hosted within the ZKsync Association’s GitHub repository to facilitate collaboration and maintain security standards:

  • ZKsync Ignite Website: The main portal for the program, providing users program information, a user dashboard, a list of incentivized applications, the ability for 1-click participation/view/claim rewards in a gas-free manner via paymaster, and other resources. The portal is an access point to third-party apps/protocols, but is not a standalone product or service and does not constitute the “liquidity hub” itself. To be built and operated by Merkl after passing of proposal.
  • Analytics: A public Dune dashboard to provide, track and measure performance data, user engagement, and effectiveness of the program strategies. All source-code (SQL) and CSVs should be hosted in a repo under the ZKsync Association Github. To be built and maintained by Open Block Labs and Merkl.
  • Discord: A discord server for users to receive answers on program or technical questions. To be maintained by Merkl.
  • Contracts: All source-code for contracts supporting further program automation will be hosted in a repo under the ZKsync Association Github. [Amendment 21-OCT-2024]
  • Data Transparency: All data used in the monitoring and decision-making processes will be made publicly available.

This framework ensures that the Ignite Program operates with a high degree of accountability and responsiveness to both its internal metrics and the community’s expectations.

Contributors

The following independent third-parties have agreed to assist with the implementation of the program, and a summary of their roles follows below:

1. Analystics Manager: OpenBlock Labs

OpenBlock Labs (“Analytics Manager”) is the analytics manager for the Ignite Program. Their data analysis and performance metrics form the basis of the ZK token disbursements for the program.

Responsibilities:

  • Review and recommend applying DeFi apps/protocols to DSC for program participation
  • Integration and developer support for participating teams integrating with OpenBlock Labs platform
  • Create high-level token allocation strategy to optimize for program metrics and share with DSC before program begins
  • Recommend token allocations to DSC fortnightly for review
  • Ongoing technical support or review of data discrepancies
  • Report program results on a monthly basis for the DSC to review
  • Create public 3-month “seasonal” review of the program for the DSC & Token Assembly to review the progress

Resources:

  • Data Scientist, Data Engineer, Project Manager

ZK Token Allocation: total of 4,995,500 ZK over 9 months, or ~1.54% of program budget

  • 3,923,000 ZK for 3,240 hours of effort. [AMENDMENT 21-10-2024] Fees for man hours will be re-computed at the start of season 2 and 3 based on the 30D MA of ZK at that time and will be included as part of any renewal recommendation sent to the DSC.
  • 1,072,500 ZK for 9 months of SaaS fee to utilize OpenBlock analytics platform

Bonus Allocation: up to a total of 1,625,000 ZK tokens, or 0.50% of program budget

  • OpenBlock Labs is eligible to receive bonuses for exceeding thresholds for the following metrics (DSC will determine exact definition + thresholds before launch of program):
    • Price-adjusted DeFi TVL
    • Slippage amongst key pairs
    • Retained DeFi TVL (or similar sustainability measure)

DSC may change the Analytics Manager under specific conditions.

Their data analysis and performance metrics form the basis of the emissions disbursements for the program.

2. Technology Provider: Merkl

Merkl is the technology provider (“Technology Provider”) for the Ignite Program. This role is crucial for ensuring that the program’s technology needs are met promptly and efficiently.

Responsibilities:

  • UX design, creation, implementation, hosting, and maintenance of legally compliant ZKsync Ignite Website
  • Custom integrations with applications to Merkl platform
  • Create campaigns for user incentive rewards
  • Calculation and distribution of rewards to users
  • Operational support of program for participating applications and users

Resources:

  • Lead Developer, Front-End Developer, UX Designer, Operations Manager, Support Liaison

ZK Token Allocation: total of 4,634,500 ZK tokens over 9 months, or ~1.43% of program budget

  • 2,197,000 ZK tokens for 2,120 hours of effort. [AMENDMENT 21-10-2024] Fees for man hours will be re-computed at the start of season 2 and 3 based on the 30D MA of ZK at that time and will be included as part of any renewal recommendation sent to the DSC.
  • 2,437,500 ZK tokens for 9 months of SaaS fee to utilize Merkl platform

Bonus Allocation: up to a total of 325,000 ZK tokens, or 0.10% of program budget

  • Merkl is eligible to receive bonuses for exceeding thresholds for the following metrics (DSC will determine thresholds before beginning of program):
    • DeFi TVL
    • Price-adjusted DeFi TVL

DSC may change technology provider under specific conditions.

3. DeFi Steering Committee (DSC)

The DeFi Steering Committee is comprised of 5 members. These members are industry experts and stakeholders who perform limited oversight functions to ensure that the program has continued alignment with the goals and target metrics approved by the Token Assembly. The DSC’s discretion is limited by its corporate documents and its members are subject to binding legal agreements entered into with the DSC.

Membership: Members of the DSC who will be considered ratified by the Token Assembly if this proposal is approved are:

  1. Lindsey Winder, Hedgey Finance
  2. Michael Lewellen, OpenZeppelin
  3. Kerman Kohli, 0xarc
  4. Ashwath Balakrishnan, Delphi Digital
  5. Karthik Senthil, Matter Labs

Members of the DSC may resign voluntarily or be removed from their position with approval from three DSC members. The DSC is responsible for nominating and approving candidates to fill vacant seats. A replacement may be appointed with approval from three DSC members. There should always be a minimum of three DSC members.

Responsibilities:

  • Review eligible DeFi apps/protocols from the program, exercising veto as needed
  • Review bi-weekly modifications to reward incentives as recommended by OBL, exercising veto as needed
  • Sign transaction via multi-sig for bi-weekly reward dispersement to active participants of the program
  • Conduct monthly meetings reviewing the status of the program hosted by OBL (publish public minutes of these meetings for the Token Assembly)
  • Conduct in-depth seasonal reviews of the program every 3 months to ensure that the program is adhering to the metrics set forth in this proposal
  • Engage third party vendors, if needed, for limited marketing and audit duties
  • If necessary, add or remove DeFi apps/protocols from the program
  • If necessary, decide to end the program early if the program is not living up to the guidelines set forth by this proposal or for other reasons at the DSC’s sole discretion

The Ignite_Admin_Multisig will be the admin of the 6 program distribution capped minters, as well as one of 2 signers for the DSC_OBL_Admin_Multisig, DSC_Merkl_Admin_Multisig and the DistributorUpgradeBoard. The Ignite_Admin_Multisig will be composed of all 5 DSC members and 3 signers from the Security Council. It will have a signing threshold of 6/8, requiring at least one member from the Security Council to sign off on each transaction as an accountability measure for the DSC.

As the admin on the 6 Ignite Distribution capped minters, the Ignite_Admin_Multisig will have the power to mint up to 300,000,000 ZK tokens for disbursement. As the collective admins of the 4 Ignite Administration capped minters, theIgnite_Admin_Multisig, DSC_OBL_Admin_Multisig and DSC_Merkl_Admin_Multisig are authorized (but not required) to mint up to 25,000,000 ZK tokens (total) for costs related to operations execution as specific in this proposal.

Compensation: The DSC will receive a monthly budget of 100,000 ZK tokens over the course of the nine month program for a total of 900,000 ZK tokens, to be divided equally among four members. (Excluding Karthik Senthil representing Matter Labs)

The Security Council (SC) signers will receive 14,814 ZK tokens each, totaling 44,442 ZK per month for their participation; with a total budget of 400,000 ZK tokens allocated to them for the nine month program.

Additional Provisions for Program Operations: 12,115,000 12,120,000 ZK tokens (3.73% of the program budget) [Amendment 21-OCT-2024]

If necessary or advisable for the success of the program (at the sole discretion of the DSC), the DSC is authorized to allocate additional ZK tokens as follows:

  • Branding/Marketing/Publicity: The DSC has the authority to spend up to 5,000,000 ZK tokens across the full length of the program (9 months) towards branding, marketing and publicity of the program.
  • Gas Credits: The DSC has the authority to spend up to 500,000 ZK tokens across the full length of the program to sponsor gas for user transactions via paymaster made from the Ignite website.
  • Third Party Audit: The DSC has the authority to spend up to 1,500,000 ZK tokens across the full length of the program (9 months) to hire a third party auditor to review the results of the program at the end of every season.
  • DeFi Applications: The top performing participating DeFi app(s)/protocol(s) towards the specified metrics are eligible for bonus compensation up to a total of 2,000,000 ZK tokens.
  • Onchain Automation: An initial 250k ZK tokens are allocated this workstream to cover automation design, contract development, and the report to the Token Assembly. Depending on workstream outputs and Ignite program KPI achievement, additional token allocations may be considered by the DSC for Seasons 2 and 3, which will come from the budgeted line item for audits and production integration into the Ignite program. [Amendment 21-OCT-2024]
  • Reserve for Unforeseen Expenses: In the case that there are any additional unforeseen costs that are required for the program’s continued success, the DSC may use up to 3,115,000 2,870,000 [Amendment 21-OCT-2024] ZK tokens to pay for these services.

NOTE: While the DSC is permitted to use these tokens for administering the program, it is by no means required to use all of these tokens. Any ZK tokens that are unused will remain unminted and the related capped minter smart contract will be destroyed upon conclusion of the program.

Proposal Code Specifications

Relevant Multisigs

Name Address Signers
Ignite_Admin_Multisig TO BE CREATED 6/8: 5 DSC signers & 3 members of the Security Council
Merkl Multisig zksync:0x3d3Fd37af3aEaBD0154230AdcfC9C177E13142c8 Merkl team
OBL Multisig Needed OBL Team
DSC_OBL_Admin_Multisig TO BE CREATED 2/2: Ignite_Admin_Multisig & OBL Multisig
DSC_Merkl_Admin_Multisig TO BE CREATED 2/2: Ignite_Admin_Multisig & Merkl Multisig
DistributorUpgradeBoard TO BE CREATED 2/2: Ignite_Admin_Multisig& DSC_MainMultisig

Other Relevant Contracts

Name Address Note
ZK Token Contract 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E Controlled by Token Protocol Governor Timelock
ZkCappedMinterFactory (Mainnet) 0x4dBBd2dE17F811B5281a79275a66f4a8aFbc7bc7 No Admin
Merkl Distributor Contract ZKsync Era Block Explorer Merkl will use the following distribution and campaign creation contracts to distribute ZK to eligibly recipients
Merkl Campaign Creator ZKsync Era Block Explorer Admin: DistributorUpgradeBoard. Merkl will create a new campaign every two weeks with updates parameters based on onchain user participation metrics.

Capped Minters

The necessary capped minters will be created in advance of being submitted onchain, with the appropriate multisigs as their admins (see capped minter tables below for details). The passing of this proposal will assign the following capped minters the Minter Role on the ZK Token contract. This will grant the admins of each capped minter access to mint the specified amount of ZK in each capped minter.

The Ignite Program has ten (10) ZKCappedMinters:

Six (6) Ignite Program Distribution ("IP-Distro") capped minters:

These relate to ZK tokens to be minted and distributed to users in pursuit of the goals and metrics of the program. Each capped minter will contain 50,000,000 ZK Tokens and will be used as needed throughout the program.

IP-ZK-Distro-Minter-1: `TO BE CREATED`

IP-ZK-Distro-Minter-2: `TO BE CREATED`

IP-ZK-Distro-Minter-3: `TO BE CREATED`

IP-ZK-Distro-Minter-4: `TO BE CREATED`

IP-ZK-Distro-Minter-5: `TO BE CREATED`

IP-ZK-Distro-Minter-6: `TO BE CREATED`
Four (4) Ignite Program Administration ("IP-Admin") capped minters:

These relate to ZK tokens to be minted and disbursed with respect to: (a) OBL’s ongoing Analytics Management services for the program; (b) Merkl’s ongoing Technology services for the program; (c) DSC ongoing program activities, SC signing + provisional bonus incentives for the program operators OBL/Merkl; and (d) Supporting services necessary for the program (including: marketing, gas abstraction, 3rd party audits, provisional bonus incentives to app/protocol operators, as well as any additional necessary discretionary spend).

IP-ZK-Admin-Minter-OBL: `TO BE CREATED`

IP-ZK-Admin-Minter-Merkl: `TO BE CREATED`

IP-ZK-Admin-Minter-DSC: `TO BE CREATED`

IP-ZK-Admin-Minter-Supporting-Services: `TO BE CREATED`

Ignite Program Capped Minters

The Ignite Program capped minter contracts which administer the Ignite Program are based on the following specifications:

Ignite Program Cappe Minters Overview
Parameter/Feature Minter 1 Values Minter 2 Values Minter 3 Values Minter 4 Values Minter 5 Values Minter 6 Values Description
TOKEN ZK ZK ZK ZK ZK ZK The token contract where new tokens will be minted, defined as IMintableAndDelegatable.
ADMIN Ignite_Admin_Multisig Ignite_Admin_Multisig Ignite_Admin_Multisig Ignite_Admin_Multisig Ignite_Admin_Multisig Ignite_Admin_Multisig The address that is authorized to mint tokens. This is set as an immutable public address.
CAP 50,000,000 50,000,000 50,000,000 50,000,000 50,000,000 50,000,000 The maximum number of tokens that can be minted by this contract. This value is immutable.
minted - - - - - - Tracks the cumulative number of tokens that have been minted by the contract so far.
Mint Function Enabled, DSC can mint up to cap Enabled, DSC can mint up to cap Enabled, DSC can mint up to cap Enabled, DSC can mint up to cap Enabled, DSC can mint up to cap Enabled, DSC can mint up to cap Allows minting a specified amount of tokens to a given address, provided the cap is not exceeded.
Authorization Check Admin-only (DSC) Admin-only (DSC) Admin-only (DSC) Admin-only (DSC) Admin-only (DSC) Admin-only (DSC) Ensures that only the designated admin can mint tokens by checking if msg.sender is the ADMIN.
Cap Check Automatic, prevents exceeding cap Automatic, prevents exceeding cap Automatic, prevents exceeding cap Automatic, prevents exceeding cap Automatic, prevents exceeding cap Automatic, prevents exceeding cap Ensures that minting does not exceed the predefined cap by checking the sum of minted and _amount.
Error Handling Unauthorized access, cap exceeded Unauthorized access, cap exceeded Unauthorized access, cap exceeded Unauthorized access, cap exceeded Unauthorized access, cap exceeded Unauthorized access, cap exceeded Includes custom errors for unauthorized access (ZkCappedMinter__Unauthorized) and for attempts to mint tokens beyond the cap (ZkCappedMinter__CapExceeded).
Admin Management Governed by TA decisions Governed by TA decisions Governed by TA decisions Governed by TA decisions Governed by TA decisions Governed by TA decisions Specifies that the TA has the authority to change or remove the admin, (and maybe burn tokens) if key metrics/milestones aren’t met, subject to a GovOps or Token proposal.

Ignite Administration Capped Minters

In order for the Ignite Program to succeed, the following deliverables are expected to be completed by named contributors. Costs associated with the execution of the program are provided for by the following Ignite Administration capped minters.

Ignite Administration Capped Minters Overview
Parameter/Feature OBL Admin Values Merkl Admin Values DSC Admin Values Support Service Values Description
TOKEN ZK ZK ZK ZK The token contract where new tokens will be minted, defined as IMintableAndDelegatable.
ADMIN DSC_OBL_Admin_Multisig DSC_Merkl_Admin_Multisig Ignite_Admin_Multisig Ignite_Admin_Multisig The address that is authorized to mint tokens. This is set as an immutable public address.
CAP 4,995,500 4,634,500 3,250,000 12,115,000 The maximum number of tokens that can be minted by this contract. This value is immutable.
minted - - - - Tracks the cumulative number of tokens that have been minted by the contract so far.
Mint Function Enabled, OBL can mint up to cap Enabled, Merkl can mint up to cap Enabled, DSC can mint up to cap Enabled, DSC can mint up to cap Allows minting a specified amount of tokens to a given address, provided the cap is not exceeded.
Authorization Check Admin-only (OBL) Admin-only (Merkl) Admin-only (DSC) Admin-only (DSC) Ensures that only the designated admin can mint tokens by checking if msg.sender is the ADMIN.
Cap Check Automatic, prevents exceeding cap Automatic, prevents exceeding cap Automatic, prevents exceeding cap Automatic, prevents exceeding cap Ensures that minting does not exceed the predefined cap by checking the sum of minted and _amount.
Error Handling Unauthorized access, cap exceeded Unauthorized access, cap exceeded Unauthorized access, cap exceeded Unauthorized access, cap exceeded Includes custom errors for unauthorized access (ZkCappedMinter__Unauthorized) and for attempts to mint tokens beyond the cap (ZkCappedMinter__CapExceeded).
Admin Management Governed by TA decisions Governed by TA decisions Governed by TA decisions Governed by TA decisions Specifies that the TA has the authority to change or remove the admin, (and maybe burn tokens) if metrics/milestones aren’t met, subject to a GovOps or Token proposal.

Accountability Framework

The accountability framework of the Ignite Program is designed to ensure transparency, responsiveness, and adherence to the program’s goals. This framework outlines the procedures for monitoring performance, addressing deviations from expected outcomes, and making necessary adjustments to the program.

Monitoring and Reporting

  • DSC Accountability: The multisig that has permission to mint and distribute any funds for the program have 6/8 signers from both the DSC and the Security Council. Each transaction requires at least one Security Council member to sign. This is to prevent the DSC from misusing any program funds.
  • Bi-weekly Reviews: The DeFi Steering Committee (DSC) will conduct bi-weekly reviews to assess the progress against the program’s success metrics. These reviews will involve detailed analysis provided by the Analytics Manager, focusing on metrics such as TVL growth, user engagement, and liquidity impacts. The DSC will release review notes to the ZKsync Governance Forum in the interest of transparency.
  • Seasonal Assessments (every three months): At the end of every season (three months), a comprehensive evaluation, created by the Analytics Manager, will be submitted to the DSC to compare longer-term trends against the program’s objectives. The program may be cancelled at the discretion of the DSC within 14 days of the end of a season in response to goals being missed by a margin greater than 25% or as a result of significant industry or market changes which require an adapted strategy in order to best serve the ZKsync protocol and community.

Approving Changes to Key Metrics

  • Proposal for Modification: Changes to key metrics can be proposed by the DSC if certain aspects of the program are found to be unrealistic or if external market conditions have shifted significantly. Such proposals should be put to the Token Assembly as a Governance Advisory Proposal (GAP) on the GovOps Governor and must detail the reasons for modification and expected impacts on the program’s goals. If a GAP is put to a vote and approved by the Token Assembly, the DSC is required to implement any changes specified.
  • Community Involvement: Seasonal Assessments and modifications to key metrics will be subject to community feedback through the ZKsync Governance Forum, ensuring that the ZK Nation community has the opportunity to voice their opinions.

Program Cancellation

  • Cancellation by DSC: The DSC may cancel the Ignite Program in response to a failure of the program to meet key metrics by a margin greater than 25%. The DSC has two opportunities to cancel the Ignite Program:

    1. The DSC may cancel the Season 2 and 3 of the program in the last 14 days of Season 1; or
    2. The DSC may cancel Season 3 of the program in the last 14 days of Season 2.

    Upon decision to cancel the program, the DSC is responsible for the final distribution of disbursements for work-to-date within seven days of the end of the active season. After all necessary tokens have been minted and distributed, the capped minters will be destroyed. There should not be any unallocated minted tokens from any of the capped minters.

  • Cancellation by Token Assembly: The Token Assembly may cancel the Ignite Program by passing a TPP on the Token Governor to revoke the minter role from all capped minters related to the Ignite Program.

    In the event that the Ignite Program is cancelled by the Token Assembly, by passing a proposal to remove the minter role from all capped minters, the DSC is responsible for making a final distribution of disbursements for work-to-date prior to the end of the timelock period for the relevant cancellation proposal. Upon execution of the proposal no further tokens will be able to be distributed as part of the Ignite Program.

Legal & Compliance

The DeFi Ignite Program will be administered in compliance with applicable law, including applicable sanctions and anti-money laundering rules and regulations.

9 Likes
88

Yep, send it to vote, enjoying the discussion thus far

89

This is a great idea that should be supported.

90

Could be a good idea to attract liquidity, if we have a look at other campaigns from Manta, Linea or Scroll.

91

very good start, i will vote

92

I’m really happy to see the inclusion of the program automation item into the proposal and I’m very much looking forward to supporting this TPP in it’s path towards progressive automation.

As I mentioned in my earlier post, I think it’s important to signal a commitment to decentralisation and progressive automation from the outset and I think this does that very clearly.

I think the willingness of the proposers and the DSC to bring in another evaluative pair of eyes into the programme bodes very well for the quality of oversight we can expect here. They didn’t need to do this, and I was invited in to observe and propose enhancements to the system, as well as beginning the process of building technical specifications and designs for paths towards a truly permissionless TPPs.

Overall, I’m very impressed with the willingness to take feedback and the openness to pushing the space forward on trustless execution. I will be reporting back to the token assembly with a full report and potential designs for technical enhancements and other permissionless pathways well in advance of the end of season one.

93

:memo: Proposal Review Call: TPP Ignite Program :memo:

Due to the attention the Ignite Program proposal has received on the forum, the ZKsync Governance Systems Team thought it would be helpful to organize an open Q&A for Delegates this week. Since the X Space today was more of a presentation of the proposal (find recording here), this session is intended to give Delegates an opportunity to ask questions about the proposal in real time.

Join Wednesday’s call to engage with the proposal authors and program admins, ask questions, and discuss key points with fellow Delegates.

When: Wednesday, October 23rd at 6pm CET / 12pm ET / 9am PT

:phone: Call link: https://meet.google.com/uii-pcve-eyq (also found on Delegate Call Calendar)

:movie_camera: The call will be recorded and shared on the new ZK Nation Youtube channel for those who cannot make it.

:information_source: Please note Delegates can request/organize these types of calls themselves at any time and I can add it to the Delegate Call Calendar.

4 Likes
94

looks good, thanks for helping achieving the growth of zk sync

95

Good work & good continuation

96

Congrats on the first proposal.LFG

97

Incentive programs like the one proposed by zkSync Ignite, which plans to distribute 325 million ZK tokens over 9 months, seem to follow a strategy similar to Arbitrum and Optimism. The primary goal here is to attract liquidity through short-term incentives. However, there’s a real risk that this approach will mainly draw in “mercenary capital”—liquidity that is only interested in benefiting from the temporary bonuses and will likely exit once the campaign ends.So far, there’s no clear strategy outlined in the zkSync Ignite proposal on how they plan to retain this liquidity after the program ends. For example, as seen with Arbitrum and Optimism, without a clear long-term retention plan, much of the liquidity attracted through these incentives tends to quickly move on to the next best opportunity once the rewards dry up. Additionally, the increase of 325 million tokens will result in about an 8.13% dilution of the total supply. This could further reduce the attractiveness of the platform post-incentive, as returns may become less appealing for investors compared to other opportunities in the market.

2 Likes
98

Looks great thanks for your work ! Let’s send it to vote :slight_smile:

99

Hello,
Overall, I do like the proposal and it can really attract more people on the ZKsync network and benefit the whole space. But I still have a couple questions:

  1. The proposal outlines a rapid two-week iteration cycle where token allocations are adjusted based on performance metrics. Could you clarify what specific data points will be prioritized in these bi-weekly reviews? How will the DeFi Steering Committee ensure that short-term fluctuations don’t negatively impact long-term strategy?

  2. The proposal currently suggests a weekly cadence for claiming rewards, with a feedback request from the community. What are the main considerations behind this choice? Have alternative cadences, such as bi-weekly or monthly, been evaluated for potential benefits in terms of reducing gas costs or enhancing user experience?

In advance, thank you for your answers and your time :slight_smile:
Keep up the good work !

1 Like
100

Thanks for the well-crafted proposal @BaptistG. Some questions:

  1. Could you elaborate more on the quantum of bonuses that would be awarded to KYC-ed DeFi protocols? When would the KYC be conducted, and when do the protocols have to indicate they are willing to undergo KYC?

  2. What kind of information will be needed in the KYC process, and who would be conducting the KYC?

  3. Will the program cover the Merkl integration costs for projects that are not currently integrated with Merkl on ZKsync?

1 Like
101

Hello,

I think the Ignite Program is a great idea to bootstrap liquidity and enable devs to focus on building. Looking at the compensation compared to the program size its also reasonable.
But what I still want to mention is that the DAO should prepare a budget per year and split it into different working areas.
Like bootstrapping programs like this one, potential future delegate compensation, advisory services and so on.

Its important to have a clear guide on this and a fixed budget otherwise the DAO will pretty fast overspend and there is no good overview where the money is flowing, how it is being used and what kind of effect it has on the chain.

1 Like