Edited Q3 to clarify that the disposition of the Sprout funds is out of scope for this poll. Thanks for the feedback.
2 Likes
Question 3: “broadly accepted” overstates where we actually are on Sprout
The question asserts that deprecation of v4 transactions is “broadly accepted” and that “only timing is open.” I don’t think that holds. Coinholders rejected ZIP 2003 in the early-2026 sentiment poll. That’s not broad acceptance. I’ve heard the reading that it failed only because no deadline was attached, but that’s an inference, and from talking with several large ZEC holders, I know first hand that none of them are in support of deprecating Sprout any time soon.
@daira said in this very thread that the reasons behind those no-votes still aren’t understood. If we genuinely don’t know why coinholders voted against it, we can’t declare the objection resolved and quietly narrow the question down to “when.” And there’s a discrepancy here: the open ZIP-editor concern is whether those no-votes meant outright opposition to deprecation or merely a timing problem, but the new question only asks which timing is better. It resolves a question that was never settled by quietly assuming one answer to it. As written, Question 3 gives no way to express opposition at all. “Immediately,” “one year,” and “abstain”. Every non-abstain answer is a yes.
At minimum, please add an option along the lines of “Do not set a Sprout deprecation date in NU7.” If deprecation really is broadly accepted, that option loses and we come away with a far stronger mandate than we have today. If it doesn’t lose, then the framing was wrong and we’ll be glad we asked.
4 Likes
Curious on the why? Its becoming dangerous.
2 Likes
Good question. The realistic view is that those coins are lost and will never upgrade. But for a pool this small, the precedent of deleting coins is plausibly worse than the risk of a future quantum attacker taking them.
People might compare it to the quantum situation with Bitcoin, but with Bitcoin it runs the opposite way from how it’s usually cited: Bitcoin discusses deletion because its at-risk supply is enormous. Sprout’s is 25K ZEC. The small size is an argument against deletion.
Is disabling the same as deleting though? I think we should extra clear with the language on the question.
That’s a good point. We’re talking here of disabling v4 transactions, not of deleting the Sprout ZEC.
2 Likes
I’m in favor of a third voting option on the Sprout Q, for a no-op here.
IDK how the vote will turnout, but if that gets selected, its reasonable for a follow-on vote to discern between:
- Set the latest possible last day (e.g. when we freeze sapling / orchard as well for quantum)
- Or re-propose another freeze & claim method. (Ala QR Orchard, except here claiming ends on quantum-freeze-day)
Somewhat interesting, ~70 ZEC exited Sprout since March 1st: ZCash Shielded Supply
71 to be precise ( sprout json ) , and nothing since 4/3. As dollar price goes up, so do the stakes. I say lets get ahead of it. 
- Preserve halvings. Keep the existing halving schedule for new ZEC. Only fees and donated funds are smoothed and reissued.
In the “preserve halvings” approach, there is no smoothing. This should just say “Only fees and donated funds are eventually reissued.”
- Do not include issuance smoothing in NU7. (Fee burning still proceeds.)
This needs to explicitly say that it also doesn’t reissue funds (unlike option 1).
- Do not include smoothing of the supply curve or reissuance of unissued funds in NU7. 60% of fees are still required to be unissued, and additional funds can be unissued voluntarily via
zip233Amount. What to do with unissued funds is entirely left to future governance decisions.
The ordering is odd. Why isn’t the originally proposed approach (the current option 2) given as option 1?
Also, there is no way to express opposition to requiring 60% of fees to be unissued. I would vote for ZIPs 233 and 234 but against 235, and I can’t express that vote. By giving answer 2 it would be assumed that I support ZIP 235 when I don’t. This has to be an orthogonal question, because there are actually 6 possibilities: any of 1, 2, or 3 can either require 60% fee unissuance, or not — and that is a policy question properly within the domain of governance, not just a technical decision.
[Edit: fixed the ZIP numbers.]
1 Like
Re: Sprout removal
To me, the security issue fixed in zcashd 6.12.1 demonstrates conclusively that I was right about the Sprout attack surface being an unacceptable risk. AI-assisted vuln discovery has only made it more likely that any bugs in that attack surface will be found, and possibly exploited. Also, Sprout is going to have to be removed anyway, along with Sapling, for the post-quantum transition. The alternative is not Sprout holders being able to keep their funds in Sprout; it’s an insecure protocol.
Please note: you can have a shielded protocol that allows long-term storage. Sprout is not it (as we said at launch), and neither is Sapling or Orchard. We will design one, and then you’ll realistically be able to hold funds in that pool for potentially decades.
8 Likes
Hi @daira - I address some of your comments below:
I think the important thing for respondents to understand is that funds removed from circulation are eventually recycled into future block rewards. I’m okay with your suggestion. Alternatively, a more clear version might be:
- Preserve halvings. Keep the existing halving schedule for new ZEC. Fees and donated funds removed from circulation are eventually reissued into future block rewards.
I agree that the third option should make clear that any decision about how unissued funds are eventually recycled into future block rewards will be left to future governance. I suggest a small edit to what you proposed:
Do not include smoothing of the supply curve or reissuance of unissued funds in NU7. 60% of fees are still required to be unissued, and additional funds can be unissued voluntarily. How unissued funds are reissued will be determined through future governance.
Agreed. We should make the smoothing option first since it reflects the original proposal.
2 Likes
This actually further solidifies my change of posture. I’m now in favor of deprecating Sprout, just to clarify my previous comments above the thread
2 Likes
Very good point.
1 Like
I have a high-level complaint about this poll that I want to register, then I’ll be quiet about it.
Previously, Hanh’s coinholder voting protocol was implementation-defined, only available from YWallet. Currently, the Valar Group voting protocol has a draft ZIP specification, but to my knowledge the Zodl wallet is the only wallet to have implemented the protocol, and it’s not clear to me whether another wallet implementing the protocol based on the specification would be able to participate in the poll. It’s a step forward, but I think that until we have certainty that the specification is correct, and we have multiple deployed compliant implementations of that specification, it’s not reasonable to consider a poll based on this specification to be representative of the overall community of coinholders.
9 Likes
I realize I’m late with this request, but I propose changing the text of Question 5, Benefits, first bullet from:
- Confirmation latency drops ~3× (from 75 s to 25 s average for first confirmation))
-to:
- Gives users the option of ~3× faster confirmations (from 75 s to 25 s average for initial block confirmations) with a corresponding reduction of protection against rollbacks (from 75s of mining effort to 25s).
Lower latency for confirmation is a trade-off against rollback security, and a trade-off itself isn’t a pure benefit. The benefit is the choice it gives to users between the trade-off. IMO, it’s important to make trade-offs clear for anyone casting votes.
See my post on the shorter block time proposal for more detail.
Agreed confirmation is nuanced, let’s perhaps change it to inclusion, to keep it simple?
- inclusion latency drops ~3× (from 75 s to 25 s average for time to inclusion in blockchain))
Acknowledged. It is evolving and this is a massive improvement over past polling mechanisms. Ideally more wallets will add support over time and all coins voted, tallied. We’ll have comparative data following this poll.
1 Like
Presumably this just refers to client side (as ZKP-side there is only one implementation of Zcash Orchard!). On the client side, Vizor is targetting having a compatible wallet integration of token holder voting by the vote.
On the PIR side alone, @hhanh already made a version that uses the same library client side with his stack to extend the registration period!
To clarify, this integrated the PIR but the rest uses the previous method.
I am working on replacing the complete stack at some point
1 Like
Regarding Sprout deprecation, this is a very strong argument in favor of it: https://x.com/maraoz/status/2059413451265441990
2 Likes