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

starkleio.eth · October 23, 2024, 8:20am

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

kumosoukai.eth · October 23, 2024, 9:40am

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:

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?
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
Keep up the good work !

chefmaroon · October 23, 2024, 9:48am

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

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?
What kind of information will be needed in the KYC process, and who would be conducting the KYC?
Will the program cover the Merkl integration costs for projects that are not currently integrated with Merkl on ZKsync?

Ezr3al · October 23, 2024, 10:55am

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.

Benido · October 23, 2024, 1:03pm

+1 wrt to budget and planning.
Was thinking about this since some days, but we should create a new thread for this.

Sinkas · October 23, 2024, 2:12pm

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

To start, we want to thank Merkl for the work they put into the proposal and for kicking off the discussion. We appreciate both the proactiveness and the enthusiasm to start moving things forward and we hope to continue seeing the same level of involvement going forward.

Having been in crypto, and more specifically, DAOs, for quite some time, we understand the need for an incentives program to remain competitive in the current landscape. That’s even more true for a relatively new DAO looking to attract builders and users. We should, however, look at the learnings from other such programs carried out in other protocols to avoid some common pitfalls.

Based on our experience as active delegates in other protocols (e.g., Arbitrum and Optimism), we want to draw attention to the fact that the program, as it’s currently described, could be significantly improved. Right now, the proposal lacks many crucial details that shouldn’t be overlooked, as they are bound to cause problems down the line.

Below, we’ve attempted to capture some of the points that we should discuss further before jumpstarting a ~$45,000,000 program.

Lack of specific goals

Right now, the goals of the program are described as

…increase DeFi TVL…

and

…[increase] liquidity depth of strategic DeFi assets (ZK, ETH, stablecoins, etc) for both existing and new DeFi projects on ZKsync Era.

These goals are too vague to be the drivers of a 45M program. Firstly, there are many incentive mechanisms through which those goals can be achieved. For example, instead of just incentivizing liquidity DAO could do a protocol-owned liquidity (POL) program and use the treasury’s funds to acquire other assets and then use them to provide liquidity in various pools in different dApps. There are no details in the proposal regarding which strategies are going to be explored and how are they going to be assessed.

Secondly, these goals do not address any of the following things.

Increase in sticky capital that remains in ZKsync after incentives end.
Increase in users transacting on the chain.
Increase of protocols being deployed on ZKsync.

Also, while some metrics are described, there is no mention of what kind of increase we’re aiming for with the program, which by default would make anything a ‘success’ by the standards we have, or rather haven’t, set.

Lack of input from strategic stakeholders

While this forum post contains several comments, there isn’t much input from strategic stakeholders of the ZKsync ecosystem, including Matter Labs, ZK Foundation, and major ZK protocols.

Considering their familiarity with the ecosystem, as well as the fact that they stand to benefit from such a program, we should consider their input and involve them in the process.

Program mechanics

Only allowing protocols to apply within a 1-week window each season feels too small of a time window and is bound to cause problems, either by bottlenecking the program providers or creating an unfair environment for protocols that miss the application deadline.

We would suggest either extending the application window, or allowing protocols to apply in perpetuity (or several different time windows) if they meet the requirements.

Marketing

The proposal includes a marketing budget that will be at the discretion of the DSC, but it doesn’t mention anything in regard to the marketing itself. We understand that a marketing agency will be hired to carry out the marketing, but we’d appreciate at least some more information about the strategy, the messaging, the target audience, and the available channels. Right now, all these things are omitted.

Synergy between protocols

For the program to be more likely to succeed, we suggest that participating protocols and service providers collaborate not only in setting up the program but also in its marketing and seek synergies across the whole ecosystem. Protocols that are receiving incentives should ensure that they communicate that fact with their community, not only in social media channels (e.g. Twitter or Discord), but also on their platform (e.g. a banner on the top of their website). Moreover, they should proactively look for ways to cooperate with other projects in the ecosystem to boost their offering, for example a DeFi protocol can think about how can they utilize a zkSync game audience to attract them to trying out DeFi, or they can think how their users could use Lens in order to promote the fact that they received DeFi incentives (and by doing so they could receive some additional multiplier for example).

The scope of work for service providers

