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

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

:ballot_box: This proposal passed with a majority of 1.25B ZK in-favor of the proposal. See final results here.

This is an outdated draft, please find the updated draft here

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

Summary

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

Abstract

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

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

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

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

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

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

The Ignite Program operations will be structured as follows:

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

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

Motivation

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

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

Primary Metrics

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

Specifications

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

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

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

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

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

Program Mechanics

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

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

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

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

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

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

Program Timeline

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

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

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

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

DeFi Protocol Participation Requirements

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

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

  • Complete and submit a ZKsync Ignite Program Application
  • 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 both L2Beat and DeFi Llama
  • Fully cooperate and integrate relevant APIs, data streams, and platforms with the program providers: OpenBlock Labs & Merkl
  • Must not encourage or participate (directly or indirectly) in sybil farming, spoofing metrics (such as TVL, users, etc), or other activities that are abusive or inconsistent with the purposes of the program
  • Actively assist in the administration of the program where necessary or advisable, for instance by helping with co-marketing and collaboration for the program

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

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

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

Infrastructure

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

  • ZKsync Ignite Website: The main portal for the program, providing users program information, a user dashboard, a list of incentivized applications, the ability for 1-click participation/view/claim rewards in a gas-free manner via paymaster, and other resources. The portal is an access point to third-party apps/protocols, but is not a standalone product or service and does not constitute the “liquidity hub” itself. To be built and operated by Merkl after passing of proposal.
  • Analytics: A public Dune dashboard to provide, track and measure performance data, user engagement, and effectiveness of the program strategies. All source-code (SQL) and CSVs should be hosted in a repo under the ZKsync Association Github. To be built and maintained by Open Block Labs and Merkl.
  • Discord: A discord server for users to receive answers on program or technical questions. To be maintained by Merkl.
  • 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
  • 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
  • 2,437,500 ZK tokens for 9 months of SaaS fee to utilize Merkl platform

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

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

DSC may change technology provider under specific conditions.

3. DeFi Steering Committee (DSC)

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

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

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

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

Responsibilities:

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

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

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

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

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

Additional Provisions for Program Operations: 12,115,000 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.
  • 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 ZK tokens to pay for these services.

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

Proposal Code Specifications

Relevant Multisigs

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

Other Relevant Contracts

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

Capped Minters

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

The Ignite Program has ten (10) ZKCappedMinters:

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

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

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

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

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

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

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

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

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

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

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

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

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

Ignite Program Capped Minters

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

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

Ignite Administration Capped Minters

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

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

Accountability Framework

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

Monitoring and Reporting

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

Approving Changes to Key Metrics

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

Program Cancellation

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

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

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

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

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

Legal & Compliance

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

97 Likes

LFG! Well done, proposal is gonna rock!!!

4 Likes

This is an important step for the protocol. Should be the first step for long-term success for DeFi sector.

2 Likes

Thank you for the proposal, I imagine this has been a lot of work, but the result is a great starting point for discussions and questions. Generally I think the idea to focus on “Expanding onchain assets” is great and likely to be the best candidate for a first TPP.

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

After reading all the FAQ and posts here, at least I had a different - more automated - picture of TPPs in mind.

  1. Could you please explain why KYC is needed?
  2. Do we really expect that we need 3 seasons / 9 months to “learn […] what is necessary for automation in the future”?

I understand that automation from the start is hard, but maybe a shorter (and smaller?) program is enough in the beginning and a bigger TPP can use the learnings after that.
I am not 100% happy with the application process and e.g. picking participants and creating the token allocation strategy (and only every 3 months). I think this should be as objective and automated as possible.

Contributors and compensation:

  1. Could you break down how the 3240 hours / 2120 hours were estimated?
  2. What’s included in the SaaS fees?
  3. Are the allocations part of the 25M ZK or come on top? Could you share some “unforeseen circumstances”?
  4. Bonus allocation should be publicly discussed and not be limited to DSC.

With regards to the 5M ZK for “branding, marketing, publicity”: Do the members of the DSC have any experience in marketing? I agree that a TPP needs to be marketed to achieve the goals, but from my experience marketing budgets are often wasted and 5M ZK is a considerable amount, so we should be careful.

13 Likes

Super exciting to see this, we’re confident in the Merkl team and their ability to deliver and distribute rewards for such a program. It might be important to highlight any fees that are associated with this for OBL as well as Merkl?

Additionally, we have some similar messages with prior delegates regarding KYC and duration of program, as 9 months does seem a little arbitrarily odd.

Additionally more information on the selection committee would be nice assuming this will be a governance led and voted in team?

Overall, excited to see where this will go, and thanks for putting this to the forums!

5 Likes

Sounds like a good idea. Important step!

I think it might hold a voting system like ‘Snapshot’ so that we can have the right to vote for the direction of the project!

1 Like

Great job Baptiste on the structure of the proposal. It’s very well thought out, and I think the Ignite program is something I would love to see in practice. I do have a few questions:

  1. Is the goal here to include existing ZKSync DeFi projects or attract new ones (from other chains)?

  2. How do you define the KPI of the proposal to be successful? Is it the number of new projects launched on ZKSync? Are new users onboarded to those protocols?

  3. Will the TPP reward be paid retroactively to participating projects? Does this mean that projects will have to pay their rewards upfront to their users? This could be an issue for many not-so-liquid projects, don’t you think so?

5 Likes

Great proposal, lets “ignite” the ZKsync Ecosystem!!!

1 Like

Congrats on the first proposal.

I hereby approve

1 Like

why not? i support everytime ZKSYNC

1 Like

Great and professional prepared proposal.

1 Like

Thanks for submitting this proposal.

Before giving an opinion, checking if I understand correctly:

  • you’re suggesting that we commit upfront to $39mn budget for 9 months
  • decisions made offchain
  • With the average salary per month and per person for the OpenBlocks Labs team being $17,700 or yearly equivalent of $213,000 (based on 3 people and just short of 4mn zk tokens requested. SaaS costs on top of the above)
  • paying $124/hour for the Mrkl team (and SaaS costs on top)
  • $3,000 per month per member of the committee
  • all positions have been agreed by the proposers in advance (so no election and no provisions for removals)
  • the program essentially provides multiple pockets of funds that are used at the discretion of the proposers (within the remit)
  • the goal is to increase DeFI TVL and “strategic assets” liquidity (not defined)
  • SaaS not defined

Is this understanding correct?

16 Likes

This is a huge step for the ZKsync, success is inevitable

2 Likes

this is great proposal, i approve :smile:

however i suggest to decrese program budget (4,995,500 ZK over 9 months, or ~1.54%). I suggest to make it below 1%.
ZK is the endgame!

2 Likes

cool proposal send it to governance vote

2 Likes

Well done. A great proposal for zknation!

1 Like

Nice thread LFG to make this !

Ive read all the allocation of the 25m ZK and i still think this is excessive. Is more than 7% of the program. What are the kpis for the bonus allocations?

Also a 12,115,000 zk discrecional use? This needs to be detailed and aproved as needed imho.

Thanks for posting the first TPP, Zk is the endgame.

4 Likes

How can DeFi protocols ensure that they are being monitored by the analytics provider, with the correct set of smart contract addresses, events, token prices ? Ideally, there should be a Github repository where anyone can submit a PR including relevant protocol details.

1 Like