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

[Uhthred]

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

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

The expectations are not signed documents- but draft, white-label agreement templates

---

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-

1. 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 ?

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

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

[Benido]

@Golem

• 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 see that 2/5 DSC members are high ranking delegates?

First of all thank you for the in-depth answer. I know you did not directly pick up my post (which refers to similar topics) but I would still like to answer these question and share my thoughts:

First question:
I would still love to see a clear goal for season 1 and season 2 that if it’s not met would automatically cancel the following seasons.

Second question:
I did not know that, so thank you for highlighting that.

I still believe there is a difference between 2 people of the DSC also being delegates and the Token Assembly sending 2 additional delegates. Disclaimer: I don’t know Michael Lewellen, I don’t know Lindsey Winder, so this is not about them, but more a very general remark.

I think there are arguments both wrt to the process and the structure.

• The members of the DSC were picked as industry/ defi experts (quote not verbatim, but mentioned in the twitter space IIRC) and we have no clue about the process, who picked them, based on which requirements etc.
• Delegates being sent by the Assembly would be voted on and their mandate (at least from my point of view) would be to question especially criticial decisions in terms of ZK spending (so y/n for e.g. season 2 and 3, but also the 12M ZK that are e.g. marketing and a “buffer” for now)

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

Michael’s delegate profile sadly doesn’t load for me, at least the delegation tab is not

Lindsey’s delegate profile shows she

• self delegated 8721 ZK 4 months ago
• has two 0 ZK delegations from Sept 12th
• has two ±5M delegations from October 24th

Again: I don’t know either of them, so I can’t judge them. It’s actually the other way around, I am happy two delegates are already part of the DSC. That doesn’t change my position though.

We should add one or two delegates that we vet, vote on and send to the DSC as our representative with the goal to increase transparency, check especially critical decisions and learn for future programs.

[Golem]

Hi Benido! Thank you for your kind words and also thank you for your ongoing diligence as a ZKsync Delegate, it’s because of great people like you that I’m so bullish on the future of ZKsync.

My apologies for not picking up your post in particular, I saw some common questions being asked and did my best to reply to them, I’d like to help answer any lingering questions to the best of my abilities before the vote officially starts next week.

@Benido

First question:
I would still love to see a clear goal for season 1 and season 2 that if it’s not met would automatically cancel the following seasons.

Ok so seeing as the main goal of this program is to increase DeFi TVL, we can use that as a good barometer for at least the 1st season of the program. In the proposal it is noted that if the goal is missed by a margin greater than 25%, then the program will be cancelled. As stated below:

@BaptistG

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

Since DeFi TVL is the main goal, we can look to what was said to accurately measure this:

@BaptistG

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.

Over 9 months, 3x 3-month seasons, the goal is to increase DeFi TVL by 205m-410m+; this roughly translates to an increase in DeFi TVL by roughly: 68.33m USD - 136.6m USD within the first season.

Using the reasoning above we can infer that if DeFi TVL does not increase by at least 51.25m USD (75% of lower goal) then the program can be considered a failure and should be cancelled immediately upon the conclusion of the 1st Season.

What do you think about that logic? Of course, there are other things being measured, but since DeFi TVL is the most important metric, if that is missed, then the program should be cancelled and re-evaluated as to what went wrong.

@Benido

We should add one or two delegates that we vet, vote on and send to the DSC as our representative with the goal to increase transparency, check especially critical decisions and learn for future programs.

Regarding your 2nd question, to be completely honest with you, I agree that we should have more delegate representation in future TPP / governance proposals, and I would love for essentially a list of pre-vetted, legit, delegates/ZKsync community members to be created that can serve on future Councils to overview future proposals.

This is something that would be super beneficial to the ecosystem as a whole, if we had a list of say, 20-30+ people with differing specialties and knowledge that can be relied upon to be a part of future councils for future governance proposals.

In the case with Ignite however there’s a few things to point out.