While the cost breakdown shows how the service provider compensation is going to be split across different roles, it does not show what is the scope of work for all the staff that is going to be working on this program as well, and it does not explain why we need so many resources to handle this program. The rates presented in the proposal are relatively high; we are not convinced that we should be locking ourselves for 9 months with this structure, primarily as what those teams will be doing daily for 9 months is vaguely described right now.

In addition, we would like to suggest opening up some opportunities for other service providers to get involved in this program as well. While it’s fine to have OBL as the main program analyst responsible for the entire program, we would like to have some open door for other experts in the field to propose their solutions and ideas based on the public data dashboards. We can set aside a separate budget for such vendors to get involved down the road without replacing the main program analyst or significantly altering the program.

Capped Minters

In terms of the capped minters:

Why is the proposal suggesting we use 6 for the incentives and 4 for administrative expenses? Why not just 1, or why not 4+6, or 8+10, or 15 + 1, or any other potential combination? We’d like to understand if there’s a reason behind it or if it’s simply an arbitrary decision.
How will the capped minters distribute the tokens, and what is the process for a delegate to propose stopping the distribution?

Miscellaneous points

The whole proposal has nothing to do with the TPP spirit towards which ZKsync’s governance was moving. Instead, this proposal is more like any traditional grant programs with funds allocated subjectively according to some allocation schema. While we agree with some previous commenters that this is not necessarily bad, it is worth noting as it will set a precedent.
The amended version removed the KYC/KYB requirement for participating protocols. We’re not quite sure why that change was introduced. Requiring KYC/KYB from participating protocols is a good way to safeguard against potentially malicious applications and also a mechanism to hold protocols accountable for the use of funds.
The compensation for the program contributors includes bonus allocations for exceeding thresholds. However, as noted above, the thresholds aren’t specified.

olawaledaniel.eth · October 23, 2024, 3:34pm

This is a groundbreaking proposal that will not only help push the chain up, but it will clean up the system for an healthy community. Thank you to everyone who contributed to this.

404Gov · October 23, 2024, 9:35pm

We want to thank @BaptistG for bringing this proposal forward. After reviewing the design and proposed implementation, we are pleased to support this first TPP for the DAO. We are glad to see that the program is designed with a focus on user experience and sustainable growth.

We believe 300M in incentives over 9 months is a reasonable allocation to attract liquidity and assets to the Era chain, bolstering base liquidity for the elastic chain in preparation for future grant programs. Additionally, we appreciate the focus on blue-chip asset pools, strategic trading pairs, ZKsync-native asset pools, and stablecoin pools to create a strong foundation for liquidity on the Era chain.

Based on our experience overseeing incentive programs in other DAOs, this proposal includes many elements that stand out. The inclusion of a marketing/branding strategy, a feedback loop for continuous learning, community involvement, and third-party audits are all refreshing to see.

While we would prefer more specific target objectives/KPIs for the incentives, we are comfortable with the approach, as the program is designed with a focus on iteration across multiple seasons.

Lastly, we would like to see all parties disclose any conflicts of interest regarding protocols or apps before the program starts, specifically OBL and the DSC, as the two parties are recommending and approving protocols/apps.

Benido · October 24, 2024, 7:25am

First of all thank you all for taking the time on Tuesday and yesterday to present the TPP and discuss questions. I have a better picture of it now, both because it was more than just the written proposal and because a lot of details and arguments were added in these two events.

I agree with and support a data-driven approach that’s iterating on the learnings. I still would like to add some feedback and potential changes:

