[TPP 001] ZKsync Ignite Program (the “Ignite Program”)
| Title | ZKsync Ignite Program |
|---|---|
| Proposal Type | TPP |
| One Sentence Summary | Allocate 325,000,000 ZK tokens over nine months to deploy a program designed to establish a DeFi liquidity hub on ZKsync Era, aimed at increasing DeFi TVL and improving liquidity across all interoperable ZK Chains (”Elastic Chain”). |
| Proposal Author | Merkl |
| Proposal Sponsor | Baki |
| Date Created | 2024-10-17 |
| Version | v1.0 |
| Summary of Action | The Ignite program will allocate 325 million ZK tokens over nine months, with 300 million allocated to users via six capped minters (50 million each), and an additional 25 million tokens, managed by four capped minters, to cover administrative and unforeseen costs. |
| Link to contracts | See “Proposal Code Specifications” section |
Summary
- Goals: The ZKsync Ignite program will allocate 325M ZK tokens over 9 months to establish a DeFi liquidity hub for the Elastic Chain on ZKsync Era. The primary metrics of the program are to increase DeFi liquidity and strategic asset depth to minimize slippage
- Design: Every 2 weeks, token allocations will be defined and streamed towards specific pools/assets in participating DeFi apps/protocol at the recommendation of the program’s analytics provider (OpenBlock Labs), which is subject to review by an independent group of experts called the DeFi Steering Committee (DSC). This design enables the program to be iterative and strategic towards meeting its primary metrics.
- UX: The Ignite website will allow users to view incentivized pools from participating DeFi apps/protocols and directly provide liquidity. Pending eligible ZK rewards will be updated every ~8 hours on the Ignite website. The current proposal is to allow pending rewards to be claimed from the Ignite website on a weekly basis, however we would like community input on this point…
- Performance: Primary metrics will be available on live public dashboards as well as in detailed reports at the conclusion of every season (3 months).
- Oversight: The Token Assembly has the ability to cancel the program at any time by passing a proposal or revoking DSC admin authority. In addition, the DSC has the authority to cancel the program at the end of any season if primary metrics are not achieved.
Abstract
The goal of the Ignite Program is to establish a robust, unified source of liquidity on ZKsync Era in service of builders and users across the Elastic Chain who can access this liquidity via native interoperability.
This consolidation of liquidity forms a “liquidity hub”, which serves as foundational infrastructure to facilitate critical functions for builders and users including storing & exchanging assets, liquidity, and accessing a broad array of crypto-native and real-world assets in an economically efficient manner.
“Liquidity hub” refers to a decentralized, permissionless means for builders and users to access liquidity across ZK Chains via third-party apps/protocols that are deployed on ZKsync Era. It is not a single service but a collection of independent apps/protocols. There is no centralized control or provision of regulated crypto-asset services.
Why have a unified liquidity hub?
- 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
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
Although it would be ideal for this program to be automated, that objective is not fully achievable due to the program’s complexity and commitment to following legal requirements such as KYC. Therefore, the qualification review and distribution mechanic of this program will be supported by OBL and Merkl, and the DSC will need to sign off on final transactions to distribute ZK tokens to recipients. While this introduces administrative oversight to the distribution mechanism, we have outlined the setup, operational processes, and contracts in detail to ensure full transparency. All transactions will be executed onchain.
NOTE: An amendment to this proposal has been included on 21-Oct-2024 to allocate tokens to support onchain automation. Please see the “Program Mechanic Automation” section for more details.
For further details on accountability of the service providers and the DSC, please refer to the “Accountability Framework” section at the end of the proposal. We hope to learn through this program what is necessary for automation in the future.
Program Design [Amendment 21-OCT-2024]
The design of the Ignite Program is rooted around rapid iteration and being data-driven with clear success metrics to create maximum efficiency and long-term sustainability. Every 2 weeks, OpenBlock Labs (“OBL”) will propose several experiments towill be running concurrently across different assets, pools, routes, and apps, with the incentive amount roughly proportional to confidence level. Earlier experiments which have the least amount of backtesting will also distribute the least amount of incentives. As a result, we suspect the first season to index more on information gathering and for the program’s allocation to likely be back-weighted. Initially, we will focus on blue-chip asset pools, strategic trading pairs, ZKsync-native asset pools, and stablecoin pools to establish a balanced and robust liquidity foundation, alongside some “shots on goal” with assets that have nascent demand which may offer strategic differentiation vs. other ecosystems. The experimental design minimizes contamination between experiments to learn about multiple outcomes, thereby maximizing the insights gained from each iteration.
At the end of every two weeks, results will be measured which include 1) supply-side performance of incentives, 2) demand-side performance and dynamics, and 3) user segmentation to distinguish between speculative and long-term investors. This will allow us to learn what works (and equally importantly, what doesn’t), and “double down” on the experiments that meet the program’s goals by increasing allocation. Additionally, the design will aim to predict user retention and weight TVL by expected user lifetime to help achieve sustainable growth over short-term gains.
The program centers on user-centricity, and will fund a custom-designed website & dashboard that makes it simple for users to discover incentivized apps, directly participate, and view/claim rewards. The website & dashboard will be designed and operated by Merkl.
The design of this program incorporates learnings from both what has and hasn’t worked in similar programs that came before it, indexing on:
- Meritocracy + Rapid Iteration — Instead of pre-determining incentive amounts to participating DeFi protocols, the Analytics Manager (OpenBlock Labs) will propose recommendations for which assets, pools, and applications will receive ZK token allocations every two weeks. This allows the program to be fluid in its strategy and maximizes program effectiveness by assessing performance continually to deliver the highest growth potential possible.
- Being User-Centric — The program will fund a custom-designed website & dashboard that makes it simple for users to discover incentivized apps, directly participate, and view/claim rewards. The website & dashboard will be designed and operated by Merkl.
- Lessons from Prior Programs - The design of Ignite leverages learnings from programs such as Arbitrum STIP & LTIPP, Avalanche Rush, Sui Incentives, and Linea Surge to create a well-balanced approach that combines decentralized governance with structured and focused oversight via the DeFi Steering Committee (DSC) over participating DeFi apps/protocols.
Program Mechanics
Every two weeks, OpenBlock Labs (“OBL”) will propose specific ZK token allocations on a per pool basis to the DeFi Steering Committee (“DSC”) based on its analytics and data science models, and Merkl will prepare a transaction for the ZK token amount allocated for this period.
The DSC will need to sign a transaction of the ZK token amount from the “Ignite Program Distribution (“IP-Distro”) capped minter” to the Merkl distributor contract (not providing a signature is indication of a veto of this proposed recommendation). Merkl will create campaigns on a per pool basis based on the allocation methodology provided by OBL, and will dynamically compute rewards based on user actions and activity over the given period. Users will be able to see updated ZK token rewards every ~4-8 hours on the Ignite Program Dashboard, located on the Ignite Program website.
Merkl will update the distributor contract to reflect these rewards every week. Users will be able to claim their rewards directly from the Ignite Program Dashboard on a weekly basis. The corresponding ZK token rewards that users claim will be fully unlocked and sent directly to their wallet upon claiming.
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
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 → ~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)- Proposal posted on Forum (Oct 17th)
- Proposal submitted onchain (~Oct 29th)
- Proposal voting starts (~Nov 5th)
- Proposal execution (~Nov 20th)
- Application Submission + Approval (~mid/late Nov)
- Application Integration with OpenBlock Labs and Merkl + QA (~late Nov)
- Ignite Launch (~early Dec)
- Season 1 (~Nov 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
If this program is approved by the Token Assembly, there will be a one week application submission and approval period where DeFi applications are able to apply to be included in the program’s initial season. The final decision on the inclusion in the program sits with the DSC.
To participate in the Ignite Program, all DeFi apps/protocols must:
- Complete and submit a ZKsync Ignite Program Application
- [AMENDMENT 21-10-2024]
Complete KYC with the ZKsync Association before the start of the program - Be live on ZKsync Era Mainnet
- Must have a minimum $1MM DeFi TVL (as measured by DeFi Llama) at the time of the application submission
- Maintain an integration with [AMENDMENT 21-10-2024]
bothL2BeatandDeFi Llama - Fully cooperate and integrate relevant APIs, data streams, and platforms with the program providers: OpenBlock Labs & Merkl
- Must not encourage or participate (directly or indirectly) in sybil farming, spoofing metrics (such as TVL, users, etc), or other activities that are abusive or inconsistent with the purposes of the program
- Actively assist in the administration of the program where necessary or advisable, for instance by helping with co-marketing and collaboration for the program
Failure to comply with these guidelines or any other regulatory or compliance concerns may result in the DSC removing participants from the program at any point in time.
Failure to meaningfully participate towards the specified goals during the program may result in the DSC removing under-performing apps/protocols.
The program will span 3 seasons, as such, protocols that do not qualify for a particular season of the program can re-apply for the subsequent season. More information will be released about how new DeFi protocols can apply to the program near the conclusion of each season.
Infrastructure
These components are essential for deploying and managing the program. The code created will be hosted within the ZKsync Association’s GitHub repository to facilitate collaboration and maintain security standards:
- ZKsync Ignite Website: The main portal for the program, providing users program information, a user dashboard, a list of incentivized applications, the ability for 1-click participation/view/claim rewards in a gas-free manner via paymaster, and other resources. The portal is an access point to third-party apps/protocols, but is not a standalone product or service and does not constitute the “liquidity hub” itself. To be built and operated by Merkl after passing of proposal.
- Analytics: A public Dune dashboard to provide, track and measure performance data, user engagement, and effectiveness of the program strategies. All source-code (SQL) and CSVs should be hosted in a repo under the ZKsync Association Github. To be built and maintained by Open Block Labs and Merkl.
- Discord: A discord server for users to receive answers on program or technical questions. To be maintained by Merkl.
- Contracts: All source-code for contracts supporting further program automation will be hosted in a repo under the ZKsync Association Github. [Amendment 21-OCT-2024]
- Data Transparency: All data used in the monitoring and decision-making processes will be made publicly available.
This framework ensures that the Ignite Program operates with a high degree of accountability and responsiveness to both its internal metrics and the community’s expectations.
Contributors
The following independent third-parties have agreed to assist with the implementation of the program, and a summary of their roles follows below:
1. Analystics Manager: OpenBlock Labs
OpenBlock Labs (“Analytics Manager”) is the analytics manager for the Ignite Program. Their data analysis and performance metrics form the basis of the ZK token disbursements for the program.
Responsibilities:
- Review and recommend applying DeFi apps/protocols to DSC for program participation
- Integration and developer support for participating teams integrating with OpenBlock Labs platform
- Create high-level token allocation strategy to optimize for program metrics and share with DSC before program begins
- Recommend token allocations to DSC fortnightly for review
- Ongoing technical support or review of data discrepancies
- Report program results on a monthly basis for the DSC to review
- Create public 3-month “seasonal” review of the program for the DSC & Token Assembly to review the progress
Resources:
- Data Scientist, Data Engineer, Project Manager
ZK Token Allocation: total of 4,995,500 ZK over 9 months, or ~1.54% of program budget
- 3,923,000 ZK for 3,240 hours of effort. [AMENDMENT 21-10-2024] Fees for man hours will be re-computed at the start of season 2 and 3 based on the 30D MA of ZK at that time and will be included as part of any renewal recommendation sent to the DSC.
- 1,072,500 ZK for 9 months of SaaS fee to utilize OpenBlock analytics platform
Bonus Allocation: up to a total of 1,625,000 ZK tokens, or 0.50% of program budget
- OpenBlock Labs is eligible to receive bonuses for exceeding thresholds for the following metrics (DSC will determine exact definition + thresholds before launch of program):
- Price-adjusted DeFi TVL
- Slippage amongst key pairs
- Retained DeFi TVL (or similar sustainability measure)
DSC may change the Analytics Manager under specific conditions.
Their data analysis and performance metrics form the basis of the emissions disbursements for the program.
2. Technology Provider: Merkl
Merkl is the technology provider (“Technology Provider”) for the Ignite Program. This role is crucial for ensuring that the program’s technology needs are met promptly and efficiently.
Responsibilities:
- UX design, creation, implementation, hosting, and maintenance of legally compliant ZKsync Ignite Website
- Custom integrations with applications to Merkl platform
- Create campaigns for user incentive rewards
- Calculation and distribution of rewards to users
- Operational support of program for participating applications and users
Resources:
- Lead Developer, Front-End Developer, UX Designer, Operations Manager, Support Liaison
ZK Token Allocation: total of 4,634,500 ZK tokens over 9 months, or ~1.43% of program budget
- 2,197,000 ZK tokens for 2,120 hours of effort. [AMENDMENT 21-10-2024] Fees for man hours will be re-computed at the start of season 2 and 3 based on the 30D MA of ZK at that time and will be included as part of any renewal recommendation sent to the DSC.
- 2,437,500 ZK tokens for 9 months of SaaS fee to utilize Merkl platform
Bonus Allocation: up to a total of 325,000 ZK tokens, or 0.10% of program budget
- Merkl is eligible to receive bonuses for exceeding thresholds for the following metrics (DSC will determine thresholds before beginning of program):
- DeFi TVL
- Price-adjusted DeFi TVL
DSC may change technology provider under specific conditions.
3. DeFi Steering Committee (DSC)
The DeFi Steering Committee is comprised of 5 members. These members are industry experts and stakeholders who perform limited oversight functions to ensure that the program has continued alignment with the goals and target metrics approved by the Token Assembly. The DSC’s discretion is limited by its corporate documents and its members are subject to binding legal agreements entered into with the DSC.
Membership: Members of the DSC who will be considered ratified by the Token Assembly if this proposal is approved are:
- 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,115,000 12,120,000 ZK tokens (3.73% of the program budget) [Amendment 21-OCT-2024]
If necessary or advisable for the success of the program (at the sole discretion of the DSC), the DSC is authorized to allocate additional ZK tokens as follows:
- Branding/Marketing/Publicity: The DSC has the authority to spend up to 5,000,000 ZK tokens across the full length of the program (9 months) towards branding, marketing and publicity of the program.
- Gas Credits: The DSC has the authority to spend up to 500,000 ZK tokens across the full length of the program to sponsor gas for user transactions via paymaster made from the Ignite website.
- Third Party Audit: The DSC has the authority to spend up to 1,500,000 ZK tokens across the full length of the program (9 months) to hire a third party auditor to review the results of the program at the end of every season.
- DeFi Applications: The top performing participating DeFi app(s)/protocol(s) towards the specified metrics are eligible for bonus compensation up to a total of 2,000,000 ZK tokens.
- Onchain Automation: An initial 250k ZK tokens are allocated this workstream to cover automation design, contract development, and the report to the Token Assembly. Depending on workstream outputs and Ignite program KPI achievement, additional token allocations may be considered by the DSC for Seasons 2 and 3, which will come from the budgeted line item for audits and production integration into the Ignite program. [Amendment 21-OCT-2024]
- Reserve for Unforeseen Expenses: In the case that there are any additional unforeseen costs that are required for the program’s continued success, the DSC may use up to
3,115,0002,870,000 [Amendment 21-OCT-2024] ZK tokens to pay for these services.
NOTE: While the DSC is permitted to use these tokens for administering the program, it is by no means required to use all of these tokens. Any ZK tokens that are unused will remain unminted and the related capped minter smart contract will be destroyed upon conclusion of the program.
Proposal Code Specifications
Relevant Multisigs
| Name | Address | Signers |
|---|---|---|
| Ignite_Admin_Multisig | TO BE CREATED | 6/8: 5 DSC signers & 3 members of the Security Council |
| Merkl Multisig | zksync:0x3d3Fd37af3aEaBD0154230AdcfC9C177E13142c8 | Merkl team |
| OBL Multisig | Needed | OBL Team |
| DSC_OBL_Admin_Multisig | TO BE CREATED | 2/2: Ignite_Admin_Multisig & OBL Multisig |
| DSC_Merkl_Admin_Multisig | TO BE CREATED | 2/2: Ignite_Admin_Multisig & Merkl Multisig |
| DistributorUpgradeBoard | TO BE CREATED | 2/2: Ignite_Admin_Multisig& DSC_MainMultisig |
Other Relevant Contracts
| Name | Address | Note |
|---|---|---|
| ZK Token Contract | 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E | Controlled by Token Protocol Governor Timelock |
| ZkCappedMinterFactory (Mainnet) | 0x4dBBd2dE17F811B5281a79275a66f4a8aFbc7bc7 | No Admin |
| Merkl Distributor Contract | ZKsync Era Block Explorer | Merkl will use the following distribution and campaign creation contracts to distribute ZK to eligibly recipients |
| Merkl Campaign Creator | ZKsync Era Block Explorer | Admin: DistributorUpgradeBoard. Merkl will create a new campaign every two weeks with updates parameters based on onchain user participation metrics. |
Capped Minters
The necessary capped minters will be created in advance of being submitted onchain, with the appropriate multisigs as their admins (see capped minter tables below for details). The passing of this proposal will assign the following capped minters the Minter Role on the ZK Token contract. This will grant the admins of each capped minter access to mint the specified amount of ZK in each capped minter.
The Ignite Program has ten (10) ZKCappedMinters:
Six (6) Ignite Program Distribution ("IP-Distro") capped minters:
These relate to ZK tokens to be minted and distributed to users in pursuit of the goals and metrics of the program. Each capped minter will contain 50,000,000 ZK Tokens and will be used as needed throughout the program.
IP-ZK-Distro-Minter-1: `TO BE CREATED`
IP-ZK-Distro-Minter-2: `TO BE CREATED`
IP-ZK-Distro-Minter-3: `TO BE CREATED`
IP-ZK-Distro-Minter-4: `TO BE CREATED`
IP-ZK-Distro-Minter-5: `TO BE CREATED`
IP-ZK-Distro-Minter-6: `TO BE CREATED`
Four (4) Ignite Program Administration ("IP-Admin") capped minters:
These relate to ZK tokens to be minted and disbursed with respect to: (a) OBL’s ongoing Analytics Management services for the program; (b) Merkl’s ongoing Technology services for the program; (c) DSC ongoing program activities, SC signing + provisional bonus incentives for the program operators OBL/Merkl; and (d) Supporting services necessary for the program (including: marketing, gas abstraction, 3rd party audits, provisional bonus incentives to app/protocol operators, as well as any additional necessary discretionary spend).
IP-ZK-Admin-Minter-OBL: `TO BE CREATED`
IP-ZK-Admin-Minter-Merkl: `TO BE CREATED`
IP-ZK-Admin-Minter-DSC: `TO BE CREATED`
IP-ZK-Admin-Minter-Supporting-Services: `TO BE CREATED`
Ignite Program Capped Minters
The Ignite Program capped minter contracts which administer the Ignite Program are based on the following specifications:
Ignite Program Cappe Minters Overview
| Parameter/Feature | Minter 1 Values | Minter 2 Values | Minter 3 Values | Minter 4 Values | Minter 5 Values | Minter 6 Values | Description |
|---|---|---|---|---|---|---|---|
| TOKEN | ZK | ZK | ZK | ZK | ZK | ZK | The token contract where new tokens will be minted, defined as IMintableAndDelegatable. |
| ADMIN | Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
The address that is authorized to mint tokens. This is set as an immutable public address. |
| CAP | 50,000,000 | 50,000,000 | 50,000,000 | 50,000,000 | 50,000,000 | 50,000,000 | The maximum number of tokens that can be minted by this contract. This value is immutable. |
| minted | - | - | - | - | - | - | Tracks the cumulative number of tokens that have been minted by the contract so far. |
| Mint Function | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Allows minting a specified amount of tokens to a given address, provided the cap is not exceeded. |
| Authorization Check | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Ensures that only the designated admin can mint tokens by checking if msg.sender is the ADMIN. |
| Cap Check | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Ensures that minting does not exceed the predefined cap by checking the sum of minted and _amount. |
| Error Handling | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Includes custom errors for unauthorized access (ZkCappedMinter__Unauthorized) and for attempts to mint tokens beyond the cap (ZkCappedMinter__CapExceeded). |
| Admin Management | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Specifies that the TA has the authority to change or remove the admin, (and maybe burn tokens) if key metrics/milestones aren’t met, subject to a GovOps or Token proposal. |
Ignite Administration Capped Minters
In order for the Ignite Program to succeed, the following deliverables are expected to be completed by named contributors. Costs associated with the execution of the program are provided for by the following Ignite Administration capped minters.
Ignite Administration Capped Minters Overview
| Parameter/Feature | OBL Admin Values | Merkl Admin Values | DSC Admin Values | Support Service Values | Description |
|---|---|---|---|---|---|
| TOKEN | ZK | ZK | ZK | ZK | The token contract where new tokens will be minted, defined as IMintableAndDelegatable. |
| ADMIN | DSC_OBL_Admin_Multisig |
DSC_Merkl_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
The address that is authorized to mint tokens. This is set as an immutable public address. |
| CAP | 4,995,500 | 4,634,500 | 3,250,000 | 12,115,000 | The maximum number of tokens that can be minted by this contract. This value is immutable. |
| minted | - | - | - | - | Tracks the cumulative number of tokens that have been minted by the contract so far. |
| Mint Function | Enabled, OBL can mint up to cap | Enabled, Merkl can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Allows minting a specified amount of tokens to a given address, provided the cap is not exceeded. |
| Authorization Check | Admin-only (OBL) | Admin-only (Merkl) | Admin-only (DSC) | Admin-only (DSC) | Ensures that only the designated admin can mint tokens by checking if msg.sender is the ADMIN. |
| Cap Check | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Ensures that minting does not exceed the predefined cap by checking the sum of minted and _amount. |
| Error Handling | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Includes custom errors for unauthorized access (ZkCappedMinter__Unauthorized) and for attempts to mint tokens beyond the cap (ZkCappedMinter__CapExceeded). |
| Admin Management | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Specifies that the TA has the authority to change or remove the admin, (and maybe burn tokens) if metrics/milestones aren’t met, subject to a GovOps or Token proposal. |
Accountability Framework
The accountability framework of the Ignite Program is designed to ensure transparency, responsiveness, and adherence to the program’s goals. This framework outlines the procedures for monitoring performance, addressing deviations from expected outcomes, and making necessary adjustments to the program.
Monitoring and Reporting
- DSC Accountability: The multisig that has permission to mint and distribute any funds for the program have 6/8 signers from both the DSC and the Security Council. Each transaction requires at least one Security Council member to sign. This is to prevent the DSC from misusing any program funds.
- Bi-weekly Reviews: The DeFi Steering Committee (DSC) will conduct bi-weekly reviews to assess the progress against the program’s success metrics. These reviews will involve detailed analysis provided by the Analytics Manager, focusing on metrics such as TVL growth, user engagement, and liquidity impacts. The DSC will release review notes to the ZKsync Governance Forum in the interest of transparency.
- Seasonal Assessments (every three months): At the end of every season (three months), a comprehensive evaluation, created by the Analytics Manager, will be submitted to the DSC to compare longer-term trends against the program’s objectives. The program may be cancelled at the discretion of the DSC within 14 days of the end of a season in response to goals being missed by a margin greater than 25% or as a result of significant industry or market changes which require an adapted strategy in order to best serve the ZKsync protocol and community.
Approving Changes to Key Metrics
- Proposal for Modification: Changes to key metrics can be proposed by the DSC if certain aspects of the program are found to be unrealistic or if external market conditions have shifted significantly. Such proposals should be put to the Token Assembly as a Governance Advisory Proposal (GAP) on the GovOps Governor and must detail the reasons for modification and expected impacts on the program’s goals. If a GAP is put to a vote and approved by the Token Assembly, the DSC is required to implement any changes specified.
- Community Involvement: Seasonal Assessments and modifications to key metrics will be subject to community feedback through the ZKsync Governance Forum, ensuring that the ZK Nation community has the opportunity to voice their opinions.
Program Cancellation
-
Cancellation by DSC: The DSC may cancel the Ignite Program in response to a failure of the program to meet key metrics by a margin greater than 25%. The DSC has two opportunities to cancel the Ignite Program:
- The DSC may cancel the Season 2 and 3 of the program in the last 14 days of Season 1; or
- 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.
Proposal Review Call: TPP Ignite Program 
Call link: 
The call will be recorded and shared on the new 