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
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.
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.
Edit: This post from @polar quoting Alex this morning is a timely reminder that permissionlessness is the point. It’s great to see these signals from important figureheads in this ecosystem. I think we have an opportunity to live these values here.
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.
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?
This proposal is too good, with best for both zksync and community
finally some sanity is prevailing. apply it retractive so that users who provided liquidity after airdrop may get more share
I would love to congratulate everyone on the upcoming Governance event. This is a really important milestone for the zkSync community. As a delegate I would like to add a comment and/or suggest changes to the proposal. We all want the same thing: to make the Elastic Chain a leading chain in terms of TVL, user base, adoption, etc.
Why are several crucial decisions combined into one proposal?
2. “Establish a DeFi liquidity hub for the Elastic Chain on zkSync Era.”
You’ve mentioned that the main goal is to establish a Liquidity Hub. But how do you plan to achieve this? What mechanisms will you use? What are the concrete plans to reach this goal? There is zero information on it. Simply adding LPs and rewarding them feels trite.
3. “Which is subject to review by an independent group of experts called the DeFi Steering Committee (DSC).”
The positions have been agreed upon in advance and off-chain.
4. “OpenBlock Labs will serve as the ‘analytics manager’ and be responsible for: recommending how ZK tokens are allocated. Merkl will own technology and program operations, including the calculation and distribution of user token rewards. 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 proposed ZK token allocations.”
If OpenBlock Labs recommends how ZK tokens are allocated, Merkl calculates and distributes them, and the DSC has the power to veto (a legal right to reject a decision), then who decides whether to approve the ZK allocation? Am I missing something here? Need a legal clarification here.
5. “Must have a minimum $1MM DeFi TVL (as measured by DeFi Llama) at the time of the application submission. Builders can focus on finding product-market fit without the burden of bootstrapping liquidity, accelerating time-to-market and impact.”
Don’t you think the above-mentioned terms oppose each other? Is it necessary to set a limit of $1M TVL? There are only a few projects on zkSync, such as SyncSwap, Koi and etc with 1m+ TVL, besides they have a 100M+ ZK voting power. They will likely approve this proposal; don’t you think it presents a conflict of interest?
I suggest changing the terms and requirements so that all DeFi projects (without TVL requirements, but with KYC for founders) can apply with concrete proposals detailing their step-by-step plans for participating in the zkSync Ignite program. I have no doubt that interesting proposals will emerge.
Thank you!
yes good idea. i support zksync all the time
This is pretty good.
I think, i am going to vote YES