In the spirit of what TPPs are supposed to be one way I would like to see clear goals for the first two seasons. If these KPIs are not met, the following season should be automatically canceled.
I hope this can be middle ground between the assumption that “we know we need to do a big TPP to attract 1B TVL” (not verbatim, quote by Karthik in the call yesterday) and the position of a lot of delegates (including myself) that are at least cautious when it comes spending 325M ZK in one vote. I understand that the Token Assembly could technically stop season 2 and 3, but I think that having clear goals and an “MVP” for automation is important for transparency, accountability and to kick start TPPs in a more automated way than comparable programs.
Some thoughts around compensation and bonuses, especially in the case of OBL:
3923000 ZK for 3240 hours is somewhere between 120 USD/ hour and 150 USD/ hour (calculated with 10c/ZK, 30d MA is more like 13c/ZK)
I think spending 120 USD/h and even 150 USD/h is not unreasonable for freelance/ project work in their area of expertise.
I also understand and support the idea of bonuses as incentives to create the best outcomes for the protocol.
But combining the two seems to be a best of both worlds for OBL. So my request would be either to decrease hourly rates or limit/ cut bonuses (or a combination of the two)
On top bonus goals and bonus structure/ thresholds have to be defined pre voting. I understand the iterative nature of the program and that this is a not an easy task, but we are talking about 0.5% of overall program cost just as a bonus for OBL.
One or best case even two delegates should be added to and be part of the DSC. I understand the need to create a nimble set up that can make fast decisions every two weeks based on the analysis and proposals of OBL. At the same time I think adding one or two more people will not make a huge difference wrt coordination.
This allows us delegates to better understand the decision making process, improve transparency and hopefully acceptance of the program. In case of resignations of DSC members this makes the process to fill vacant seats easier, without a delegate being member the DSC making these decisions seems a no-go for me. Also these representatives will learn about the edge cases, today’s technical limitations etc. and can bring in that knowledge in future proposals.

Let me add as a general remark: I think what TPP1 proposes and the delegates want especially when it comes to budget and how the ZK is spent is actually not that far off. Both want to start slowly and increase after the effectiveness of the incentives are measurable and proven. My hope would be that adding season goals + delegates to the DSC can combine these two ideas. Hence I generally support this proposal if we can automate and “decentralize” the decision making process a little more.

0x647703Ea4880644AC7 · October 24, 2024, 10:33am

Yes Send it! LFG! I love the Idea and this is only bullish for Zksnyc fam.

cap · October 24, 2024, 11:21am

To clarify and consolidate my thoughts and comments, since the V2 version of this proposal has been put forth.

Thanks for clarifying and improving on existing concerns @BaptistG.

My previous concerns:

lack of automation that would make the proposal a self-executing pipeline of token distribution based on predefined onchain criteria and KPIs (as long as the team in charge progressively automates the process, I’m fine with this)
size of the allocation (I’ve come to change my mind here)
Sybil farming / gaming the system (eliminated through your project selection)
User retention (or stickiness) strategy – I’d love this to be kept in mind with every decision we make.
Setting the precedent for future TPPs.

My biggest driver for deciding to vote for this proposal is that the benefits heavily outweigh the concerns, given the quality of the proposal and the proposers who will be conducting this TPP. And even though I think there’s room for improvement in certain areas, incremental changes and improvements will naturally happen throughout the program. I would also be in favour of launching sooner rather than later, and cut down the time to market. Therefore, I would still vote yes.

I want to echo this:

If we don’t have even an estimate (target) of how much TVL we’re aiming for (since that’s the metric upon which the success of this proposal is evaluated), we can’t know whether the proposal is a success or not. I propose to have a target in mind for every 3 months and continually update the strategy based on 2-week reviews as planned.

It’s my understanding that this TPP optimizes for increasing TVL as the #1 KPI, not necessarily increasing Defi-related activity. That would be a different type of proposal that someone is hopefully working on.

+1 here.

web3-id.eth · October 24, 2024, 1:23pm

This is a great initiative! Let’s support the team and I’m sure it won’t let us down.

pengu · October 24, 2024, 1:25pm

This could be something that will almost solve the problem of lack of liquidity in the long run I am supporting it

Metta · October 24, 2024, 1:53pm

GM. Very much agree. Elastic Chain indeed needs a liquidity hub.
Just wonder about the $1MM TVL condition? That might create unfair advantages and limit innovation from new apps? Here is an example.

We are building SaveTogether and planning to deploy on zkSync. SaveTogether is a Saving Layer between Stablecoin Holders and DeFi yield like AAVE. The concept is similar to PoolTogether but we focus solely on Stablecoin and also add new upgrades.

Because SaveTogether gamifies the saving, we believe that liquidity incentives through SaveTogether are much more efficient and sticky than plain incentives on AAVE for pure capital return.

The $1MM TVL condition will auto cancel new apps like SaveTogether and other new apps. Therefore we propose a solution: make separate tracks for mature apps with TVL over $1MM and another track for new apps with TVL under $1MM. The token incentive for mature apps may be 90% of 300M and for new apps: 10% of 300M. This will create a new wave of apps coming to the zkSync chain.
Google has “Other Bets” to foster innovation. I hope Elastic Chain has that too.

