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

We have reviewed the proposal and decided to support and vote FOR it. The program is well-structured, divided into three seasons, with each season assessing the program’s outcomes to identify any necessary adjustments. The incentives offered are likely to attract more liquidity deposits, as protocols in ZKsync are expected to yield high returns. This program is anticipated to increase both activity and Total Value Locked (TVL) in ZKsync.

What the source of 325 million Zk token ? Does it mean Total Supply ZK 21 billion will then became 21 bill. + 325 mill. ZK ? :moneybag:

Voted For: After reviewing the proposal, I believe this will benefit the zkSync ecosystem. Supporting programs like this is important for keeping strong projects in the space. I do expect the team to take a professional approach, as this is ZKNation’s first TPP and should set an example for future TPPs. I also look forward to receiving regular reports and updates on the program’s progress.

During my review of the proposal, I noticed that some of the multisigs mentioned, such as the Ignite Admin Multisig, have not yet been verified. We cannot vote on this proposal until all referenced contracts are properly verified. Contract verification is crucial, as it allows us to confirm that the code and parameters align with what is stated in the proposal. Given the growing length of this discussion thread, it might be more practical to address the resolution of this issue in a separate thread.

Hey @keating , very good catch thank you. These are the gnosis safes, I didn’t even think of checking if these were verified contracts (I assumed they were).

I have just reached out to the Safe team to figure this out, we’ll keep you posted!

Thanks again for sharing this

1 Like

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.

We’re voting FOR this proposal, with our full rationale for the decision outlined below.

First, we want to thank @BaptistG for responding to delegates’ comments, addressing concerns, and incorporating feedback. The extensive communication and multiple iterations of the proposal to address most points didn’t go unnoticed.

In our original comment, we expressed some of our concerns about seven key areas of the proposal. Some of them have been adequately addressed since, and some others, while addressed, haven’t fully convinced us. Specifically:

  1. Lack of specific goals

We appreciate the proposal’s revision to include more specific goals, but for a program of that size, we’d like to see some goals that are not merely tied to increasing the TVL. We’d love to see some attempt to also increase user acquisition and retention, as well as an increased number of projects choosing to deploy on ZKsync as a result of the program.

  1. Lack of input from strategic stakeholders

Upon further discussing this with other stakeholders, we realized that the proposal did, in fact, receive input from strategic stakeholders and wasn’t a solo endeavor.

  1. Application Mechanics

The application window has been amended to allow protocols to apply in perpetuity and give the DSC the authority to accept these applications on a monthly basis. We find this to be an appropriate solution.

  1. Marketing

We understand that the marketing agency will probably be the one to design most things in regard to marketing, including the messaging, different campaigns, and the KPIs to measure its success. While we do not want to infringe on the ability of the DSC to select the marketing agency they’ll work with, we believe the DAO should at least have a say in whether the DSC’s choice, as well as the agency’s marketing efforts, are appropriate and worth the allocated budget.

  1. Synergy between protocols

The synergy we expect to see between protocols goes beyond simple co-marketing campaigns, although that’s a great place to start. We want to see the DSC or OBL facilitate the coordination between protocols that are receiving incentives to explore synergies that will help supercharge their impact.

  1. Scope of work for service providers

We understand that the money spent for the execution of the program is basically an investment into its success, and therefore, by extension, the success of ZKsync. However, there’s little justification for the amount of resources required. To be clear, we’re not suggesting that we’re allocating too many resources. We simply don’t know what we’re allocating the resources for.

On a similar note, earmarking funds for ‘Ideas Bounties’ is a good way to allow other service providers to potentially contribute to the program and positively influence it and its impact. These ‘Idea Bounties’ should fall under the discretion of the DSC.

  1. Number of Capped Minters

The response provided satisfied our curiosity

While the aforementioned points have been addressed to an extent, we are still skeptical about the program and the results it will yield. For that reason, we’re committed to monitoring the program’s progress closely and we’ll be looking to hold everyone involved to a high standard.

