I thoroughly agree. This is not how we previously built Zcash — it has always been our practice to write open specs and implement to those specs. We have strongly resisted any temptation to fall back to “the implementation is the spec” (with the exception of the transparent protocol, to our detriment). I personally believe that has been an essential contribution to our good track record of avoiding exploited security vulnerabilities.
The coin-holder voting work has been done on a schedule that —taking into account our other workload— hasn’t allowed the same degree of care. It is specified, but the spec hasn’t been reviewed or compared to the implementation with the rigour I would like. This is disappointing because AI is very good at comparing specs and implementations. To clarify, this isn’t about whether I have, or any other specific cryptographic engineer has time to review things; it’s about the policy question of what is considered a blocker on deploying them to production.
I’m frankly not sure why the rush was necessary. As I’ve said many times, the current Zcash governance specifications do not define any role for coin-holder voting to make decisions about protocol evolution (as opposed to grants). If the community wants to change that, there should be a formal proposal to change it that we can comment on and critique; not an assumption that it has already happened.
Thank you everyone. I edited the questions in the first post to capture what I believe we’ve all agreed upon. If I have made errors or omissions, please let me know.
[Scope section and Question 1] “NSM fee burning” → “NSM removal of funds from circulation (ZIP 233)”
The “Faster block times” question should say that the parameters are subject to further technical adjustments, since ZIP 218 is still in Draft.
Substantive:
I continue to think we should have a separate question on ZIP 235. The wording would be as follows:
Question 3 of 7 (and renumber subsequent questions). Removing fees from circulation via the NSM
Should 60% of fees collected for each block be required to be removed from circulation?
No, no such requirement.
Yes, but less than 60%.
Yes, 60%.
Abstain.
The question about Sprout deprecation timing says “The disposition of the affected funds is out of scope for this poll and is not specified here.”
I believe this creates uncertainty that might affect people’s votes (e.g. voting 2 or Abstain where they might otherwise have voted 1), or raise unnecessary controversy or objections to the poll, even in the absence of objections to anything that is actually proposed. The only realistic options for where those funds might go are back to their original holders (via a mechanism that does not substantially increase the attack surface), or removal from circulation via the NSM. No-one is proposing, or would get away with proposing in future, that they just be granted to some arbitrary party. That should be made clear.
Everyone should also be aware that if a balance violation vulnerability is found in the Sprout pool, the Zebra and (if still in use) zcashd devs might decide to make emergency releases to freeze it anyway, and would not be constrained in doing so by the result of this poll.
For the NU7 schedule question, the wording of option 2 allows essentially a blank time check. I don’t think anyone actually wants that. In practice, we would still drop features if they’re not ready by a reasonable date, it’s just that this date may be later than July 15, 2026 (say, two months later).
That option would require that we either re-enable v4 or add a Sprout bundle type to v6, which would reintroduce the previous attack surface, so I don’t actually think it is likely to happen. A future mechanism to recover Sprout funds might be time-limited but to be clear, that’s not what we’re voting on.
I heard an idea to introduce a potential sprout ZSA, not sure of the details, but perhaps it could offer a potential solution that keeps more folks happy.
Per your request during the last polling round, the ZIP 235 question was broken out into a separate question [1]. All community panels and coinholders voted in support of unissuing 60% of transaction fees via the NSM. See the consolidated results below.
Generally speaking, I do not think we should re-poll questions simply because certain people are unhappy with the results, but that is especially true here given that the outcome received overwhelming support from both coinholders and every community panel. Re-polling in situations like this sets an extremely bad precedent.
I also do not think it makes sense to introduce a new “less than 60%” option at this stage. There has never been a proposal for anything other than 60%, and when you requested that the ZIP 235 question be separated out in the prior poll, you did not ask for that option to be included. So I do not understand the rationale for introducing it now, after the prior polling results are already known.
Changing the available options after results are known risks creating the perception that previously settled questions are being reopened in search of a different outcome. That undermines the credibility of the polling process.
Footnote:
[1] You asked for the NSM question to be split up:
I conceded and the question on ZIP 235 was presented as a separate question:
Someone else did: @ValarDragon — and I agreed. The only reason for that option not to be included was that the suggestion was made too late.
Note that my own proposal for what questions should be included in this poll did include this question all along. I’m not just raising it now.
The reason I suggested this to be re-polled is that in the previous poll, if all the coin-holder funds voted against the NSM as a whole had been voted against ZIP 235, then the latter would have lost in the coin-holder vote. Specifically, in that poll 925,478 ZEC voted against protocol support for the NSM as a whole, while only 383,409 voted for 60% fee unissuance. As a maintainer trying to figure out what should actually go into the software, I find that result uninterpretable. It’s not about my own opinion on the question.
Just because some coinholders voted against the broader NSM proposal in Q2 does not necessarily mean they would have voted against ZIP 235 in Q3. My understanding from major coinholders who voted against Q2 is that a lot of the opposition was tied to ZIP 234 smoothing the issuance curve and eliminating halvings, which is exactly why we are now re-polling on ZIP 234 and proposing an alternative that preserves halvings.
In the prior poll, when people were asked directly about unissuing 60% of transaction fees via the NSM, both the community panels and coinholders overwhelmingly supported it. Personally, I would interpret coinholders who voted against the broader NSM proposal but did not vote against ZIP 235 itself as effectively abstaining on the ZIP 235 question, not opposing it.
The point is, a significant amount of coinholder stake still directly participated in the ZIP 235 question itself. A total of 478,408 ZEC voted on the question, with 383,409 ZEC in favor and 94,999 against. That level of participation exceeds, for example, the 420,000 ZEC threshold we use in the coinholder grants program to determine whether a vote is materially representative of coinholder sentiment.
Given that a large amount of coinholder stake and all community panels supported ZIP 235, my current view is that we should not re-poll this question. That said, I want to make sure I’m thinking through this carefully, so let me discuss it internally with my team, the Zcash Foundation, and also @ValarDragon to get their perspectives. I will follow up on this by end of day tomorrow.
On NSM fee splits, this was voted yes on in the prior poll at 60%. In the first poll I was unhappy about choice of 60% in particular, but given it was YES’d, I think its fine. My complaints with it aren’t that serious, and I think forward progress is way more important than my opinions on parameter choice. Also I only later realized, how much of a nothing-burger tx fees are relative to block reward, even if we fully filled blocks today.
I think a culture of revoting impedes a lot of progress. Revotes should only be allowed if:
Materially new information came in. (E.g. security problem)
Enough time from first vote has elapsed. (Its a parameter if thats 6 month vs 1 year vs 2 years, etc)
Otherwise no doesn’t mean no, and we can’t get alignment to progress on the things that everyone would agree makes Zcash better.
So on the particular detail of NSM being 60% fee, I think it was passed and should not be changed in the polling here. We did hit all historically established quorums for having a sufficiently high amount of turnout on this Q
Agreed. ZF supports treating ZIP 235 as approved based on the clear support it already received in the previous poll, separate from specifics of the reissuance mechanism. Keeping it off the new ballot is the right call to streamline the process.
UPDATE:@ebfull + @ValarDragon, Shielded Labs, the Zcash Foundation, and Zcash Open Development Lab (ZODL) reached consensus and announced yesterday that NU7’s scope will be focused on the activation of a new Orchard-based pool called Ironwood.
As a result, this poll will be paused for both coin holders and the Zcash Foundation ZCAP. In the coming weeks, we’ll discuss sentiment gathering for the post-Ironwood Zcash.
Saw you post this on X today and wanted to bring up something implemented on the Ergo blockchain, that has a demurrage/ storage rent policy that is implemented on unspent UTXOs after 4 years. It at least puts some onus on users to be active or at least do some sort of UTXO defragmentation exercise over periods of dormancy. Super cool idea, although that chain never really gained much adoption to see it play out at scale.
Zodl for owners with slow delayed recycle into NSM (as 