drnick · October 24, 2024, 3:16pm

I think the point here regarding the application window is a good one, given the iterative nature of the programme it could be possible to have a more dynamic approach to onboarding new projects to the programme.

I had similar concerns about the precedent set by this approach away from the TPP ‘spirit’ of permissionless pathways, but I think this has been sensibly offset by the recent update to the proposal that opens up a path to using Ignite as a jump off for that work, which I think does demonstrate a credible willingness to strive for the wider automation vision from the outset.

I do very much like the POL idea, but architecting that at the outset will introduce a lot of complexity and would slow things down considerably. It might be a good season 3 goal to nudge into this kind of activity.

While the rest of your points are good, I think it’s generally worth stressing that this is a programme that has multiple waypoints, is highly iterative and with an ability to be halted by the token assembly. It would be great if this DAO doesn’t fall into the over cautiousness and ballooning proposal traps that cripples other DAOs and has more of a pro-active move and iterate approach. I think it both has a chance of outperforming the other liquidity programmes we’ve seen elsewhere and has the ability to be steered throughout.

It’s going to be a few months before the first proposal is passed soon and the worst precedent we can set is inertia IMO. It’s time to ship.

nordstream2.eth · October 24, 2024, 8:32pm

boom! I like this! it will very likely attract a lot of capital. What is the game plan for after the seasons though? Wont they just leave?

BaptistG · October 25, 2024, 1:05am

We truly appreciate the continued, thoughtful dialogue and feedback from the community. We address several of the specific points below, but want to make an overall call-out to stress the contrast of and innovation in program design compared to prior programs, such as STIP. We explicitly have incorporated many of the key learnings from these past programs precisely to avoid common pitfalls. This includes having rewards distributed directly to users (vs. protocols) to avoid biased and short-term strategies, rapid iteration and experimentation via data-driven techniques, a focus on demand-side metrics and sustainability, and a budget to offer strong UX + effective marketing to maximize ROI for token holders.

Re: lack of specific goals:

We add further clarity to the goals below, and will update the proposal to reflect.

The top-level goals of this program are to 1) increase DeFi liquidity (supply side), 2) enhance price execution for strategic pairs (stablecoins, ETH, ZK, etc), and 3) generate organic fees to LPs (demand side). Achieving these 3 goals ensures a sustainable marketplace between users/traders and liquidity providers with sufficient asset depth that ensures a healthy pricing equilibrium to support value exchange across the Elastic Chain. While we will measure other metrics, these are the primary metrics that will be the success criteria of the program and will be detailed in bi-weekly reports and public dashboards.

We recognize it’s important to provide directional guidance on these metrics so the community has a sense of what success looks like. This guidance below comes from 1) past programs that OpenBlock Labs has driven, and 2) current state of the ZKsync Era DeFi ecosystem.

Our target is to increase DeFi liquidity by $5 - $10 for every $1 of incentive allocated (both in absolute and relative ETH terms to normalize market fluctuations.) This roughly translates to increasing DeFi liquidity by $205MM-$410MM over 9 months. This is a broad range due to the fact that there are inputs which drive this that we don’t control (e.g. macro market conditions, price of ETH, etc). However, in a vacuum, achieving towards the high end of this spectrum (or beyond) indicates success for this metric, while achieving towards the bottom end of this spectrum (or below) is an indication of underperformance.
Our target is to improve price execution to achieve:
- Maximum of 5bps slippage up to $1M trades on stable-stable pairs
- Maximum of 10bps slippage up $100K trades, and maximum of 120bps slippage up to $1M trades on key stable-volatile pairs (eg ETH-USDC)
On the demand side, our target is to generate $3 in fees for liquidity providers for every $1 incentive allocated. This translates to a goal of ~$120MM in LP fees generated over 9 months. Generating sustainable demand is critical to maintaining an active DeFi ecosystem when incentives go away. To this end, we target to retain $0.6 of DeFi liquidity post-incentives (eg “sticky capital”) for every $1 of DeFi TVL growth.

To facilitate these goals, we anticipate Season 1 to largely focus on increasing the supply side and doing extensive experimentation to identify the most impactful strategies. In later seasons, we will double down on successful initiatives from Season 1 and shift our attention more on demand-side strategies, which includes offering incentives to traders and verified human users using verification measures such as Coinbase account linkage or ZK attestations through protocols like OBL’s Universal Data Protocol.

