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.
To start, we want to thank Merkl for the work they put into the proposal and for kicking off the discussion. We appreciate both the proactiveness and the enthusiasm to start moving things forward and we hope to continue seeing the same level of involvement going forward.
Having been in crypto, and more specifically, DAOs, for quite some time, we understand the need for an incentives program to remain competitive in the current landscape. That’s even more true for a relatively new DAO looking to attract builders and users. We should, however, look at the learnings from other such programs carried out in other protocols to avoid some common pitfalls.
Based on our experience as active delegates in other protocols (e.g., Arbitrum and Optimism), we want to draw attention to the fact that the program, as it’s currently described, could be significantly improved. Right now, the proposal lacks many crucial details that shouldn’t be overlooked, as they are bound to cause problems down the line.
Below, we’ve attempted to capture some of the points that we should discuss further before jumpstarting a ~$45,000,000 program.
Lack of specific goals
Right now, the goals of the program are described as
…increase DeFi TVL…
and
…[increase] liquidity depth of strategic DeFi assets (ZK, ETH, stablecoins, etc) for both existing and new DeFi projects on ZKsync Era.
These goals are too vague to be the drivers of a 45M program. Firstly, there are many incentive mechanisms through which those goals can be achieved. For example, instead of just incentivizing liquidity DAO could do a protocol-owned liquidity (POL) program and use the treasury’s funds to acquire other assets and then use them to provide liquidity in various pools in different dApps. There are no details in the proposal regarding which strategies are going to be explored and how are they going to be assessed.
Secondly, these goals do not address any of the following things.
- Increase in sticky capital that remains in ZKsync after incentives end.
- Increase in users transacting on the chain.
- Increase of protocols being deployed on ZKsync.
Also, while some metrics are described, there is no mention of what kind of increase we’re aiming for with the program, which by default would make anything a ‘success’ by the standards we have, or rather haven’t, set.
Lack of input from strategic stakeholders
While this forum post contains several comments, there isn’t much input from strategic stakeholders of the ZKsync ecosystem, including Matter Labs, ZK Foundation, and major ZK protocols.
Considering their familiarity with the ecosystem, as well as the fact that they stand to benefit from such a program, we should consider their input and involve them in the process.
Program mechanics
Only allowing protocols to apply within a 1-week window each season feels too small of a time window and is bound to cause problems, either by bottlenecking the program providers or creating an unfair environment for protocols that miss the application deadline.
We would suggest either extending the application window, or allowing protocols to apply in perpetuity (or several different time windows) if they meet the requirements.
Marketing
The proposal includes a marketing budget that will be at the discretion of the DSC, but it doesn’t mention anything in regard to the marketing itself. We understand that a marketing agency will be hired to carry out the marketing, but we’d appreciate at least some more information about the strategy, the messaging, the target audience, and the available channels. Right now, all these things are omitted.
Synergy between protocols
For the program to be more likely to succeed, we suggest that participating protocols and service providers collaborate not only in setting up the program but also in its marketing and seek synergies across the whole ecosystem. Protocols that are receiving incentives should ensure that they communicate that fact with their community, not only in social media channels (e.g. Twitter or Discord), but also on their platform (e.g. a banner on the top of their website). Moreover, they should proactively look for ways to cooperate with other projects in the ecosystem to boost their offering, for example a DeFi protocol can think about how can they utilize a zkSync game audience to attract them to trying out DeFi, or they can think how their users could use Lens in order to promote the fact that they received DeFi incentives (and by doing so they could receive some additional multiplier for example).
The scope of work for service providers
While the cost breakdown shows how the service provider compensation is going to be split across different roles, it does not show what is the scope of work for all the staff that is going to be working on this program as well, and it does not explain why we need so many resources to handle this program. The rates presented in the proposal are relatively high; we are not convinced that we should be locking ourselves for 9 months with this structure, primarily as what those teams will be doing daily for 9 months is vaguely described right now.
In addition, we would like to suggest opening up some opportunities for other service providers to get involved in this program as well. While it’s fine to have OBL as the main program analyst responsible for the entire program, we would like to have some open door for other experts in the field to propose their solutions and ideas based on the public data dashboards. We can set aside a separate budget for such vendors to get involved down the road without replacing the main program analyst or significantly altering the program.
Capped Minters
In terms of the capped minters:
- Why is the proposal suggesting we use 6 for the incentives and 4 for administrative expenses? Why not just 1, or why not 4+6, or 8+10, or 15 + 1, or any other potential combination? We’d like to understand if there’s a reason behind it or if it’s simply an arbitrary decision.
- How will the capped minters distribute the tokens, and what is the process for a delegate to propose stopping the distribution?
Miscellaneous points
- The whole proposal has nothing to do with the TPP spirit towards which ZKsync’s governance was moving. Instead, this proposal is more like any traditional grant programs with funds allocated subjectively according to some allocation schema. While we agree with some previous commenters that this is not necessarily bad, it is worth noting as it will set a precedent.
- The amended version removed the KYC/KYB requirement for participating protocols. We’re not quite sure why that change was introduced. Requiring KYC/KYB from participating protocols is a good way to safeguard against potentially malicious applications and also a mechanism to hold protocols accountable for the use of funds.
- The compensation for the program contributors includes bonus allocations for exceeding thresholds. However, as noted above, the thresholds aren’t specified.