When is the voting starting for this precisely?
Got idea when the voting will be opening?
Great work. Hoping it goes through
This proposal is good and will result in increase in adaption and growth of the ecosystem. The rewards will attract more users and builders.
ZK is the endgame.
These are excellent responses to the questions and i’ve been impressed by the thoughtful iteration of the proposal given the feedback. I feel like most if not all sensible feedback has been incorporated.
In this recent wave, I think the inclusion of slippage targets and value for money metrics is actually quite brave comparative to the usual ‘let’s see what happens’ approach for the these kind of liquidity mining programmes and should put clear pressure on the programme to perform. If we can get 5-10X uplift on liquidity per token value spent, it may well be the case that’s a good long term spend of the token beyond this programme, especially if the liquidity hub on era serves as routing liquidity for all the ZK chains. It might be worth thinking of a post season 3 (next iteration) programme mid stream if it’s performing this well.
I think the application window mechanic improvements also respond well to concerns there and make the programme far more dynamic.
The $1MM DeFi TVL threshold is well defended, but I think this does hint that there is a need for a future TPP that goes deeper into bootstrapping more nascent protocols perhaps not through liquidity mining but more direct incentives to support teams in crossing thresholds that would get them included in programmes like this. If you’re just under this threshold for example, this programme is going to make your life even harder as your TVL might go down as users rationally seek better yields elsewhere.
I think the approach of building enhancement oriented investment into TPPs like this, especially on the automation side, is a good precedent to set and I think we’ve found the right balance of recognising the need for kickstarting the TPP system and staying true to the desired long term goals.
As a delegate I am now more than happy to vote YES on this proposal.
[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-28 |
| 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 |
| Link to proposal discussion | https://forum.zknation.io/t/draft-tpp-zksync-ignite-program-the-ignite-program/ |
Summary
- Goals: The ZKsync Ignite program will allocate 325M ZK tokens over 9 months to establish a DeFi liquidity hub for the Elastic Chain on ZKsync Era. The primary metrics of the program are to increase DeFi liquidity (supply side), strategic asset depth to minimize slippage (price execution), and organic fees generated to LPs (demand side).
- Design: Every 2 weeks, token allocations will be defined and streamed towards specific pools/assets in participating DeFi apps/protocol at the recommendation of the program’s analytics provider (OpenBlock Labs), which is subject to review by an independent group of experts called the DeFi Steering Committee (DSC). This design enables the program to be iterative and strategic towards meeting its primary metrics.
- UX: The Ignite website will allow users to view incentives from participating DeFi apps/protocols and directly provide liquidity. Pending eligible ZK rewards will be updated every ~8 hours on the Ignite website. The current proposal is to allow pending rewards to be claimed from the Ignite website on a weekly basis, however we would like community input on this point.
- Performance: Primary metrics will be available on live public dashboards as well as in detailed reports at the conclusion of every season (3 months).
- Oversight: The Token Assembly has the ability to cancel the program at any time by passing a proposal or revoking DSC admin authority. In addition, the DSC has the authority to cancel the program at the end of any season if primary metrics are not achieved.
Abstract
The goal of the Ignite Program is to establish a robust, unified source of liquidity on ZKsync Era in service of builders and users across the Elastic Chain who can access this liquidity via native interoperability.
This consolidation of liquidity forms a “liquidity hub”, which serves as foundational infrastructure to facilitate critical functions for builders and users including storing & exchanging assets, liquidity, and accessing a broad array of crypto-native and real-world assets in an economically efficient manner.
“Liquidity hub” refers to a decentralized, permissionless means for builders and users to access liquidity across ZK Chains via third-party apps/protocols that are deployed on ZKsync Era. It is not a single service but a collection of independent apps/protocols. There is no centralized control or provision of regulated crypto-asset services.
Why have a unified liquidity hub
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:
- 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
- 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 top-level goals of this program are to 1) increase DeFi liquidity (supply side), 2) enhance price execution for strategic pairs (stablecoins, ETH, ZK, etc), and 3) generate organic fees to LPs (demand side). Achieving these 3 goals ensures a sustainable marketplace between users/traders and liquidity providers with sufficient asset depth that ensures a healthy pricing equilibrium to support value exchange across the Elastic Chain. Both primary metrics as well as secondary metrics such as natively minted liquidity, DEX volume, overall liquidity and overall fees will be detailed in bi-weekly reports and public dashboards.
To give the community a sense of what success will be measured, this proposal is providing directional guidance on primary metrics. This guidance below comes from 1) past programs that OpenBlock Labs has driven, and 2) current state of the ZKsync Era DeFi ecosystem.
- Our target is to increase DeFi liquidity by $5 - $10 for every $1 of incentive allocated (measured both in absolute and relative ETH terms) This roughly translates to increasing DeFi liquidity by $205MM-$410MM over 9 months. This is a broad range due to the fact that there are inputs which drive this that we do not control (eg macro market conditions, price of ETH, etc). However, in a vacuum, achieving towards the high end of this spectrum (or beyond) indicates success for this metric, while achieving towards the bottom end of this spectrum (or below) is an indication of underperformance.
- Our target is to improve price execution to achieve:
- Maximum of 5bps slippage up to $1M trades on stable-stable pairs
- Maximum of 35bps slippage up to $100K trades, and maximum of 120bps slippage up to $1M trades on key stable-volatile pairs (e.g. ETH-USDC)
- On the demand side, our target is to generate $3 in fees for liquidity providers for every $1 incentive allocated, or roughly ~$120MM in LP fees generated over 9 months. Generating sustainable demand is critical to maintaining an active DeFi ecosystem when incentives go away. To this end, we are targeting to retain $0.6 of DeFi liquidity post-incentives (eg “sticky capital”) for every $1 of DeFi liquidity growth.
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
The design of the Ignite Program is rooted around rapid iteration and being data-driven with clear success metrics to create maximum efficiency and long-term sustainability. Every 2 weeks, OpenBlock Labs (“OBL”) will propose several experiments to be running concurrently across different assets, pools, routes, and apps, with the incentive amount roughly proportional to confidence level. Earlier experiments which have the least amount of backtesting will also distribute the least amount of incentives. As a result, we suspect the first season to index more on information gathering and for the program’s allocation to likely be back-weighted. Initially, we will focus on increasing supply side liquidity through blue-chip assets, strategic trading pairs, ZKsync-native assets, and stablecoins to establish a balanced and robust liquidity foundation, alongside some “shots on goal” for assets that might offer strategic differentiation vs. other ecosystems. In later seasons, we will double down on successful experiments from earlier seasons and shift our attention to more demand-side strategies. The experimental design minimizes contamination between experiments to learn about multiple outcomes, thereby maximizing the insights gained from each iteration.
At the end of every two weeks, results will be measured which include 1) supply-side performance of incentives, 2) demand-side performance and dynamics, and 3) user segmentation to distinguish between speculative and long-term investors. This will allow us to learn what works (and equally importantly, what doesn’t), and “double down” on the experiments that meet the program’s goals by increasing allocation. Additionally, the design will aim to predict user retention and weight TVL by expected user lifetime to help achieve sustainable growth over short-term gains.
The program centers on user-centricity, and will fund a custom-designed website & dashboard that makes it simple for users to discover incentivized apps, directly participate, and view/claim rewards. The website & dashboard will be designed and operated by Merkl.
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.
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
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 → ~Dec 2024)
- Proposal posted on Forum (Oct 17th)
- Proposal voting starts (~Nov 4th)
- Proposal voting ends (~Nov 12-18th)
- Proposal execution (~Nov 13-19th)
- Application Submission Ends + DeFi Protocol Approvals Announced (~Nov 20-26th)
- Application Integration with OpenBlock Labs and Merkl + QA (~late Nov)
- Ignite Launch (~late Nov-early Dec)
- Season 1 (~Dec 2024 → ~Feb 2025)
- Season 2 (~March 2025 → ~May 2025)
- Season 3 (~June 2025 → ~Aug 2025)
Metrics will be continuously monitored, with bi-weekly adjustments, monthly reviews, and three-month seasonal reviews ensuring the program adapts effectively to ecosystem needs. More information on the accountability framework related to metrics is set out below.
DeFi Protocol Participation Requirements
If this program is approved by the Token Assembly, the program will span across three, 3-month long seasons for a total of 9 months. The application period for DeFi protocols will remain open for the entire duration of the program. OpenBlock Labs will review new applications on a rolling basis and can recommend applicants for inclusion to the DSC at the end of each month of the program. The DSC will have the authority to approve or reject these applications.
For the 1st Season of the Ignite program, the cutoff date for DeFi protocols to apply for the program is 1 week (7 days) post-execution of the program. Please refer to the timeline above for dates. Afterwards the ongoing rolling admissions of DeFi protocols at the end of each month will begin.
To participate in the Ignite Program, all DeFi apps/protocols must:
- Complete and submit a ZKsync Ignite Program Application
- 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 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 DSC has the authority to modify the above criteria at the beginning of Season 2 or 3 in the best interest of the program.
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.
- 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. 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. Fees for man hours will be re-computed at the start of season 2 and 3 based on the 30D MA of ZK at that time and will be included as part of any renewal recommendation sent to the DSC.
- 2,437,500 ZK tokens for 9 months of SaaS fee to utilize Merkl platform
Bonus Allocation: up to a total of 325,000 ZK tokens, or 0.10% of program budget
- Merkl is eligible to receive bonuses for exceeding thresholds for the following metrics (DSC will determine thresholds before beginning of program):
- DeFi TVL
- Price-adjusted DeFi TVL
DSC may change technology provider under specific conditions.
3. DeFi Steering Committee (DSC)
The DeFi Steering Committee is comprised of 5 members. These members are industry experts and stakeholders who perform limited oversight functions to ensure that the program has continued alignment with the goals and target metrics approved by the Token Assembly. The DSC's discretion is limited by its corporate documents and its members are subject to binding legal agreements entered into with the DSC.
Membership: Members of the DSC who will be considered ratified by the Token Assembly if this proposal is approved are:
- Lindsey Winder, Hedgey Finance
- Michael Lewellen, OpenZeppelin
- Kerman Kohli, 0xarc
- Ashwath Balakrishnan, Delphi Digital
- Karthik Senthil, Matter Labs
Members of the DSC may resign voluntarily or be removed from their position with approval from three DSC members. The DSC is responsible for nominating and approving candidates to fill vacant seats. A replacement may be appointed with approval from three DSC members. There should always be a minimum of three DSC members.
Responsibilities:
- Review eligible DeFi apps/protocols from the program, exercising veto as needed
- Review bi-weekly modifications to reward incentives as recommended by OBL, exercising veto as needed
- Sign transaction via multi-sig for bi-weekly reward dispersement to active participants of the program
- Conduct monthly meetings reviewing the status of the program hosted by OBL (publish public minutes of these meetings for the Token Assembly)
- Conduct in-depth seasonal reviews of the program every 3 months to ensure that the program is adhering to the metrics set forth in this proposal
- Engage third party vendors, if needed, for limited marketing and audit duties
- If necessary, add or remove DeFi apps/protocols from the program
- If necessary, decide to end the program early if the program is not living up to the guidelines set forth by this proposal or for other reasons at the DSC’s sole discretion
The Ignite_Admin_Multisig will be the admin of the 6 program distribution capped minters, as well as one of 2 signers for the DSC_OBL_Admin_Multisig, DSC_Merkl_Admin_Multisig and the DistributorUpgradeBoard. The Ignite_Admin_Multisig will be composed of all 5 DSC members and 3 signers from the Security Council. It will have a signing threshold of 6/8, requiring at least one member from the Security Council to sign off on each transaction as an accountability measure for the DSC.
As the admin on the 6 Ignite Distribution capped minters, the Ignite_Admin_Multisig will have the power to mint up to 300,000,000 ZK tokens for disbursement. As the collective admins of the 4 Ignite Administration capped minters, theIgnite_Admin_Multisig, DSC_OBL_Admin_Multisig and DSC_Merkl_Admin_Multisig are authorized (but not required) to mint up to 25,000,000 ZK tokens (total) for costs related to operations execution as specific in this proposal.
Compensation: The DSC will receive a monthly budget of 100,000 ZK tokens over the course of the nine month program for a total of 900,000 ZK tokens, to be divided equally among four members. (Excluding Karthik Senthil representing Matter Labs)
The Security Council (SC) signers will receive 14,814 ZK tokens each, totaling 44,442 ZK per month for their participation; with a total budget of 400,000 ZK tokens allocated to them for the nine month program.
Additional Provisions for Program Operations: 12,120,000 ZK tokens (3.73% of the program budget)
If necessary or advisable for the success of the program (at the sole discretion of the DSC), the DSC is authorized to allocate additional ZK tokens as follows:
- Branding/Marketing/Publicity: The DSC has the authority to spend up to 5,000,000 ZK tokens across the full length of the program (9 months) towards branding, marketing and publicity of the program.
- Gas Credits: The DSC has the authority to spend up to 500,000 ZK tokens across the full length of the program to sponsor gas for user transactions via paymaster made from the Ignite website.
- Third Party Audit: The DSC has the authority to spend up to 1,500,000 ZK tokens across the full length of the program (9 months) to hire a third party auditor to review the results of the program at the end of every season.
- DeFi Applications: The top performing participating DeFi app(s)/protocol(s) towards the specified metrics are eligible for bonus compensation up to a total of 2,000,000 ZK tokens.
- Onchain Automation: An initial 250,000 ZK tokens are allocated this workstream to cover automation design, contract development, and the report to the Token Assembly. Depending on workstream outputs and Ignite program KPI achievement, additional token allocations may be considered by the DSC for Seasons 2 and 3, which will come from the budgeted line item for audits and production integration into the Ignite program.
- New Ideas Bounty: We are establishing a new application process where 3rd party service providers may propose new ideas, integrations, and technology to the Ignite program to help the program run more effectively. This will be an open application available to any service provider in the space. In their application they will need to outline how much budget they are requesting and for what purpose. The compensation for this bounty will be taken from the “Reserve for Unforeseen Expenses”.
- 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 2,870,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 | 0x79E4e4C345af49c1f18620b4F5bd10F671A71F49 | 6/8: 5 DSC signers & 3 members of the Security Council |
| Merkl Multisig | 0x3d3Fd37af3aEaBD0154230AdcfC9C177E13142c8 | Merkl team |
| OBL Multisig | 0x754b4756e45Dcd1146D63Dd2477479645562AfF2 | OBL Team |
| DSC_OBL_Admin_Multisig | 0xa00E010f1eb877bC4240D053f6fa561462dD0aa0 | 2/2: Ignite_Admin_Multisig & OBL Multisig |
| DSC_Merkl_Admin_Multisig | 0xC2dC653B49A5ed3bfCb46E82ab0F2dA94b11eB4c | 2/2: Ignite_Admin_Multisig & Merkl Multisig |
| DistributorUpgradeBoard | 0xa58F16D6b4311Dd5161913bCFb5c65fF2a395605 | 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: 0xe546AEaaC57584da7554e7F88154DeDAD30A82b0
IP-ZK-Distro-Minter-2: 0x11791c6249631555cEb75CB39128789E3954c2EC
IP-ZK-Distro-Minter-3: 0x3BC3f64d084bE6d3336f10340DC8424290FFc4ab
IP-ZK-Distro-Minter-4: 0xDa2fBE31Fd47Af741bdB3dBC4eb662dA0107D33a
IP-ZK-Distro-Minter-5: 0x6b689B93B368c7C25E6e5ecaeAb23C11F8C2c392
IP-ZK-Distro-Minter-6: 0x2CC6c7b1a59A23fB3faCAFe4A3791C5c8A58Cbcc
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: 0xD375A20d93C2F7C6a83B19C5ae153cF2C6e09ba9
IP-ZK-Admin-Minter-Merkl: 0x2ADa5C15BC4FEE97EC2463ce4F8E4557174B8Dcf
IP-ZK-Admin-Minter-DSC: 0x4E86e74237Eb1f9432810eB5ab5861368d2f5964
IP-ZK-Admin-Minter-Supporting-Services: 0x178bFf5A197FB4499526D04Db602C45cEDCA40a9
Ignite Program Capped Minters
The Ignite Program capped minter contracts which administer the Ignite Program are based on the following specifications:
Ignite Program Cappe Minters Overview
| Parameter/Feature | Minter 1 Values | Minter 2 Values | Minter 3 Values | Minter 4 Values | Minter 5 Values | Minter 6 Values | Description |
|---|---|---|---|---|---|---|---|
| TOKEN | ZK | ZK | ZK | ZK | ZK | ZK | The token contract where new tokens will be minted, defined as IMintableAndDelegatable. |
| ADMIN | Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
The address that is authorized to mint tokens. This is set as an immutable public address. |
| CAP | 50,000,000 | 50,000,000 | 50,000,000 | 50,000,000 | 50,000,000 | 50,000,000 | The maximum number of tokens that can be minted by this contract. This value is immutable. |
| minted | - | - | - | - | - | - | Tracks the cumulative number of tokens that have been minted by the contract so far. |
| Mint Function | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Allows minting a specified amount of tokens to a given address, provided the cap is not exceeded. |
| Authorization Check | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Admin-only (DSC) | Ensures that only the designated admin can mint tokens by checking if msg.sender is the ADMIN. |
| Cap Check | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Ensures that minting does not exceed the predefined cap by checking the sum of minted and _amount. |
| Error Handling | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Includes custom errors for unauthorized access (ZkCappedMinter__Unauthorized) and for attempts to mint tokens beyond the cap (ZkCappedMinter__CapExceeded). |
| Admin Management | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Specifies that the TA has the authority to change or remove the admin, (and maybe burn tokens) if key metrics/milestones aren’t met, subject to a GovOps or Token proposal. |
Ignite Administration Capped Minters
In order for the Ignite Program to succeed, the following deliverables are expected to be completed by named contributors. Costs associated with the execution of the program are provided for by the following Ignite Administration capped minters.
Ignite Administration Capped Minters Overview
| Parameter/Feature | OBL Admin Values | Merkl Admin Values | DSC Admin Values | Support Service Values | Description |
|---|---|---|---|---|---|
| TOKEN | ZK | ZK | ZK | ZK | The token contract where new tokens will be minted, defined as IMintableAndDelegatable. |
| ADMIN | DSC_OBL_Admin_Multisig |
DSC_Merkl_Admin_Multisig |
Ignite_Admin_Multisig |
Ignite_Admin_Multisig |
The address that is authorized to mint tokens. This is set as an immutable public address. |
| CAP | 4,995,500 | 4,634,500 | 3,250,000 | 12,120,000 | The maximum number of tokens that can be minted by this contract. This value is immutable. |
| minted | - | - | - | - | Tracks the cumulative number of tokens that have been minted by the contract so far. |
| Mint Function | Enabled, OBL can mint up to cap | Enabled, Merkl can mint up to cap | Enabled, DSC can mint up to cap | Enabled, DSC can mint up to cap | Allows minting a specified amount of tokens to a given address, provided the cap is not exceeded. |
| Authorization Check | Admin-only (OBL) | Admin-only (Merkl) | Admin-only (DSC) | Admin-only (DSC) | Ensures that only the designated admin can mint tokens by checking if msg.sender is the ADMIN. |
| Cap Check | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Automatic, prevents exceeding cap | Ensures that minting does not exceed the predefined cap by checking the sum of minted and _amount. |
| Error Handling | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Unauthorized access, cap exceeded | Includes custom errors for unauthorized access (ZkCappedMinter__Unauthorized) and for attempts to mint tokens beyond the cap (ZkCappedMinter__CapExceeded). |
| Admin Management | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Governed by TA decisions | Specifies that the TA has the authority to change or remove the admin, (and maybe burn tokens) if metrics/milestones aren’t met, subject to a GovOps or Token proposal. |
Accountability Framework
The accountability framework of the Ignite Program is designed to ensure transparency, responsiveness, and adherence to the program’s goals. This framework outlines the procedures for monitoring performance, addressing deviations from expected outcomes, and making necessary adjustments to the program.
Monitoring and Reporting
- DSC Accountability: The multisig that has permission to mint and distribute any funds for the program have 6/8 signers from both the DSC and the Security Council. Each transaction requires at least one Security Council member to sign. This is to prevent the DSC from misusing any program funds.
- Bi-weekly Reviews: The DeFi Steering Committee (DSC) will conduct bi-weekly reviews to assess the progress against the program’s success metrics. These reviews will involve detailed analysis provided by the Analytics Manager, focusing on metrics such as TVL growth, user engagement, and liquidity impacts. The DSC will release review notes to the ZKsync Governance Forum in the interest of transparency.
- Seasonal Assessments (every three months): At the end of every season (three months), a comprehensive evaluation, created by the Analytics Manager, will be submitted to the DSC to compare longer-term trends against the program’s objectives. The program may be cancelled at the discretion of the DSC within 14 days of the end of a season in response to goals being missed by a margin greater than 25% or as a result of significant industry or market changes which require an adapted strategy in order to best serve the ZKsync protocol and community.
Approving Changes to Key Metrics
- Proposal for Modification: Changes to key metrics can be proposed by the DSC if certain aspects of the program are found to be unrealistic or if external market conditions have shifted significantly. Such proposals should be put to the Token Assembly as a Governance Advisory Proposal (GAP) on the GovOps Governor and must detail the reasons for modification and expected impacts on the program’s goals. If a GAP is put to a vote and approved by the Token Assembly, the DSC is required to implement any changes specified.
- Community Involvement: Seasonal Assessments and modifications to key metrics will be subject to community feedback through the ZKsync Governance Forum, ensuring that the ZK Nation community has the opportunity to voice their opinions.
Program Cancellation
-
Cancellation by DSC: The DSC may cancel the Ignite Program in response to a failure of the program to meet key metrics by a margin greater than 25%. The DSC has two opportunities to cancel the Ignite Program:
- 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.
1 Like
To echo @drnick I commend the commitment to revision in response to comments and criticisms. I too would have smaller nitpicks here and there, but we are at a point where this should probably go to vote rather than further discussion.
2 Likes
I will try to be as clear as possible.
I don’t think the proposal’s goal and KPIs are clear enough. The delegates’ questions are not being addressed properly, and there is no clear model explaining where the 300M zk figure comes from. Additionally, the 25M zk cost (with 12.5M for discretionary use) is very high.
Here’s what I propose:
-
Add 2/3 delegates to the DSC.
-
Define clear and unambiguous metrics before this begins. I don’t want a dashboard to track progress later; I want a dashboard with predefined metrics from the start.
-
Remove the 12.5M discretionary fund and reserve it for a future vote if needed and if governance deems it appropriate.
1 Like
Only comment I would have is that it would be great it ZK had RFPs for further selection of teams that executed these very large proposals. This builds legitimacy
Here is a SimScore report of this Forum’s replies. It prioritizes and clusters the responses simplifying proposal updating process, making it transparent and granular. Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. @drnick @zer8 @BaptistG
They ignore questions from small delegates, pretending they don’t exist, but they responded to questions from major delegates, such as @L2BEAT. It feels as if the proposal has already been accepted, and the voting is a mere formality.
Additionally, this proposal has already been supported by delegate @404Gov , who received votes from the Dragonfly fund using tokens that should be locked. On this topic, a user published a brief investigation on Discord, which appears quite credible
2 Likes
At Tevaera, we’re dedicated to being a strong community voice, promoting fair and transparent decision-making to advance the ZKsync network. With over 26M ZK in voting power, we’re pleased to support ZKNation’s first proposal, the ZKSync Ignite Program, which aims to establish a robust liquidity hub to enhance ZKsync’s DeFi total value locked (TVL) and accessibility.
7 Reasons for Tevaera’s Support of this Proposal:
1. Unified Liquidity: We love the idea of making Era the central liquidity hub to power the Elastic Chain network. The 300M ZK incentives will drive significant activity over the next 9 months, attracting new users and developers to ZKsync.
2. Transparent Rewards: Instead of vague “future” airdrops, ZK Nation is focusing on structured, transparent rewards, a clear improvement.
3. Clear Success Measures: Increase DeFi liquidity by $5-$10 per $1 in incentives, aiming for $205M-$410M over nine months. Success metrics include maximum 5bps slippage on $1M stable-stable trades, 35bps for $100K stable-volatile trades, and generating $120M in fees for liquidity providers, with a retention goal of $0.60 for every $1 of liquidity growth post-incentives.
4. Meaningful Engagement: Forum discussions have shown high-quality feedback, with the Ignite proposal team promptly addressing issues and opportunities.
5. Ecosystem Growth: This initiative will benefit all projects in the ecosystem by strengthening liquidity and is likely to drive new user traffic to native dApps on ZKsync.
6. User-Centric Approach: The Ignite website streamlines access, allowing users to view incentives, provide liquidity, and check rewards every 8 hours, with weekly claiming options
7. Good Timing: With the expansion of the Elastic Chain network through the addition of new ZK chains, these incentives provide a solid foundation and build strong momentum.
Feedback/Improvement Opportunities: This is a strong, well-thought-out proposal. Much of our feedback around program automation, KYC etc. was echoed by other delegates and addressed by the proposal team. We’re supportive and will provide more feedback as results from the first season come in.
For now, we have two recommendations for consideration:
a.) Implement real-time reward claims instead of weekly options to boost on-chain transactions, offer flexible claim times, reduce “potential” simultaneous sell pressure, and give users greater control over their rewards.
b.) Develop a clear, long-term plan to maintain liquidity momentum beyond the Ignite incentives, focusing on meeting the retention goal of $0.60 for every $1 of liquidity growth. That’s it for now. We’ll continue to share our decision rationale transparently with the ZK community for all future proposals.
Onwards 
2 Likes
I don’t think the proposal’s goal and KPIs are clear enough. The delegates’ questions are not being addressed properly, and there is no clear model explaining where the 300M zk figure comes from. Additionally, the 25M zk cost (with 12.5M for discretionary use) is very high.
1. Proposal’s goal & KPI’s:
2. KPI’s Explained in-depth:
3. Where does 300M ZK figure come from?
- This was explained on both the public X Spaces + Public Delegate discussion
- It was chosen by working backwards from the amount of DeFi TVL KPI ($205MM-410MM) and factoring in learnings from previous DeFi programs, where it can be expected to receive between $5-$10 increase in DeFi TVL per $1 spent. In this case, you take the 30 day moving average price of $ZK (e.g. say it’s $0.1250), multiply it by 300M tokens, = $37.5M USD; then multiply it by 5 = $187.5m, and multiply it by 10, = 370.5m; and you get in the range of the DeFi TVL increase (187.5 - 370.5) you can estimate based on utilizing 300M ZK for the program rewards.
- They said this was not the only reason why they chose 300m ZK in incentives, but it was a big reason behind their decision
4. The 25M ZK administration budget (and 12.5m ZK discretionary fund) is too high, remove it
-
The 25M ZK is broken up into many different categories for the successful running of the program over 9 months, you can view the complete breakdown HERE
-
OBL = 4.95M ZK; Merkl = 4.63M ZK; DSC + SC = 1.3M ZK; KPI Bonus (pontential) = 3.95M ZK;
Marketing expenses = 5M ZK; Gas Credits = 500k ZK; Automation Budget = 250k ZK; 3rd party audit = 1.5M ZK; discretionary spend (unforeseen costs) = 2.87M ZK -
Now that we’ve broken down the expenses, you said that the 12.12M ZK discretionary fund should be removed. Note: it is 12,120,000 ZK (max spend, not necessarily they will spend all of that), which, at $.13 is $1,575,600 USD. Certainly a large number but not $12.5m USD as you said in your post.
- If that is removed, that means you want to REMOVE: all marketing for the program, Gas Stipend (making everyone’s gas txns free for Ignite), 3rd Party Auditor (to protect community), Automation budget (to make better for community in future proposals), KPI bonuses for DeFi protocols (if they work super hard to make the program a success), & any discretionary funds (in case something goes wrong and or something needs to be upgraded immediately without time for a vote to approve the spending + as a buffer for new teams to offer services for Ignite)
Personally I think that it would be very shortsighted and not in the best interests of the community to remove these important functions and services
5. Add 2/3 Delegates to DSC
- Michael Lewellen, OpenZeppelin is on DSC, is a delegate with 12.45M votes
- Lindsey Winder, Hedgey Finance is on DSC, is a delegate with 10.2M votes
I think I’ve gone ahead and answered all of your questions, giving important context from the proposal and from what was said in the public answers.
My questions for you:
- Do you still believe the proposal goal & KPIs are not good enough? If yes, what type of additional clarity are you looking for?
- Do you understand now the logic behind where 300M ZK for rewards came from?
- Do you think 12.12M ZK for all of those areas is still too much and should be removed completely?
- Do you see that 2/5 DSC members are high ranking delegates?
I hope I was able to help!
1 Like
really big news.Zksinc is the future of L2
Hey! Thanks for all the work you’ve put into this proposal—it’s clear a lot of thought went into it. That said, there are a few things we think need addressing before moving forward:
- What’s the plan after it ends? We’ve seen with Arbitrum and Optimism that activity spikes during incentive programs, then drops off afterward. It’d be great to have a strategy for keeping users engaged once this wraps up.
- Tracking what works: We need a solid way to analyze the program as it runs, so we know we’re putting funds into the right areas. If things aren’t going as planned, it’d be helpful to make adjustments along the way.
- Identifying real users: Bots can skew the results, so we’ll need a way to spot and focus on genuine user engagement.
- Avoiding farm and dump: We’ve seen users farm rewards just to dump them, which can hurt token value. Having more specific KPIs and maybe starting with a 3-month pilot could help us refine what works and avoid some of those pitfalls.
So, for now, we’re voting against this proposal, but we’d love to see these points addressed for a stronger program!
1 Like
Answers to your questions below. Did you read the proposal? Every one of your questions is answered in the proposal:
-
Identifying and rewarding real users while punishing & disincentivizing bad actors is one of the primary responsibilities of OpenBlock Labs, the analytics manager of the program.
-
Are the current KPI’s not specific enough? Please provide examples of specific KPIs you would like to see. OBL has stated on the public calls that they are looking into ways of enticing users to not simply farm & dump but rather to farm & continue farming with their rewards. In my opinion, if the program makes it more worthwhile for users to farm > dump then that’s what they will do.
I have a hard time understanding what your main concerns are, considering that all of the topics have been addressed in the proposal and during the public forums (in Q&As, spaces, and open delegates calls).
2 Likes
To clarify, my main intent was to emphasize how crucial these points are for building community confidence and setting the program up for long-term success. However, considering the 9-month duration and 325M ZK token allocation, I’m concerned that this is a significant commitment without a prior trial phase. Running a pilot program first could allow us to see if everything works as intended based on the specifics laid out in the proposal. This would give us the chance to adjust and review the program as needed to ensure it’s optimized before fully scaling up.
1 Like
Ok I understand where you are coming from. It is definitely a valid concern. It is a large program, however, i believe the program is written in a way that anticipates this concern and is setup to fight against this via 2 main ways:
-
The DSC has the authority to cancel the program at the end of each Season if things are not going well. Since tokens are minted & used on an “as-needed” basis, then if the program is cancelled after season 1, (3 months in), then at most 1/3rd of the 325M tokens will be used and the rest will remain unminted & untouched.
-
The Token Assembly has the authority to cancel the program at ANY time. 1 month into the program, if it looks like a sh*tshow then anyone can propose the program be cancelled and boom, if the Token Assembly approves the cancellation, the program is over.
Utilizing the rapid iteration cycle of 2-week increments + the need for the DSC to decide whether to continue or cancel the program every 3 months, based on analytical data I think settles all of your concerns. This ensures that you can view the 1st season as the “pilot” portion of the program. If it’s bad it will be cancelled.
Why not just set it for 3 months, then if it’s good, do another proposal to continue? It’s really simple. Doing that would destroy all of the momentum of the program. If 3 months goes by and everything is great, if it’s done your way, then you would need to write another proposal + put it onchain for a vote.
This at the very least would take 15 days to do and most likely take 3-4 weeks to do. Plus everything would need to be restarted. This means all the positive momentum and hype for the program would die and need to be restarted after the 2nd governance proposal passes.
This seems like an incredible waste of attention and opportunity. I understand the concern you have, but checks & balances have been built in to prevent the running of a bad program; while also capturing all the upside if things go great.
1 Like
What do you mean? They clearly said at the beginning that they would group all of the common questions together and post large Q&As answering similar theme’d questions.
You can view this to see the common questions that are all grouped together:
Onto your final point:
Did you know that across all governance systems in the space locked tokens can be delegated to different delegates and used for voting? This is how DAOs work in crypto, it works like that on Arbitrum, Optimism, and ZKsync. Locked tokens means that tokens cannot be sold. It doesn’t mean they can’t be delegated and used for voting. I don’t understand the problem here?
1 Like
Bootstrapping a $45 mm GTM strategy is not an amateur endeavor. The expertise that assembled this team, structured this proposal, and sought validation from a month-old DAO is well organized. The proposers’ attitude towards delegate feedback is nothing short of professional.
Traditionally a deal ticket of this size would have some degree of due diligence inquiry. TPP #1 was tabled on October 17th and the Token Assembly has less than three weeks to deliberate, decide and deploy this budget. As a potential delegate to this Token Assembly, I seek the following information as a public good-
Sponsorship
Assuming it is the same person, please disclose
- Did Baki participate in drafting this TPP as an independent contributor to the Token Assembly, or in his designation as the Co-Founder of Clave?
- If he was representing Clave, what was the role and extent of their contribution?
Selection
1: Is audit history a prerequisite? If so, will all protocols that participate in TPP-1 have their audit history reviewed by OBL and approved by the DSC?
“This guidance below comes from 1) past programs that OpenBlock Labs has driven, and 2) current state of the ZKsync Era DeFi ecosystem.”
2: Under the current state of the ZKsync Era Defi ecosystem, how many protocols pre-qualify under the criteria of ‘1 mm TVL’ and ‘live on mainnet’? Can you provide a list ?
“Fully cooperate and integrate relevant APIs, data streams, and platforms with the program providers: OpenBlock Labs & Merkl”
3: If a $1 mm TVL protocol started today, how long would it take for them to audit their smart contracts and go live on the ZKSync Era mainnet?
3.1 Once live, how long does it take for the protocols to fully integrate the relevant APIs, data streams, and platforms with the program providers?
Allocation Strategy
Instrument Selection
“Rewards will be applied to pools that align with the program’s goals and demonstrate meaningful results to the program’s key metrics. This includes:
- Blue-Chip Asset Pools: Pools involving major assets like ETH, ZK, USDC, WETH and WBTC.
- Strategic Trading Pairs: Key pairs such as ZK/ETH, ETH/USDC, ZK/USDC, and wsETH/ETH.
- ZKsync-Native Asset Pools: Pools that support tokens native to the ZKsync ecosystem.
- Stablecoin Pools: Attracts liquidity providers seeking lower-risk options
- Nascent Asset Pools: Pools that support assets that show nascent demand and can offer unique differentiation to other ecosystems such as RWAs”
1: Could you share a simple percentage breakdown of nominal allocations to each of these asset classes?
1.2: Are there caps to any of these position sizes?
“Nascent Asset Pools: Pools that support assets that show nascent demand and can offer unique differentiation to other ecosystems such as RWAs”
2: Could you describe such potential assets in a function of
- Market cap
- Liquidity requirements (volume and minimum length of trading history)
- Historical (reliability of price data)
Rebalancing
“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”
1: Might we not end up creating a moat around the program’s earliest participants by following this mandate (i.e. more time=more backtesting=higher confidence=larger allocations)?
1.2 Wouldn’t that disincentivize the participation of new protocols in a market where they have to compete with a $43 mm incentive subsidy pool for user attention and acquisition?
Oversight
“The DSC’s discretion is limited by its corporate documents and its members are subject to binding legal agreements entered into with the DSC.”
This is a $45 mm proposal, and DSC is the sole fiduciary trusted to oversee this distribution.
1: What are these documented limitations on the discretion of DSC ?
1.1: Who drafted these contracts?
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”.
2: Since Micheal Lewellin (Open Zeppelin) is both a DSC member and a Security Council member, does he get 2 votes?
2.1: Who are the 3 SC members? Will they get voted in by the Token Assembly?
Review eligible DeFi apps/protocols from the program, exercising veto as needed
3: When OBL recommends a pre-qualified ($1 mm, contract audited, mainnet live) protocol for review at the end of each month, what are the covenants that might trigger a veto rejection?
Marketing
“The DSC has an agency in mind to help operationalize this strategy which will include:
- Partner marketing: This will likely be the most effective marketing tactic. We plan to include both direct beneficiaries (protocols chosen by the DSC) and indirect beneficiaries (projects not selected but still benefit from attention) will regularly participate in co-marketing campaigns. This could include onchain campaigns, leveraging popular games or communities, contests, and other methods this chosen agency has experience with.
- Distribution launch partners: Collaborate with strategic partners like wallets, exchanges, or bridges to raise awareness to their audiences (similar to JumperExchange’s involvement with SuperFest)
- Direct Paid Marketing (via newsletters, podcasts, and crypto media channels)
- UGC Campaign: We will likely execute a user-generated-content campaign for DeFi/crypto content creators.
- Twitter/Telegram: We plan to use the existing Twitter and Telegram community to continually communicate updates and opportunities, and create a place for participants to share and learn together. These channels will be moderated.”
1: Could you provide a nominal breakdown of how $100 would be split between these categories?
“Engage third party vendors, if needed, for limited marketing and audit duties”
2: Who will own and drove the strategy and direction of such marketing agency relations? Will that be DSC ?
KPI-
- DEFI TVL
“Our target is to increase DeFi liquidity by $5 - $10 for every $1 of incentive allocated (measured both in absolute and relative ETH terms) This roughly translates to increasing DeFi liquidity by $205MM-$410MM over 9 months.”
1: Are these token unlocks (worth nearly $140 mm) factored in to these final TVL projections of $205MM-$410MM ?
- Slippage amongst key pairs
“Our target is to improve price execution to achieve:
- Maximum of 5bps slippage up to $1M trades on stable-stable pairs
- Maximum of 35bps slippage up to $100K trades, and maximum of 120bps slippage up to $1M trades on key stable-volatile pairs (e.g. ETH-USDC)”
1: From September 2025 there’s a linear unlock of nearly 173 mm $ZK every month till June 2028. Once we stop incentivizing demand, what slippage rates are expected for this consistent supply ?
- Organic fees
“On the demand side, our target is to generate $3 in fees for liquidity providers for every $1 incentive allocated, or roughly ~$120MM in LP fees generated over 9 months”
1: What happens to LP fees at the end of Season 3 when the ZK Ignite tap turns off? How will these protocols survive such an incentive driven spike in block space demand after Season 3?
Compliance
There have been questions from delegates asking about any potential of conflict risks regarding the DSC and vendors. We want to clarify that no members of the DSC or 3P vendors (OpenBlock Labs, Merkel, etc) have a conflict of interest with any potential DeFi app/protocol that may apply to the program. This was specifically kept in mind while selecting potential members of the DSC and the program service providers.
1: Does any members of the DSC share investors/investments?
1.2: If a Defi protocol that applies to the Zk IGnite program share investors/investments with members of the DSC, will such members disclaim such conflict of interest and abstain from voting?
“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.”
1: Since this cost has already been budgeted, does the DSC commit to a mandatory audit at the end of Season 3?
The DSC or Token Assembly can cancel the program at any time.
1: If there are public, credible allegations of favoritism, asset inflation, or collusion by DSC, do the proposers consent to a 3rd party audit by a vendor of the Assembly’s choice?
Disclaimer:
This submission was prepared from readings of all versions the ZK Ignite proposal, feedback statements, and publicly sourced information. I possess no privileged investigation, nor claim any qualified opinion for any of the assumptions, whether literal or inferred in the body of text above. I am an independent contributor.
4 Likes