Re: lack of input from strategic stakeholders:

Both Matter Labs and the ZKsync Foundation have consistently provided key input to the ZKsync Ignite Program design. To ensure this strategic input and feedback persists, Karthik Senthil (head of ZKsync Era) has been included in the DeFi Steering committee. In addition, nearly all major ZKsync Era DeFi protocols were consulted for their inputs and recommendations during the creation of this proposal, alongside delegates, VCs and various DeFi experts.

Re: Application mechanics:

Thank you for the feedback on a one week application period not being sufficient. To help mitigate this, we have already opened up the application process for DeFi protocols to apply for the program (applications will not be reviewed until after the vote concludes).

To further mitigate, we will amend the proposal to allow for an open application window for DeFi protocols to apply for the program instead of simply waiting for the final 2 weeks window of every season. OpenBlock labs will evaluate new applications and can recommend applicants for inclusion to the DSC on a monthly basis. The DSC will have the authority to approve these applications.

Re: Application Requirement of $1MM DeFi TVL

There have been several comments from the forum and the open delegate call about the $1MM DeFi TVL requirement, and how this may detract newer or more nascent applications to build in the ZKsync ecosystem. While we firmly believe this is the right requirement for Season 1 as we want to focus on a small set of reasonably mature applications with good UX to provide the best possible experience for users, we recognize the benefit of taking bets on newer projects/builders. We have updated the proposal to give the DSC authority to modify application criteria, including the DeFi TVL requirement, at the beginning of Season 2 or 3, if needed.

Re: Marketing

The DSC has an agency in mind to help operationalize this strategy which will include:

Partner marketing: This will likely be the most effective marketing tactic. We plan to include both direct beneficiaries (protocols chosen by the DSC) and indirect beneficiaries (projects not selected but still benefit from attention) will regularly participate in co-marketing campaigns. This could include onchain campaigns, leveraging popular games or communities, contests, and other methods this chosen agency has experience with.
Distribution launch partners: Collaborate with strategic partners like wallets, exchanges, or bridges to raise awareness to their audiences (similar to JumperExchange’s involvement with SuperFest)
Direct Paid Marketing (via newsletters, podcasts, and crypto media channels)
UGC Campaign: We will likely execute a user-generated-content campaign for DeFi/crypto content creators.
Twitter/Telegram: We plan to use the existing Twitter and Telegram community to continually communicate updates and opportunities, and create a place for participants to share and learn together. These channels will be moderated.

Re: Synergy between protocols

We fully agree. One of the key learnings from talking to other teams is how important partner marketing is, and this will be our #1 priority. Both co-marketing between partners and also pushing the message out on partner channels. As mentioned above, partner marketing includes direct beneficiaries (protocols chosen by the DSC) and indirect beneficiaries (projects not selected but still benefit from attention).

Re: The scope of work for service providers

As mentioned in the initial FAQ earlier in the thread, the resources needed for the program are an investment in the program’s success. This program will require full-time staff to continually design experiments, analyze results, and incorporate learnings into the next set of experiments. of work for the staff

We agree that having an opportunity for other service providers or community members to propose their solutions will be helpful. We will amend the proposal to include budget for an “Ideas Bounty” that reward users for ideas that are accepted.

Re: Capped Minters

The capped minters for the incentives have been split to balance program allocation modularity and security. The number 6 was chosen because there are 3 seasons, and the team’s operational design followed this same multiplier (two (2) per season). Other designs, such as having one capped minter allocated to every two weeks were considered, however, there is significant uncertainty around the experiment outcomes, so we didn’t want to overfit the solution.

The six (6) capped minters were also chosen such that a change to the overall program could remove/add different capped minters without impacting one which is currently “live” (being used in real-time for the continuation of the program). Lastly, splitting up the capped minters was recommended during a security review, such that permissions to mint were not all anchored on a single minter. During this design discussion, additional possible improvements were uncovered, which are documented in Notion here.

Similarly, the capped minters for the program administration were created in a modular manner. This provides similar benefits on program operations, as well as easier onchain monitoring. For example, anyone can view and track operational token allocations for each of the individual capped minters.

