Overall, the Ignite program demonstrates a good balance of flexibility, transparency and community engagement that can effectively drive growth in the ZKsync DeFi ecosystem. However, there is still room for improvement in automation, standardization of incentive allocations, and participation thresholds. These adjustments will help increase the scalability and inclusiveness of the program, making it beneficial not only for large-scale agreements, but also for supporting innovative small-scale projects
Congrats on the first proposal. It seems like a step towards a major and important decision has been taken. I fully support ZKSync.
Suggestions for the ZKsync Ignite Program
- Simplify Rewards: Instead of weekly claims, let users claim rewards whenever they want. That way, both casual and active users are happy. Maybe even throw in an auto-compounder to make things easier.
- Get More Community Input: Make the feedback process more structured with clear timelines or a voting system. This way, people feel more involved and heard when it comes to big decisions like pool choices or reward timing.
- Keep Things Flexible: Regularly adjust token allocations based on what’s working. Having bi-weekly check-ins is great, but make sure you’re quick to pivot if something’s not clicking.
Make zk invincible in the future.
A summary for those who can’t go throught the whole draft:
The ZKsync Ignite Program proposes allocating 325 million ZK tokens over nine months to establish a DeFi liquidity hub on ZKsync Era. The goal is to increase DeFi TVL and enhance liquidity across interoperable ZK Chains, known as the “Elastic Chain.” Here’s an overview of the key elements:
Program Structure
-
Token Allocation:
- 300M ZK Tokens: Distributed to participants in selected DeFi protocols via six capped minter contracts (50M each).
- 25M ZK Tokens: Reserved for administration and unforeseen expenses, divided across four capped minter contracts.
-
Program Execution:
- OpenBlock Labs (Analytics Manager): Reviews and recommends token allocations bi-weekly based on analytics, publishes quarterly performance reports.
- Merkl (Technology Provider): Manages program operations, website development, and token reward distribution.
- DeFi Steering Committee (DSC): Oversees key decisions, including veto power on program approvals, allocations, and renewals.
Goals
- Primary Objective: Consolidate liquidity across ZKsync Era to serve builders and users, enabling efficient access to a wide range of assets.
- Target Metrics: Track DeFi TVL growth, asset depth, and slippage reduction through live dashboards and quarterly reports.
Design & Timeline
- Iterative Design: Bi-weekly adjustments to token allocations based on performance data, with real-time updates on the Ignite dashboard.
- Program Timeline:
- Set-Up (Oct-Nov 2024): Proposal review, vote, and launch preparation.
- Three Seasons (Nov 2024 - Aug 2025): Continuous monitoring with seasonal reviews for adaptive adjustments.
Participation Requirements
- Eligibility: DeFi protocols must complete KYC, maintain a minimum $1M TVL, and integrate with L2Beat and DeFi Llama.
- Compliance: No sybil farming or metric manipulation allowed.
Infrastructure & Transparency
- Website & Dashboard: Merkl will develop a user-centric platform for liquidity participation and reward management.
- Analytics & Data Sharing: OpenBlock Labs will create public dashboards for tracking metrics.
Governance & Oversight
- Accountability: DSC or Token Assembly can terminate the program at any time. Any unused tokens will remain unminted, with relevant contracts destroyed at the program’s end.
The Ignite Program aims to create a dynamic DeFi ecosystem, learning from prior incentive programs while maintaining transparency and governance integrity.
2 Likes
Without a doubt, this is a good proposal that will bring many benefits to the zkSync network, but I believe that in the initial stage, 300 million zk is too much. I suggest the proposal authors review the funding and reduce the number of tokens, otherwise, I will be forced to vote against it. I have already seen such large allocations on Arbitrum, and they brought nothing but a decrease in the token’s market price.
I also support Gabriel’s words and believe that 25 million zk is excessive
2 Likes
great proposal! Looking forward to it!
thtat´s a great point, i will vote
great stuff, waiting top start
Very happy to see the first TPP! Writing my thoughts and comments as I read through it.
Although I’m not necessarily against this, this is not how envisioned TPPs would work. This defeats the purpose of having onchain trackable metrics (and the entire design of TPPs) if a group of people will select where the money is allocated. Unless the TPP and all its contracts contain updatable logic as to how funds are being distributed toward participants (based on updatable criteria and onchain metrics) and then OpenBlock Labs could iterate as needed.
For transparency purposes, it would be desirable to have a cost structure breakdown of how 25,000,000 would be spent, or are expected to be spent.
Again, I’m not against this, this is how most grant programs work but I assumed predefined (possibly upgradable) contract logic would be ‘in charge’ of where the tokens are allocated. Otherwise, power is concentrated with people and not a self-executing contract design process.
Well, this renders my previous concerns moot. Thanks for clarifying. I’m glad to see that you keep autonomy and automation in mind and hope to see future TPP designs getting progressively better.
It would be helpful to have a framework for decision-making based on some criteria as to who gets the tokens, public and available for everyone to see so everyone knows what defines good performance and what metrics are being tracked.
Just out of curiosity - how are projects protecting against Sybil farming? Should we have some precise requirements for that?
Once again, I make a comment about something above (cost structure breakdown), and a few minutes later I find the answer. Great job on this and thanks for sharing.
This 
–
Extremely well-written proposal! This is the standard by which all future proposals should be written and measured.
Seems like the benefits heavily outweigh the concerns so I won’t nitpick the details.
Big +1 for this proposal!
I’m pretty concerned about the size of this program and that it doesn’t allow for future deployments on ZKSync to participate.
This program outlines spending on incentives roughly equal to 50% of current defi TVL!
Also, are we expecting these protocols to apply for incentives themselves? Why not just approve them on a case-by-case basis, allow the protocols to manage the incentives themselves, and skip the high management fees as outlined by @daniel-ospina.
Time and time again, the first couple proposals in a new DAO shoot for the moon and dramatically over-ask while the DAO is getting it’s footing.
While we are all excited to start seeing some programs in, I caution my fellow delegates to exercise prudence here.
4 Likes
This is a good idea. Would there be any form of KYC?
I agree.
This is too much money for the first vote, I believe that the amount of money being requested should be adjusted to at least half.
Great. Let do these. But i’m more interesting in when staking will be launching.
Seems exciting! Looking forward to voting.
nice… i will fully support ZK
It’s great to see the first TPP up and I think liquidity ‘ignition’ is the perfect place to start.
High level feedback
The obvious position is that this does of course deviate from the ‘permissionless pathways’ state of play that I think was the design focus for the TPP framework, which is principally what I found so interesting about this governance arrangement. However, I think this is well recognised in the proposal that this is not the ideal automated form we are looking for and there is a desire to iterate beyond this structure in the future (hopefully).
I do think it’s important that we shouldn’t be hamstrung by waiting for automated systems to arrive before the network makes a move like this. It does also fit within the capped minter with accountability framework discussed in the more meta TTP discussion, but I do think it’s important that this doesn’t interfere with, or limit the potential of a more decentralised development trajectory.
Some more general thoughts and feedback:
Liquidity Incentives
I think it’s well established now that liquidity incentives make the DeFi world go round. The challenge is making them sustainable and dialling the emissions to maximally bring in liquidity and network effects without over paying for it.
I think it’s possible that the structure here can do this. The two week decision making process is a tight loop and should allow relatively efficient ‘dialling’ process. The flow of using OpenBlock Labs to make distribution proposals, with review and oversight from a DSC is sensible at this point.
In short, we need it, no one has cracked this yet, might as well get going, it looks like a good place to start.
The Programme Mechanics
Pretty straight forward and sensible. Analytics team interrogates the impact in the ecosystem, generates a recommendation, creates a merkle drop, DSC signs off.
In some ways this is a step forward from programmes seen elsewhere, the execution here is more onchain, others had far more trust and direct human token holding in the loop. In other areas it has less delegate and community input.
The weaknesses here from a decision making perspective is that we have a rather centralised decision making system. We are delegating the decision to OpenLabs (who may be great at this I don’t know them), with the opportunity for the DSC to change it if desired. This is an obvious site for future decentralisation. One of the things I think we lose in this setup is a broader set of analysts joining the decision making process and in fact it should be recognised that the presence of such a team actively disincentivises broader oversight of the programme. For example, I think 5m ZK could bring a huge amount of independent minds to the chain. Again, I’m not against this approach at this stage given the lack of infra to broker such an arrangement but I think it’s worth flagging the trade off.
It’s also worth noting that this group essentially gains the power to enhance the TVL and volume metrics etc of the projects chosen, so it has quite a bit of power to directly make those projects revenue. Weaning off these systems is often difficult, Arbitrum are “detoxing” from their STIP and it’s likely that projects (and communities) might be aggrieved when the token tap turns down (or off) based on the decisions made, so they will get quite a lot of attention and decisions that will be challenged.
The benefit of a more automated system governed by the DAO is that they can take it up with the delegates if they’re upset about it, here they will have a more targeted group to lay blame to. It will be worthwhile thinking about processes to allow that deliberation to happen in the open, or have them be so algorithmic in nature that there is no room for argument.
RE the feedback request, ideally the cadence of reward flows would be block by block, which is one of the outcomes that an automated system could bring, but given that we are in that interim phase a weekly push of a merkle distribution seems sensible.
One thing that is worth noting that this creates a cryptoeconomic schelling point for potential selling activity. For example, let’s say there are a n actors receiving rewards all with the intent to realise those profits. The first actor to claim has the advantage over the others, creating a race condition. This is fine (sort of) if the exact time informationally is known to the participants, otherwise those with privileged information get access to the tokens first and can sell them for higher. So I would consider making that moment routine, or publicly known in advance and make sure no one claims before it.
The other way into smoothing this effect is to up the cadence of distribution (with block by block being optimal) or add a linear vesting dynamic which smooths out the sell moments to user directed choice.
The important thing here is that the Token Assembly can stop this at any time. This is an excellent policy and really changes the dynamic of this decision. If this feels suboptimal at any point in the programme lifecycle, any above threshold delegate could propose to stop it and rally votes.
The Token Economics
The 350m seems ok to me. It’s roughly 8% inflation on the current circ supply, sub 2% of the total supply. This is definitely not DeFi summer era token inflation frenzy, it’s an entirely manageable inflation especially since (I believe) the wider investor team unlocks are not happening in this period and any airdroppers who wanted to sell have sold already. If anything, I think it could be more aggressive, this is under $50m in dollar terms, which isn’t a crazy amount when it comes to a network level incentive programme. Of course, that could look a lot better if ZK does well in the market. I think the question is how much more inflation in the market are we willing to tolerate for everything else?
The ideal scenario is that this draws in token buyers to the ZK ecosystem, who buy ZK to get access to the elevated yields. In fact, I would make sure this is a key forcing function of the decision making. TVL is actually a terrible metric in my opinion, unless it’s raw slippage minimising market depth in core pairs. Projects that bring in new buyers to the ecosystem is worth 10X a metric that can be pumped by a few whales, who will move their capital to the next token tap on the next chain level liquidity programme the minute this one ends.
The DeFi Protocol Requirements
I would consider dropping the $1m TVL entry point, it’s very low in DeFi terms and you might get a pre-launched project that could launch with support of this programme and it would be a shame to exclude them. The evaluative process should provide all the assurances beyond this arbitrary line in the sand.
The sybilling or spoofing detection is a real rats nest and is the kind of thing that can lead to contentious decisions, might be useful to build an appeals process in advance. In fact generally the decisions for why dials have been dialled probably need to be well justified to head off the moans.
The Automation Game
We can’t get progressive automation without starting somewhere, but what I liked about the restrictions of the TPP framework in the docs was that it would put a pressure on the generation of automated DAO systems. This proposal alleviates that pressure and opens the door to similar set ups – it could set a precedent for centralisation.
It is made clear in the proposal that this is a less than an ideal set up. If that’s the case, what are we doing to get closer to the ideal? There’s definitely a reading of this that it delays, or even prohibits the development of automated mechanisms if they compete with this more centralised programme.
Additionally, given that this programme will have its own infrastructure, such as website, dashboards and other infrastructural pieces, is there a danger that this set up “enshrines” into practice in a deep manner? Is there even a point in proposing decentralised alternatives to this TPP?
It would be nice to see something in this proposal that recognises the need for, and potentially promotes the progressive automation of liquidity provision at the network level as it integrates with the token contract. Otherwise, we might get stuck in the rut of relying on centralised decision making, which is just “easier” than going the hard path of decentralisation. This is a phenomenon we’ve seen everywhere in this space and it always leads to closed systems and systemic fragility. I genuinely believe that open decentralised systems is what makes the best networks and filling out forms for centralised teams to make decisions on significantly limits that openness.
Summary
One of the things that got me excited about this network and DAO set up was that it might lead the industry towards better governance and decentralisation practices. I think there’s been every evidence of that so far and I certainly don’t think that the presence of this TPP necessarily changes that at all. But I do think we have an opportunity at this point to ‘start as we mean to go on’ and clearly signal that it is desirable to head towards those permissionless pathways.
Outside of those concerns, I think it’s an entirely sensible proposal. I recognise the need to move (especially on liquidity incentives) in advance of the creation of credibly decentralised systems. I also think there are elements of this activity, particularly with regards to integrations and deeper relationships with DeFi protocols and projects that need a degree of centralised coordination and may not be possible to mechanise. It could be an interesting meta outcome of this programme to identify what they are.
Overall, I’d be more than happy to support and vote yes on this proposal if we clear paths on how the decentralised alternatives can emerge.
2 Likes
I think allocating 325,000,000 ZK tokens is a little too much, how about allocating 300,000,000 ZK token. I think 25,000,000 zk tokens is distributed to people who deligate zk tokens to others.
I’m all for this proposal since it increases liquidity. Could we make it so that we can vote on it using $ZK, the governance token?