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

[Sinkas]

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.

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

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

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

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

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

7. Number of Capped Minters

The response provided satisfied our curiosity

@BaptistG

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.

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.