I have rarely commented on ZOMG, and I also haven’t tracked suggestions around its future shape moving forward closely. However, I feel compelled to describe what I perceive as a significant issue, and suggest some brainstorms on how to address it. If I’m just rehashing existing discussion, I’d love pointers to it, since I missed it.
The significant issue is that due to the structure and timeline of elections, grant applicants have significant uncertainty around planning longer term projects.
Here are some challenging questions grant applicants face in planning how much they can risk and commit to contributing to Zcash around grant process/structure uncertainty:
Will my application be decided by the current committee or an upcoming not-yet-known committee?
Will the next committee have the same priorities and criteria as the current committee?
Will my ongoing approved project be subject to different scrutiny around ongoing milestones when the committee composition changes?
How can I successfully propose a long-term project that will take longer than a single committee’s lifespan?
What kinds of contingencies do I need to set up before I can even submit the application successfully, such as preparing backup sources of income or budgeting savings to accommodate a rejection?
Keep in mind that proposing a grant not only requires an applicant to put forward all of the proposed visible work itself, but they also have to plan their future around it, including foregoing other potential plans, and making contingencies around whether or not the grant is accepted. This is a significant cost that is outside of the price tag of an application, and typically only seasoned consultants know how to handle this kind of income / work contingency planning.
Another important nuance: long term doesn’t necessarily mean large scopes or large budgets! For example, someone may propose something like fulfilling some role, like a community coordinator for a specialized niche, over the course of a couple of years even though their budget is a relatively low rate. IMO, longevity of grant-funded projects is potentially very valuable for Zcash, even for small-budget projects.
Ok, with the problem defined, how can ZOMG committees or the larger process and structure around ZOMG address it?
One “light weight” possibility is simply that ZOMG committees establish a convention / norm that they strive to apply the same review norms to currently running grant projects as their predecessors.
Another similar convention / norm might be that by default they agree up-weight a grant application from an existing recipient (same team / org / people) that has a similar scope of work.
A more structured brainstorm might be to introduce a concept of “renewal proposals” where if the proposal effectively boils down to “keep doing a similar thing to what we’ve already done” the proposal format / effort is streamlined so it’s not as heavy-weight. (I’m not super clear on how to do this effectively…)
Establish a convention of breaking up large applications into “starter” vs “followup” grants for long term or large scope projects. Remember, part of the goal of a “starter” grant isn’t just to limit the risk to ZOMG and Zcash of misallocating funds, but also to help get the applicants in the door to reduce the planning uncertainty issue I described above. For example, suppose they have a big idea, but even putting together a proposal and planning their contingencies around it is costly, then a starter grant would actually include work to build out a fuller plan and do contingency planning around it.
IMO, a deeper structural shift that I’ve heard people discussing is to stagger committee elections so that the entire committee is never replaced, except for unusual / exceptional reform needs.
I’m not particularly attached to these suggestions, and I don’t have experience in running a grants programs through committee like ZOMG. What I’m hoping to see is more experienced folks address the deeper underlying issue.
Good thoughts, Nate! Here’s an idea: give a grant to a recipient in which they provide their Zcash address and then in the next Network Upgrade that address starts getting a small slice of the issuance.
The community could later decide to revoke that grant if the recipient was under-performing, in which case that address would get removed from the issuance in a future Network Upgrade.
This would help with the “long term continuity” idea that you are getting at, and in addition I really like the fact that it is fully permissionless — no external third party (like a government for example) could seize the funds or compel someone to stop the funds flowing to that recipient.
I’m personally against hard forking when we could instead have a ZOMG controlled wallet sign authorizations. It wouldn’t be hard on a theoretical level, would start building an on chain DAO infrastructure, and not be subject to the infrequent hard fork schedule.
As for the idea itself, I totally understand it for maintenance of infrastructure over years, yet question the amount of grants that take over a year to develop and would warrant building something like this or in the first place. While yes, a proposal could be passed at the end of one committee and hit the next almost instantly, I believe the new committee which was elected for a reason should still have authority. So ACK for maintenance, NACK for development IMO.
Edit clarification: I made the second paragraph a few minutes after the first and this post already had an interaction by the time I finished editing. Please be mindful of that.
We can use a DAO-like/multi-sig like structure, but bear in mind that this is not as permissionless. Some third party (for example a government) may be able to compel those signers to give up their control of the funds. Not true of dev funds baked into the base layer.
Fair, and the decision to issue these grants in the first place could be entirely via ZCAP as well, offering a complete alternative to ZOMG. That said, it requires ZCAP members to be informed on the set of grants in front of them, and arguably replaces ZOMG which I don’t believe to be beneficial. If ZOMG still decides, and this is just the new implementation, then it’s just as trustless since either way ZOMG can be compelled to issue grants (by keys or by words). The important distinction may be the inability for the multisig to revoke such grants without a hard fork. The problem with this path is then people will be proposing hard forks solely to revoke grants and we’d have a much more frequent schedule in order to be successful, requiring a lot more involvement from the community.
This sounds like a kind of on-chain issuance mechanism we also want available with ZSAs as well. Including this as a feature of ZSAs would remove the need for hard forks.
What is the thinking on how Zcash social projects are funded for ongoing maintenance 3-4+ years after their original funding? These can often be small expenses such as a domain renewal or server or hosting, but necessary costs that often determine if a project continues.
A few options:
1). The original grant recipient pays out of pocket
2). The original grant recipient writes a new grant proposal
3). The original grant recipient monetizes the project with ads or fees
4). Once a year, the ZF or grant committee communicates with projects funded in the past to see what expenses might be required
5). Retroactive rewards for projects that are still viable and used by the community
In regards to #5, Vitalik has said “The core principle behind the concept of retroactive public goods funding is simple: it’s easier to agree on what was useful than what will be useful.”
retroactive funding it’s a really good idea if you want to reward the right actions but if you want to use the grant in order to incentivize building what you want to be build it is too much uncertainty for the recipients.
.