As described in the proposal, all capped minters have an assigned administrator address. Each capped minter administrator includes the DSC multisig, and, in specific cases, a second administrator such as OBL or Merkl. This administrator can call the mint method, and assign a recipient of the minting action.

Should the Token Assembly decide to cancel the program, a sponsoring Delegate can place a proposal onchain via the Token Governor. This proposal would include an onchain action (calldata) that revokes the ZK token minter_role from the specific capped minter contracts. As noted above, this proposal can revoke one or multiple minter_roles, as well as deploy new capped minters if needed. This allows the Token Assembly to adjust the program should it be needed.

Re: token mechanics

Token Mechanics must mature over time. We agree that the level of automation in this first TPP does not achieve the ambition of the token mechanics vision. However, we have activated a dedicated workstream to continuously improve the program given the known constraints today. Furthermore, it’s worth noting that this program has already improved token mechanics design. As described in the previous post:

“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 1, which the Association has documented.”

As a precedent, this TPP should set an example of the use of capped minters, distributors, veto councils, and workstreams for continuous automation. We expect and fully encourage the community to continue pushing innovation forward and hold this program accountable to ongoing improvements in token mechanics.

Re: Conflict of Interest

There have been questions from delegates asking about any potential of conflict risks regarding the DSC and vendors. We want to clarify that no members of the DSC or 3P vendors (OpenBlock Labs, Merkel, etc) have a conflict of interest with any potential DeFi app/protocol that may apply to the program. This was specifically kept in mind while selecting potential members of the DSC and the program service providers.

Re: KYC

The amended version of the proposal had removed the original KYC/KYB requirement for DeFi protocols to participate in the program. The reasoning for this removal was due to the fact that DeFi protocols will not be handling any ZK tokens from the Token Assembly. All tokens allocated to user rewards will be streamed directly to users, via the ZKsync Ignite Program Website, operated by Merkl. All service providers will need to KYC/KYB.

All DeFi protocols will need to 1) Fill out an application to be reviewed by OBL & approved by the DSC, 2) Be live on ZKsync Era, 3) Have a minimum of $1M USD in TVL; among other requirements. We believe these requirements as well as the personal review/approval of OBL + DSC create an effective moat around the program to prevent bad actors from participating. Finally, in order to be eligible to receive the extra KPI bonus allocation for DeFi protocols, protocols will need KYC/KYB to be considered before the end of the program.

BaptistG · October 25, 2024, 1:08am

[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 (supply side), strategic asset depth to minimize slippage (price execution), and organic fees generated to LPs (demand side) [AMENDMENT 24-10-2024]
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 incentives 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?

Boost Innovation: builders can focus on finding product-market-fit without the burden of bootstrapping liquidity, accelerating time-to-market and impact,
Seamless DeFi Asset Exchange: users benefit from low-slippage asset exchanges using proven DeFi protocols, creating a smooth and reliable experience, and
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?

Unmatched Security: as a ZK rollup on Ethereum, ZKsync Era offers the strongest security guarantees with ZK proofs and fast finality,
Established DeFi Ecosystem: ZKsync Era has already integrated with key foundational primitives (including native USDC) and blue-chip DEX and lending protocols, and
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?

Deep Liquidity: reducing slippage across volatile and stable assets such as: ETH, USDC, USDT, WBTC, etc.,
Incentives for Participation: attracting liquidity, users, and builders through targeted rewards, and
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:

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

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

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

Primary Metrics [AMENDMENT 24-10-2024]

The top-level goals of this program are to 1) increase DeFi liquidity (supply side), 2) enhance price execution for strategic pairs (stablecoins, ETH, ZK, etc), and 3) generate organic fees to LPs (demand side). Achieving these 3 goals ensures a sustainable marketplace between users/traders and liquidity providers with sufficient asset depth that ensures a healthy pricing equilibrium to support value exchange across the Elastic Chain. Both primary metrics as well as secondary metrics such as natively minted liquidity, DEX volume, overall liquiduity and overall fees will be detailed in bi-weekly reports and public dashboards.

To give the community a sense of what success will be measured, this proposal is providing directional guidance on primary metrics. This guidance below comes from 1) past programs that OpenBlock Labs has driven, and 2) current state of the ZKsync Era DeFi ecosystem.