In our mind, all participants of the program, including OpenBlock Labs and members of the DSC, are not just the operational executors of it, but also the program (and its success) owners. We expect OBL to closely monitor all projects receiving incentives and inform the DSC on any potential problems, who will also, in turn, inform the DAO.

We want to avoid a situation where the program concludes, and only then we learn about complications, errors, challenges or failures. Reflection periods between Seasons should be about figuring out how to mitigate problems, not about figuring out what the problems were.

3 Likes

Hello everyone,

As a member of the Ignite Program’s DeFi Steering Committee (DSC), I’m grateful to see the amount of support and feedback this proposal has received.

As a ZkSync delegate, I am voting to ABSTAIN as I will be receiving compensation as a member of DSC, which can be considered a conflict of interest. I am still supportive of the Ignite Program and I hope the remainder of ZkSync delegates vote in support.

2 Likes

An update on this, the contracts seem to be verified on a different block explorer found here.

After careful evaluation, we endorse and will vote in favor of the proposal. The program’s three-season structure provides clear checkpoints for performance assessment and optimization. We believe the incentive framework will effectively attract liquidity providers, particularly given the projected high yields from ZKsync protocols. The initiative shows strong potential to drive both user engagement and TVL growth within the ZKsync ecosystem.

This comment has been formulated by the Treasure Delegate Council (TDC), an entity recently stood up to represent Treasure within ZKsync governance.

We are supportive of the Ignite Program, and will therefore vote FOR.

We believe that having sufficient liquidity to serve all chains within the Elastic network of chains is a logical and foundational start to accelerating usage of ZK chains. While we would like to see future TPPs employ fewer centralized mechanics and take advantage of decentralized and automated solutions to measure metrics and determine token program allocations, we recognize that the relative centralized nature of the structure is a natural starting point during the early stages of ZKsync in order to allow future programs to iterate upon early successes.

Decisions and actions made now can have a profound effect on governance moving forward, and must be well thought out. The TDC would also like to note that the benefit of being able to continuously monitor program effectiveness through the seasonal review structure and the two week iteration cycle is a substantial improvement over similar incentive programs that we have seen before. This means that data collected can be directly applied to be able to adapt to the market, effectuate successful incentive designs and directly iterate on incentive and program automation mechanisms.

Recommendations

  • Give the delegates better insight into the data analysis OBL will be providing for ZKsync, and what measures are being used.
  • Transparent insight and argumentation into OBL’s specific ZK token allocations in the bi-weekly reviews of the program. Over-compensation has been an issue in past DAO programs and we should look to balance attracting talent with effective spending.
  • @baptistG rightfully mentions that the target to ‘increase DeFi liquidity by $5 - $10 for every $1 of incentive allocated’ is dependent on a broad range of factors, such as ‘macro market conditions’. What we are trying to measure with this target is for the most part how well ZKsync is performing in terms of liquidity. It is a good measure in isolation. Yet, we can also measure liquidity performance as a measure of market share, so that we can remove macro market conditions as a confounding variable and measure the direct impact of the Ignite Program on the share of total Ethereum liquidity. We therefore recommend also incorporating a target that compares ZKsync’s liquidity in terms of percentage of market share within Ethereum.
1 Like

We support this proposal as a first step to bootstrap liquidity in the ZKsync ecosystem. The proposed framework provides a well-structured approach to establish ZKsync Era as a DeFi liquidity hub, which is crucial for the ecosystem’s growth.

The token allocation is well-balanced, with clear metrics for success including DeFi liquidity growth and specific slippage targets. The three-season structure with bi-weekly adjustments enables agile responses to market conditions.

The current setup with human oversight makes sense given the program’s complexity and compliance requirements, though we look forward to seeing more automation in future iterations. The dedicated R&D workstream led by Dr. Nick to specify automated and permissionless designs is a promising addition.

The accountability framework with multiple checkpoints and cancellation options provides robust safeguards. Both the DSC and Token Assembly maintain significant control over the program’s direction and can intervene if metrics aren’t met.

The program’s iterative nature will allow for continuous improvements as the ecosystem matures, and we’re excited to see its implementation.

1 Like