In light of recent discussions, I have drafted a ZIP that proposes proposes expressly prohibiting any disbursement of funds from the Lockbox until after Zcash Shielded Assets is active on Mainnet, and extending the Current Dev Fund for one year.
A pull request has been opened to add this draft ZIP to the zcash/zips Github repository.
Constructive feedback welcome! 
Hello @Dodger ! Left some comments there.
Note: these comments MUST NOT be interpreted as opposition or endorsement of the ZIP. The objective of the review comments are to suggest improvements that could help the ZIP author to better convey the ZIP objectives for readers.
I posted a review which Iâm linking for discussion here:
In my personal opinion, this draft ZIP âmanifestly violates common expectations of a significant portion of the Zcash communityâ and should not be accepted. ZIP 1015 says that âthe Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development fundsâ. There was no expectation that âallocation of development fundsâ would be blocked behind any specific protocol feature, other than possibly mechanisms that directly help to allocate development funds â which ZSAs do not.
ZSAs in particular are a complicated feature that very well might encounter delays in deployment for entirely legitimate reasons. What if a security vulnerability is found, for example? It is completely inappropriate to hold the lockbox funds hostage to ZSA deployment.
The draft also contains misleading assertions about the likelihood of conflicts between ZSA code and other potential consensus changes, as mentioned here.
This proposal has its justification, given the potential high impact and importance of ZSAs.
Delays in ZSA implementation due to additional obstacles or the tying up of important resources on governance issues would definitely be suboptimal.
However, one condition would be that ZCG continues to receive funds and retains the possibility of funding other projects and teams, while the lockbox remains âlockedâ for the time being. Projects such as the maintenance and improvement of mobile wallets like Zashi as well as making hardware wallets available like Keystone lead to the actual adoption of Zcash technology (e.g. see growth of the Orchard pool). Another example is the integration into Brave and its marketing offensive. These are on par with the importance of ZSAs and must not be neglected.
Cross-posting my response to Dairaâs Github comments hereâŚ
In my personal opinion, this draft ZIP âmanifestly violates common expectations of a significant portion of the Zcash communityâ and should not be accepted.
I disagree.
ZIP 1015 says that âthe Zcash Community wishes to establish a new Zcash Development Fund after the second halving in November 2024, with the intent to put in place a more decentralized mechanism for allocation of development fundsâ. There was no expectation that âallocation of development fundsâ would be blocked behind any specific protocol feature, other than possibly mechanisms that directly help to allocate development funds â which ZSAs do not.
The absence of an explicitly-articulated expectation in a ZIP does not imply that the ZIP in question can be interpreted as expressing an opposite or counter-expectation.
Furthermore, one could argue that, at the time the community decided to adopt ZIP 1015, there was an expectation that zcashd would be deprecated well before April 2025, thus clearing the path for ZSA activation.
ZSAs in particular are a complicated feature that very well might encounter delays in deployment for entirely legitimate reasons. What if a security vulnerability is found, for example? It is completely inappropriate to hold the lockbox funds hostage to ZSA deployment.
Extenuating circumstances (such as a fundamental security vulnerability) would, in my opinion, be grounds for re-consulting the community. There is plenty of precedence for amending ZIPs (c.f. ZIP 1014).
Iâm writing this solely as an interested community member â not speaking for Shielded Labs.
The reasons given to reject this ZIP are mistaken and this ZIP should be included in the polls.
(Financial disclosure: my employer, Shielded Labs, does not and will not receive funding from Dev Fund or Lockbox so this ZIP wouldnât affect my paycheck or my personal finances, except if it impacts the price of ZEC, which is my main financial life. Emotional disclosure: Iâve had my difficulties working with the author of this ZIP, including one incident in public that I am still angry about.)
I think this ZIP would be bad for Zcash, and I would vote against it in the various polling structures and with my coins.
But the reasons given by the ZIP editors to exclude this ZIP from the polls are mistaken. The ZIP process is used for two different things â technical improvements and governance improvements. The reasons given to reject this ZIP are valid reasons to reject a technical ZIP but not a governance ZIP.
The rationale for rejecting this ZIP gave three reasons. The first two are from a list of possible reasons in ZIP 0:
it is manifestly unimplementable.
This is a valid reason for rejecting a technical ZIP, but not a governance ZIP. Most of any governance ZIP is community mandates which are not implementable technically. For example ZIP 1014 required that Dev Fund recipient organizations MUST publish quarterly transparency reports, that Zcash Foundation Board members MUST not own equity in ECC, and a great many other MUSTs besides. ZIP 1015 says the ZCG grants MUST not go to the Financial Privacy Foundation (FPF), that FPF MUST publish a grants dashboard, and so on.
it manifestly violates common expectations of a significant portion of the Zcash community.
Manifestly violating common expectations of a significant portion of the Zcash community is a pretty bad bug in a technical upgrade, but kind of essential to governance. A significant portion of the Zcash community strongly felt that ZIP 1014âs creation of the Dev Fund after the expiration of the Founders Reward was a manifest violation of their expectations. Their conviction was so strong that some of them created the first Friendly Fork â Ycash â as a branch of the Zcash blockchain that implemented their expectations. On the other hand, an even larger portion of the Zcash community strongly felt that sunsetting ongoing support and development of Zcash would manifestly violate their expectations. Thatâs governance for you.
The third reason given is not one of the reasons currently in ZIP 0:
âHowever, we also feel that there is an additional reason that should be added to ZIP 0: it attempts to use the ZIP process to effect behaviour on specific Zcash ecosystem participants, without a privacy or security motivation.â
Again, it makes sense that a technical ZIP could be rejected if it did this, but doing this is kind of the point of a governance ZIP.
My conclusion: rejecting this ZIP for the given reasons was a mistake, and I look forward to voting against it with my votes and coins in the upcoming polling! 
Regards,
Zooko
+1 to what he said. 
This incident raises questions about the role of the ZIP Editors, and their responsibility to remain impartial when discharging their duties.
ZIP 0 includes the stricture that "The ZIP Editors will not unreasonably reject a ZIP. " That is exactly what is being attempted here.
I was asked recently why I drafted three ZIPs. The answer is quite simple: To ensure that community members have a real choice when it comes to choosing if, when and how the Lockbox funds are to be disbursed.
Rejecting this ZIP on such spurious grounds is denying the community that choice, and forcibly silencing their voice.
Itâs antithetical to Zcashâs underlying principles and philosophy, and, quite frankly, downright shameful.
i find some of the wording in that zip to not be as neutral as i think it could be.
however i think it should still be allowed for community polling.
I love everything you said @zooko but gotta push back on one bit:
When you have elections in the USA and the majority of citizens decide to elect a convict as president, yet most of the world says that they donât want this guy, what happens? Do the citizens of the USA have the last word?
Rethorical question obviously. That âcommunityâ thing yâall keep talking about is great, in many social contexts and to understand the culture of ZEC supporters at large. But when it comes to governance itâs been a farce, particularly when it touches spending the inflation of stakeholders. Itâs not legitimate. Never has been, never will be. Thatâs not governance for me, no, not at all.
who can explain why we have to keeping doing devfund debates on a yearly basis now? arent there better things to be spending money on lmao seriously isnt the point of all this to be helping zcash teams have more funds??? so were spending funds to debate how to convince the community to give us more future fundsâŚ
all of these hand wavey statements are predicated on a thing about what is the community we really have no clue. the only community we know about are the 200 or so odd participants in Zcash forum and the other spinoff polls. theres no way to know what the expectations are from passive zcashers cause they dont speak up maybe they dont even know how to speak up. as one of the reddit zcash mods i know personally for sure that theres at least a handful of reddit only zcashers who never use this forum. thats just scratching the surface. so anyone here pontificating about The Zcash Community Expectations being violated is doing a bit of grandstanding if you ask me
Precisely. And most people in here are completely bias because they receive money from the dev fund. That governance is illigetimate on so many levels, itâs not even funny. Those people DO NOT represent either stakeholders or the ZEC community at large. So why are they calling the shots? A mystery of life.
Speaking for myself, and as a former ZIP Editor and an Owner / original drafter of ZIP 0 on its intended meaning.
Noted.
The argument wasnât that this provision of the draft failed to meet a narrow mechanistic definition of implementability. On the contrary, it is technically possible to implement the ZIPâs conformance requirements. But to be considered implementable in respect of the intent âas the ZIP Editors interpreted itâ of ZIP 0, that isnât enough: there must also be a reasonable chance that implementing the conformance requirements would achieve (i.e. help to cause) the claimed effect.
I will file a PR intended to clarify this. [*] You are of course welcome to provide feedback on that PR.
In this particular case, the claimed effect is that preventing disbursement from the lockbox would increase the likelihood of ZSA deployment and zcashd deprecation happening sooner. There was a consensus in the meeting (if I remember correctly, it was unanimous among ECC and ZF representatives present with their zcashd and Zebra engineer and manager hats on) that this wasnât possible: the ZIP could not achieve its claimed effect because preventing lockbox disbursement could not have any positive impact on the schedule for deploying ZSAs.
Itâs not that we claim to be infallible in making schedule estimates; far from it. Note, though, that answering whether a particular change will help to advance the schedule is a lot easier than making an overall estimate. The people present were precisely those with the relevant experience to answer this question, and we had high confidence in our answer.
Where node implementors (for both zcashd and Zebra, in this case) attending a ZIP editing meeting express strong confidence about an issue within their direct competence, the ZIP Editors â even if they are some of the same people with a different hat on, which admittedly is not ideal â are entitled to rely on it.
For example ZIP 1014 required that Dev Fund recipient organizations MUST publish quarterly transparency reports, that Zcash Foundation Board members MUST not own equity in ECC, and a great many other MUSTs besides. ZIP 1015 says the ZCG grants MUST not go to the Financial Privacy Foundation (FPF), that FPF MUST publish a grants dashboard, and so on.
Yes, and those are all requirements that could arguably achieve their claimed effects. In fact, my understanding is that some of the reporting requirements of ZIP 1014 were not only enforceable, but were in practice enforced on ZF. At some point ZF was failing to publish the required transparency reports, and that provision of ZIP 1014 was used by Jason McGee to pressure them to do so. As a result, they did, and the desired direct effect of the public being able to read ZF transparency reports was achieved. (For the purpose of this discussion it does not really matter whether all intended indirect and more subjective effects, such as incentivizing effective uses of funds, flowed from that. The direct effect is nontrivial and sufficient.)
So it is clear that such requirements do not provoke the âmanifestly unimplementableâ clause.
- it manifestly violates common expectations of a significant portion of the Zcash community.
Manifestly violating common expectations of a significant portion of the Zcash community is a pretty bad bug in a technical upgrade, but kind of essential to governance.
I disagree, and as the person who wrote this line in the ZIP, I am sure that I absolutely intended to include governance. In fact governance decisions were near the top of my mind when writing it. Each entry on this list of reasons for rejecting a ZIP apply to all ZIPs, and that was definitely not an oversight. I remember considering them all individually and whether there should be different criteria for different categories of ZIP, and concluding that they should not be.
That speaks to the original intent, but letâs also consider the merits. I still donât see a useful distinction between âtechnicalâ and âgovernanceâ ZIPs here. I put those in quotes because itâs not always a dichotomy; governance ZIPs can include more or less technical components.
Itâs a common pattern (and often preferred) that a governance ZIP such as ZIP 1014 depends on a ZIP providing technical mechanism such as ZIP 207 (Funding Streams). The former is clearly governance and the latter is clearly technical. But what about ZIP 214 (Consensus rules for a Zcash Development Fund), which defines the actual funding streams called for by 1014 (and 1015)? That is both governance and technical.
So if, for the sake of argument, the unimplementability / ineffectiveness provision applied only to technical considerations, it would have to apply to technical considerations within any ZIP, even if that ZIP mainly dealt with governance â and also if the requirement in question was deemed by the ZIP Editors to have both technical and governance aspects. Arguably (and this would be the decision of the ZIP Editors, in this hypothetical), the âLockbox Distribution Prerequisiteâ provision of draft-jackgavigan-defer-and-extend did have both technical and governance aspects, and so could still have been subject to the unimplementability / ineffectiveness provision.
I think you may also be implying that governance issues are more subjective. Indeed they often are. But are they inherently subjective, or are there cases where their unimplementability and/or ineffectiveness can be assessed (by the people with direct experience of the relevant area) with high confidence?
I would argue that the governance vs technical distinction, even in cases where the distinction is clear, is merely a heuristic. What matters is whether, on a case-by-case basis, a requirement of a submitted draft can reliably be judged to be unimplementable and/or ineffective. The ZIP Editorsâ collective statement posted by @str4d explained, to my mind quite adequately, why they thought the spirit of this reason for rejection applied here.
A significant portion of the Zcash community strongly felt that ZIP 1014âs creation of the Dev Fund after the expiration of the Founders Reward was a manifest violation of their expectations. Their conviction was so strong that some of them created the first Friendly Fork â Ycash â as a branch of the Zcash blockchain that implemented their expectations. On the other hand, an even larger portion of the Zcash community strongly felt that sunsetting ongoing support and development of Zcash would manifestly violate their expectations. Thatâs governance for you.
Yes this issue does need to be addressed when clarifying this provision. There will be cases where the issue of âmanifestly violates common expectationsâ is more of a matter of opinion, and subject to interpretation.
But the provision and interpretation is nevertheless absolutely needed. I remember that one of the examples motivating this provision was a hypothetical proposal to expand the monetary supply curve significantly above the Bitcoin supply curve. Although that does involve a technical component, it could easily be framed as a governance decision. Itâs unclear what other reason given in the list would cover it (unless you consider a bound on the supply curve to be a security requirement, but there is no explicit statement of that in any Zcash specification document).
You could argue that itâs enough to allow publishing even an outrageous proposal as a draft, and then rely on the community to reject it. I disagree, because:
Notice, in any case, that âThe ZIP Editors MAY reject a proposed ZIP or update to an existing ZIP for any of the following reasons: [âŚ]â Itâs âMAYâ precisely in order to give a certain amount of flexibility, and also because the process doesnât and shouldnât rely solely on the ZIP Editors to reject bad proposals.
Someone might also argue that âmanifestly violating common expectations of a significant portion of the Zcash communityâ is too common for governance provisions (regardless of whether they are also technical provisions), and so the unimplementability / ineffectiveness provision should not be applied to them because it would be too likely to stymie progress.
To that I would argue that no such problem has been seen in practice. The provision had never been invoked before, and to my knowledge it had never got close to being invoked. (Although Iâm not a ZIP Editor any more, I still attend almost all ZIP editing meetings. I do not remember there being any serious discussion of not publishing any previous draft due to this provision.)
The only thing I can remember that might have run into this provision if it had got any further is Qeditâs proposed surveillance protocol, which they withdrew after strong pushback from me and the rest of the community. That was a grant proposal rather than a draft ZIP, but if it had been a draft then I would argue that the ZIP Editors would have been correct, in that hypothetical situation, to use this provision (and the âhas manifest security flawsâ provision) to deny publication.
The third reason given is not one of the reasons currently in ZIP 0:
- âHowever, we also feel that there is an additional reason that should be added to ZIP 0: it attempts to use the ZIP process to effect behaviour on specific Zcash ecosystem participants, without a privacy or security motivation.â
Again, it makes sense that a technical ZIP could be rejected if it did this, but doing this is kind of the point of a governance ZIP.
Please consider the parts of my response above about ambiguity of whether a ZIP or provision is governance, technical, or both; about governance only being a heuristic; etc. to also apply here.
In addition, I absolutely do not agree that âthe point of a governance ZIPâ is to effect non-privacy-or-security-motivated behaviour from specific Zcash ecosystem participants. As partial evidence of that, none of the previous governance ZIPs have needed to do so, as @str4d laid out.
The reporting requirements of ZIP 1014 are, in my opinion, security-motivated: they limit the scope for misuse of funds, and that is the main point of them in my view. If there were no security or privacy motivation then they shouldnât exist. Putting non-privacy-or-security-motivated requirements on specific parties is unduly coercive. Especially so if in practice much of the burden would fall on specific individuals whose expertise is needed for review, and who do not consent to being put under intense pressure to do highly difficult work in order, in this case, to unblock other organisationsâ and individualsâ grant applications.
Also, I do not think it is actually a problem if there is a relatively high bar for particularly controversial proposals to be published.
[*] The PR will also address an ambiguity due to the fact that there are apparent criteria for deciding whether to accept a ZIP that are outside the main list:
âFor a ZIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.â
This wording comes from the BIP Work Flow section of BIP 1 (Bitcoinâs counterpart to ZIP 0). Since it doesnât use BCP 14 keywords, it is unclear what force it has. So that needs to be cleared up. I do not actually think that being overcomplicated is by itself sufficient reason not to publish a draft ZIP â unless it is so complicated as to be necessarily unimplementable or ineffective, say.
I object to this and have flagged it for moderation. Yes I receive money (indirectly) from the dev fund. That is a declared and well-known interest. There is nothing illegitimate about it. Itâs part of my salary and I work damn hard for it. Same for anyone else this applies to.
Actually debatable. I have defended the argument that neither ECC or ZF have been legitimate at extracting part of the inflation to run a dev fund. It follows that, the money you have received may therefore not have been acquired legitimately.
Additionally, I also consider your vote as an individual (as opposed to one you could legitimately do with your ZEC tokens) as illegitimate because any dev fund spending is effectively taking money out of either stakeholders, or the security of the network, neither of which have been agreed by stakeholders at large.
You may disagree with me and Iâd be curious what you have to say, but my argument is definitely reasonable and it is shameful to censor it. On what grounds anyway? cc @Shawn
Ah, bliss. Discourse does not make it easy to Ignore/block a user with a private profile, but you can do it by going to your own profile (https://forum.zcashcommunity.com/u/USERNAME/preferences/users), selecting â
Expandâ on the top-right, then â
Preferencesâ, then the Users tab, then â+ Addâ under âIgnoredâ.
Wow. I really do not mind that people ignore me, but thereâs something really wrong going on in the project governance and it shows.
edit: I see the above post of @daira has been flagged and is hidden. Itâs not me, I am actually happy that people reading this forum can see who @daira really is, as she proudly censors opinions that she does not like and does not want other people to read.
I donât know if I agree with that. Not being paid is a good motivation to get things done IMO. Whether it works is another topic though.
Not being paid is a good motivation to go do something else where you can get paid. I certainly donât have the luxury to do this as a hobby, and I expect the same is true of very many people currently working in the Zcash ecosystem.
True, but I think it is not the ZIP Editorâs role to block a ZIP because they think it will lead to this result.
If putting the dependency on the ZSA obstructs the lockbox, and the funding stops, and you are forced to leave, that is a risk worth mentioning.
However, I donât think the ZIP editors have the authority to block it.
I hope the community votes it down, but I think it should be allowed to participate in the election because it is part of the democratic process to allow for opposite opinions.