1. Time is a limiting factor here, this is why this proposal was created with the main service providers (OBL + Merkl) already locked-in from the onset, as well as the DSC members already being pre-selected. (NOTE: anyone can be replaced if they are not doing a good job, this is more so that the program can start with a very strong and structured foundation to hit the ground running.

2. Taking learnings from STIP & LTIPP from Arbitrum, this program more closely resembles the LTIPP which also had also pre-selected their council members & service providers before the program started, unlike the STIP that required a vote for every facet which lead to a lot of congestion and confusion. There is also a popularity contest element that would ideally be avoided over ensuring that capable people are in the roles assigned.

3. Since this is the 1st proposal, personally I think that it is important to ensure that you get very high quality, capable people that are aligned with ZKsync first and foremost, even if you are sacrificing the decentralized nature a bit by pre-selecting people. I think that as the 1st proposal it is ok to let this slide, with a goal of more community involvement (alluding to the list of qualified council members I mentioned earlier) getting established so that in the future, we can ensure that any new proposal will have a good pool of potential council members to pick from.

4. You need to make sure that there are no conflicts of interest. Since this program is so big and spreading across many different sectors that will benefit from it, no one on the DSC can have a direct connection to DeFi on ZKsync Era. If you look at a list of our top delegates this cuts out a lot of people from consideration unfortunately. You also have to consider that it needs to be someone with a lot of knowledge, no conflicts of interest, loves and is aligned with ZKsync & the community, and also has the time to devote to being on the council. This is not an easy set of requirements to satisfy.

As per the people selected, I can help shed some light on them:

@BaptistG

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

1. Lindsey Winder (co-founder of Hedgey Finance) is well known in the space with a great reputation. He was a part of the signers for the STIP (and LTIPP?) and has a wealth of knowledge and experience when it comes to governance + DeFi since his company is directly involved with token vesting, etc.

2. Michael Lewellen (head of solutions architecture @ OpenZeppelin) is one of the top security experts in the space. I mean, OZ is probably the top security firm in the space; Michael has a lot of experience reviewing code, contracts, etc, as well as being part of various DAOs, etc. OpenZeppelin is a part of the ZKsync security council and cares very much about the integrity of the ecosystem.

3. Kerman Kohli - I don’t know very well but he is highly regarded in the space and also was heavily involved with Arbitrum DAO and just DAOs in general in the space. His company, 0xARC, created the og DeFi passport too so he has a lot of knowledge + experience w/ DAOs and DeFi. He really cares about DAOs and governance and is very aligned with the ZK Credo.

4. Ashwath Balakrishnan - Also don’t know him too well but he is the head consultant for Delphi Digitial, so I would wager he has the most experience of most people in the space when it comes to DeFi in general and he would be able to help guide Ignite in a positive direction.

5. Karthik Senthil - last but certainly not least, Karthik is the Head of ZKsync Era from Matter Labs. He can essentially be considered the CEO of ZKsync Era and everything he has done since he got into this position has been in service of Era + the community. If anyone is a ZKsync Era fan/community member you can see the BIG changes across the chain from vibe to new teams/projects joining, etc, that has happened since about August of this year. Consequently late July is when Karthik took up this position. He lives and breathes ZKsync Era so I think it’s great to have him on the DSC.

Personally, I think the current list of DSC members is great.

With that being said, I agree that in the future, we should establish a list of qualified people that can serve on future councils for future proposals. I hope that this proposal sets a precent of always having a highly skilled, competent, and unbiased council that oversees future proposals to ensure that things always go in a positive direction for the ZKsync community.

Let me know if there’s anything else you’d like to discuss or if this didn’t really satisfy your questions.

[konektify]

Hello everyone!

We’ve been building on ZKsync for over two years, and our insights come from both experience and a deep commitment to the ecosystem. Our goal in participating in this voting system is to lay solid foundations that will bring long-lasting value to the collective future of our ecosystem. We understand that complex challenges rarely have black-and-white answers — there are many nuances in between. This proposal shows us that there is no perfect solution but at the same time the need for action is evident. At the same time, we have been following discussions from the time when first draft was launched, and seems a lot of thought has been put into it.

We recognize the importance of establishing a liquidity hub to support builders and users, and the Ignite Program certainly sets the groundwork for users, a more connected and thriving DeFi ecosystem. However, we have reservations about certain aspects, such as the min $1 million TVL and DSC not being corrupted.

• 1 mil which may unintentionally favor already well-funded projects, presenting potential conflicts of interest

• DSC having a lot of power, and preventing conflict of interest in case DSC members have interest or alliances with projects

The past two weeks gave a lot of clarity, answered on these questions and showed that certainly that in the future we can have new proposals which can bring us back on this topic, change the directive if we see its not going as planned etc.

Despite these concerns, we acknowledge that liquidity is critical, and in the broader context, this program offers significant value to the ecosystem.

Our inclination is to support the Ignite Program as it provides a solid framework for boosting participation and enhancing liquidity, which are crucial at this growth stage. We are also aware of the potential consequences coming with it.

While 325 million ZK tokens is a substantial allocation and not a naive one, we need to be proactive in building truly decentralized systems. It’s encouraging to see healthy community discussions, but it’s equally important to act swiftly and decisively.

Our takeaway from this experience is that future proposals should strive for simplicity, allowing the community adequate time to understand and respond, especially when multiple decisions are combined into a single proposal — a structure that can often act as a trigger for confusion or debate.

We appreciate the team’s responsiveness to feedback and the transparency they have provided. This open approach is what truly matters to us.

That said, as @lex_node pointed out, there is still work to do in creating lasting tokenomics value and governance mechanisms. We expect some market turbulence, including significant sell-offs, but remain confident that moving forward with this proposal is a step in the right direction that will ultimately drive meaningful progress.

Peace to you all

[0xsolal]

Weekly rewards are cool for keeping people engaged, but switching to every two weeks or every month might save on gas and could get users to stick around longer with their liquidity. It’d also give the team more breathing room to tweak which pools get incentives as the DeFi market changes. Curious to hear what everyone thinks

[Benido]

Hi Golem,
thank you for your detailed response and thoughts. I really appreciate it!

Let me quickly respond to the imo most important parts:

Ok so seeing as the main goal of this program is to increase DeFi TVL, we can use that as a good barometer for at least the 1st season of the program. In the proposal it is noted that if the goal is missed by a margin greater than 25%, then the program will be cancelled.

I am completely fine with that. I guess most if not all other goals/ KPIs mentioned are somehow connected to TVL and TVL is the highest KPI in that pyramid.
I am not a native speaker, so maybe my interpretation is off here, but since the proposal states that “The program may be cancelled at the discretion of the DSC […]” it’s not automatic, but optional. If we all agree that this “may” is actually a “should”, then I we are likely as close to automation as we can get with this first proposal.

I agree that we should have more delegate representation in future TPP / governance proposals, and I would love for essentially a list of pre-vetted, legit, delegates/ZKsync community members to be created that can serve on future Councils to overview future proposals.
[…]
I hope that this proposal sets a precent of always having a highly skilled, competent, and unbiased council that oversees future proposals to ensure that things always go in a positive direction for the ZKsync community.

I completely understand the issue with timing here.
I also acknowledge that it would be hard to find trusted delegates, at least for me, because I don’t (really) know the five listed DSC members, but the same applies for all other delegates here. We probably could nominate someone, but it will be hard to really evaluate people based on just a few posts here.

So for the conclusion is the following:

1. I am okay with a more pragmatic approach this time if we all agree on canceling season 2 and 3 if TVL is 25% below goal.
2. I hope we can find a more decentralized approach with more Token Assembly involvement for future proposals. This best case includes the list of 20+ delegates (tbd how we can make that happen), but also explicitly an earlier start for new proposals. I think there were rumors about more proposals already in the works. @rafa @theshelb If you are aware of other proposals, could you try to reach out so we can get delegate input earlier?

tl;dr: I am okay with taking a pragmatic approach here, but for future proposals the bar would be higher and I hope the values zksync shared won’t be aspirational forever.

[kuigas]

Position:

Overall, this proposal is well-designed, establishing a stronger liquidity foundation for ZKsync in 2025 and supporting healthy DeFi ecosystem growth through incentives.

ZK Points:

1. Building a Liquidity Hub: The proposal’s phased release of 325 million ZK tokens to build a liquidity hub can enhance ZKsync’s competitiveness in the DeFi sector, especially by increasing total value locked (TVL) and reducing trading slippage. This should make the platform more attractive in the long term.

2. Phased Monitoring: The bi-weekly evaluations and quarterly reviews allow for greater flexibility in the early stages, enabling responsive adjustments based on market and community feedback, thus optimizing incentive distribution and improving efficiency.

3. Setting KPIs: The clear establishment of key performance indicators (KPIs), such as liquidity growth and price execution, is crucial for achieving the desired impact. However, it would be beneficial to clarify the dynamic adjustment mechanisms in place for handling market volatility.

Suggestions:

1. Enhance Transparency: To increase community trust, consider making more real-time data available, such as a public dashboard showing liquidity and reward distribution details.

2. Introduce Long-Term Incentives: Avoid short-term speculative behavior by implementing incentives for long-term liquidity providers. Rewards for those with extended holding periods could help retain “sticky capital” on ZKsync.

3. Dual KPI System: Establish both short-term (TVL growth and user engagement) and long-term (user retention and capital utilization) KPIs. This approach would allow real-time project impact assessment while guiding future strategy adjustments.

4. Increase Community Involvement: Consider allowing the community to score quarterly KPI results. These scores could inform adjustments to the incentive program, fostering stronger governance involvement.

Summary: This proposal is thorough in terms of detail and execution. Maintaining sufficient transparency and flexibility will significantly advance ZKsync’s DeFi ecosystem.

[WebOfTrust]

Please excuse if this has already been answered in this forum.

I would like to know the selection criteria for OpenBlock Labs (“OBL”).
Who proposed them as the Analytics Manager?
Was there a vote or they are appointed by ZK Sync Foundation?

[Curia]

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

[Champion]

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

[Tekr0x.eth]

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

[keating]

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

[BaptistG]

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

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

Thanks again for sharing this

[Sinkas]

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.

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

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

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

1. Lack of specific goals

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

2. Lack of input from strategic stakeholders

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

3. Application Mechanics

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

4. Marketing

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

5. Synergy between protocols

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

6. Scope of work for service providers

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

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

7. Number of Capped Minters

The response provided satisfied our curiosity

@BaptistG

The capped minters for the incentives have been split to balance program allocation modularity and security. The number 6 was chosen because there are 3 seasons, and the team’s operational design followed this same multiplier (two (2) per season). Other designs, such as having one capped minter allocated to every two weeks were considered, however, there is significant uncertainty around the experiment outcomes, so we didn’t want to overfit the solution.

The six (6) capped minters were also chosen such that a change to the overall program could remove/add different capped minters without impacting one which is currently “live” (being used in real-time for the continuation of the program). Lastly, splitting up the capped minters was recommended during a security review, such that permissions to mint were not all anchored on a single minter. During this design discussion, additional possible improvements were uncovered, which are documented in Notion here .

Similarly, the capped minters for the program administration were created in a modular manner. This provides similar benefits on program operations, as well as easier onchain monitoring. For example, anyone can view and track operational token allocations for each of the individual capped minters.

As described in the proposal, all capped minters have an assigned administrator address. Each capped minter administrator includes the DSC multisig, and, in specific cases, a second administrator such as OBL or Merkl. This administrator can call the mint method, and assign a recipient of the minting action.

Should the Token Assembly decide to cancel the program, a sponsoring Delegate can place a proposal onchain via the Token Governor. This proposal would include an onchain action (calldata) that revokes the ZK token minter_role from the specific capped minter contracts. As noted above, this proposal can revoke one or multiple minter_roles, as well as deploy new capped minters if needed. This allows the Token Assembly to adjust the program should it be needed.

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

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

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

[michael-lewellen]

Hello everyone,

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

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

[keating]

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

[mcfly]

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

[smolphil]

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

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

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

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

Recommendations

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

[Areta]

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

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

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

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

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

[Tekr0x.eth]

@BaptistG

Application Submission Ends + DeFi Protocol Approvals Announced (~Nov 20-26th)

Hi, @BaptistG I was looking at the timeline for the program setup. Is everything going according to plan? Are you currently accepting applications? Is there a place where we can see this?