Our target is to increase DeFi liquidity by $5 - $10 for every $1 of incentive allocated (measured both in absolute and relative ETH terms) This roughly translates to increasing DeFi liquidity by $205MM-$410MM over 9 months. This is a broad range due to the fact that there are inputs which drive this that we do not control (eg macro market conditions, price of ETH, etc). However, in a vacuum, achieving towards the high end of this spectrum (or beyond) indicates success for this metric, while achieving towards the bottom end of this spectrum (or below) is an indication of underperformance.
Our target is to improve price execution to achieve:
- Maximum of 5bps slippage up to $1M trades on stable-stable pairs
- Maximum of 10bps slippage up to $100K trades, and maximum of 120bps slippage up to $1M trades on key stable-volatile pairs (e.g. ETH-USDC)
On the demand side, our target is to generate $3 in fees for liquidity providers for every $1 incentive allocated, or roughly ~$120MM in LP fees generated over 9 months. Generating sustainable demand is critical to maintaining an active DeFi ecosystem when incentives go away. To this end, we are targeting to retain $0.6 of DeFi liquidity post-incentives (eg “sticky capital”) for every $1 of DeFi liquidity growth.

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

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 24-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 to 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 increasing supply side liquidity through blue-chip assets, strategic trading pairs, ZKsync-native assets, and stablecoins to establish a balanced and robust liquidity foundation, alongside some “shots on goal” for assets that might offer strategic differentiation vs. other ecosystems. In later seasons, we will double down on successful experiments from earlier seasons and shift our attention to more demand-side strategies. 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.

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:

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.
Deploy a working end-to-end template of specification on testnet AND ZKsync Era mainnet (excluding audit) proving the specification works in practice.
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 [AMENDMENT 24-10-2024]

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.

Program Set-Up (~Oct 2024 → ~Dec 2024)
1. Proposal posted on Forum (Oct 17th)
2. Proposal voting starts (~Nov 4th)
3. Proposal voting ends (~Nov 12-18th)
4. Proposal execution (~Nov 13-19th)
5. Application Submission Ends + DeFi Protocol Approvals Announced (~Nov 20-26th)
6. Application Integration with OpenBlock Labs and Merkl + QA (~late Nov)
7. Ignite Launch (~late Nov-early Dec)
Season 1 (~Dec 2024 → ~Feb 2025)
Season 2 (~March 2025 → ~May 2025)
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 [AMENDMENT 24-10-2024]

If this program is approved by the Token Assembly, the program will span across three, 3-month long seasons for a total of 9 months. The application period for DeFi protocols will remain open for the entire duration of the program. OpenBlock Labs will review new applications on a rolling basis and can recommend applicants for inclusion to the DSC at the end of each month of the program. The DSC will have the authority to approve or reject these applications.

For the 1st Season of the Ignite program, the cutoff date for DeFi protocols to apply for the program is 1 week (7 days) post-execution of the program. Please refer to the timeline above for dates. Afterwards the ongoing rolling admissions of DeFi protocols at the end of each month will begin. [Amendment 24-OCT-2024] 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.

[AMENDMENT 24-Oct-2024] The DSC has the authority to modify the above criteria at the beginning of Season 2 or 3 in the best interest of the program.

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:

Lindsey Winder, Hedgey Finance
Michael Lewellen, OpenZeppelin
Kerman Kohli, 0xarc
Ashwath Balakrishnan, Delphi Digital
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,120,000 ZK tokens (3.73% of the program budget)

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 250,000 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]
New Ideas Bounty: We are establishing a new application process where 3rd party service providers may propose new ideas, integrations, and technology to the Ignite program to help the program run more effectively. This will be an open application available to any service provider in the space. In their application they will need to outline how much budget they are requesting and for what purpose. The compensation for this bounty will be taken from the “Reserve for Unforeseen Expenses”. [AMENDMENT 24-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,120,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.

kittymeowcat.eth · October 25, 2024, 2:22am

great proposal! Waiting big news

theshelb · October 25, 2024, 4:34am

Recordings from X Space & Proposal Review call:

Listen to the recording of the X space from 22.10. where proposal authors and administrators give an overview of the Ignite Program proposal.

Watch the recording of the proposal Q&A from 23.10. where proposal authors and administrators answered questions from Delegates about the Ignite Program proposal.