NU7 Sentiment Polling: Questions for Community Review & Coinholder Voting via Zodl

General
1

Title: NU7 Sentiment Polling: Questions for Community Review & Coinholder Voting via Zodl

Hi everyone,

We’re opening community review on a set of NU7 sentiment poll questions. This poll resolves outstanding NU7 scope questions following the early-2026 sentiment polling, and will run through both ZCAP and coinholders. For the first time, coinholders will be able to vote directly from within the Zodl wallet, with no separate tooling and no need to move funds to a different app. Hardware wallet users will be supported via Zodl + Keystone.

The Zodl team developed these questions in collaboration with @ebfull (Project Tachyon), @ValarDragon, @Alex_ZF (Zcash Foundation), and @aquietinvestor (Shielded Labs). Thanks to all involved.

Scope

The poll covers the remaining open items on NU7. For clarity:

Already in NU7 (established by prior consensus, not re-polled):

  • Orchard Quantum Recoverability

  • Explicit fees

  • NSM fee burning

  • Extensible transaction format

Not in NU7:

  • Project Tachyon. Universal support; targeted for a later upgrade.

  • Zcash Shielded Assets. Did not reach clear community support for NU7.

As in past polling cycles, other community groups (Engineering Caucus, ZecHub, Zcash Brasil, Zcash Español, Zcash Türkiye, and others) are welcome to run the same questions through their own panels and publish results to the forum. To allow us to interpret and compare results across groups, we ask that all polls use the exact same question language. Translations are welcome and encouraged, but please preserve the meaning and the answer-option structure so the signal stays comparable. If your group plans to run a poll, please share that in this thread.

Questions for Review

We’re giving the community 10 days to review and provide feedback before locking the final list.

Note: Selecting “Abstain” for any question registers participation without expressing a preference and is not counted as opposition.

Feedback deadline: Monday, May 25 at 11:59 PM UTC. Please reply in this thread with suggested wording changes, additional questions worth including, or concerns about scope.

Question 1 of 6. NSM issuance smoothing

The fee-burning component of the Network Sustainability Mechanism is already approved. The issuance smoothingcomponent is unresolved (84% ZCAP support, 83.5% coinholder opposition). In no case will the total supply of ZEC be affected.

Which approach do you support?

  1. Smooth issuance curve. Replace halvings with a gradual issuance curve. NSM-recycled funds reissue along the same curve.

  2. Preserve halvings. Keep the existing halving schedule for new ZEC. Fees and donated funds removed from circulation are eventually reissued into future block rewards.

  3. Do not include issuance smoothing in NU7. How unissued funds are reissued is left to future governance.

  4. Abstain

Refs: ZIP 233, ZIP 234

Question 2 of 6. When fee reissuance begins

NSM has prior coinholder approval. This question concerns the start of fee reissuance under the mechanism.

When should NSM reissuance of transaction fees begin?

  1. As soon as possible after NSM activation

  2. After the fourth halving (around 2032)

  3. Abstain

Question 3 of 6. Sprout deprecation timing

The Sprout pool was deprecated in 2018. Deposits are disabled, it holds 25,400 ZEC, and it accounts for under 0.1% of transaction volume. Deprecation of v4 transactions is now broadly accepted; only timing is open.

The disposition of the affected funds is out of scope for this poll and is not specified here.

When should v4 transactions be disabled?

  1. Immediately at NU7 activation

  2. One year after this poll concludes

  3. Abstain

Question 4 of 6. Memo bundles

ZIP 231 has been updated with additional rationale since the prior poll, where results diverged (76.8% ZCAP support, 99.3% coinholder opposition on 62 ballots).

Do you support activating memo bundles for Orchard in NU7?

  1. Yes

  2. No

  3. Abstain

Question 5 of 6. Faster block times

Reduce block target spacing from 75s to 25s, with per-pool action limits at 2 MB blocks?

Daily ZEC issuance unchanged.

Benefits:

  • Inclusion latency drops ~3× (from 75 s to 25 s average for time to inclusion on the blockchain)

  • Orchard TPS roughly 2× (2.9 → 6.1 TPS for standard 2-action transactions)

  • Worst-case shielded sync bandwidth reduced 42% (270.5 → 156.83 MB/day)

  • Worst-case trial decryptions reduced from 4.8M to 2.1M/day

Costs:

  • 3× as many blocks per day, raising overall consensus and full-node sync work

  • Sapling per-block capacity reduced (still 3.0 TPS, above current Orchard 2.9 TPS)

  • Stale rate rises from ~0.4% today to a projected 3.26% (devnet measured 4.86%, below Ethereum PoW’s 5.4% historical threshold)

  • Extra ~200 KB/day of compact-header bandwidth for light wallets

Choose:

  1. Yes

  2. No

  3. Abstain

Ref: ZIP 218

Question 6 of 6. NU7 schedule

Do you support scheduling NU7 as soon as feasible, with these contents?

Always included: Orchard Quantum Recoverability, explicit fees, NSM fee burning, extensible tx format.

Conditional on this poll:

  • NSM issuance smoothing if Question 1 is option 1 or 2

  • Sprout deprecation at the block height implied by Question 3

  • Memo bundles if Question 4 is Yes

  • Faster block times and per-pool limits if Question 5 is Yes

Readiness clause: A feature is “ready” when spec, audit, and testing are complete, as certified jointly by Zodl, the Zcash Foundation, and ZIP Editors. If a feature is not ready by July 15, 2026, it defers to the next upgrade rather than delaying NU7. Dependent features defer with their dependencies. Note that shipping some features separately could introduce long-term maintenance costs.

Choose:

  1. Ship NU7 as soon as possible, removing features as necessary to meet the proposed deadline.

  2. Ship NU7 as soon as all of the features approved by this poll are complete.

  3. Abstain

Target Polling Window

These dates are a target. Because this is the first coinholder poll conducted through Zodl, the schedule may shift pending final software testing. We’d rather slip a week than ship a voting flow that isn’t ready. Feedback is welcome on these targets and durations as well.

  • May 25, 11:59 PM UTC : Question feedback closes; final list locked

  • June 1, 11:59 PM UTC : Registration window closes (snapshot of your coins in the wallet at this time)

  • June 10 : Polling opens for ZCAP and coinholders

  • June 29, 8:00 PM UTC : Polling closes

  • June 29 : Results posted

The 3-week polling window is consistent with the January NU7 Sentiment Poll cadence. If we determine more time is needed for review or discussion, we’ll extend.

We’ll confirm or revise the dates by end of May as testing progresses, and post the exact registration block height alongside the final question list.

Coinholder Voting via Zodl

We’ve been collaborating with @ValarDragon and his team to build a privacy-preserving coinholder voting mechanism directly into Zodl. The goal is to make participation as simple as opening the app.

Two voting paths are supported:

  • Zodl — vote directly from the Zodl mobile wallet using your in-app Orchard funds.

  • Zodl + Keystone — pair Zodl with a Keystone hardware wallet to vote with Orchard funds held in cold storage. Your keys never leave the device.

Here are a few screen shots to give you an idea of the UX.

Poll@2x
Poll@2x786×1704 101 KB

Question 1 -_ Voted
Question 1 -_ Voted393×852 20.2 KB

Review Answers
Review Answers393×852 39.1 KB

The build is targeted to be ready end of May or early June, depending on final testing. As soon as the poll ships, we’ll post instructions for both paths and the exact block height anchoring the snapshot.

A few things worth noting up front:

  • Eligibility is based on Orchard notes held within the registration window. We’ll publish the exact block height range alongside the final questions.

  • The voting mechanism is open and verifiable. @ValarDragon and team have done the heavy lifting on the voting protocol design; we’re focused on making it accessible at the wallet layer.

  • Custom poll sources are supported via a config option, and so the same mechanism can be used by other community-run polls in the future.

What’s Next

Please share feedback on the questions in this thread by May 25. We’ll post a follow-up by end of May with:

  • Final question list

  • Confirmed registration block height and snapshot date

  • Voting instructions for Zodl and Zodl + Keystone

  • Updated timeline if testing requires schedule changes

Thanks again to @ebfull , @ValarDragon , @Alex_ZF , and @aquietinvestor for the collaboration on the questions, and to @ValarDragon and team for the voting mechanism work that makes in-wallet coinholder polling possible.

30 Likes
The Path to Billions. ZODL Update
Expanding the June 2026 Zcash Community Advisory Panel
2

Thanks for the hard work putting this together.

Just as a clarification: while I did contribute feedback and collaborate on the questions early on, a couple months ago I withdrew from this particular drafting/polling process. As far as I can tell, it looks like ya’ll did a great job.

8 Likes
3

Hey, thanks for getting these questions out! Excited for this poll to get out.

Two questions:

  • June 1, 11:59 PM UTC : Registration window closes (snapshot of your coins in the wallet at this time)
  • June 10 : Polling opens for ZCAP and coinholders

Why do we have a 9 day delay? Lets just open polling June 2nd? The PIR snapshots, take sub 15 minutes to generate.

  • June 24, 8:00 PM UTC : Polling closes
  • By June 29 : Results posted

What is this 5 day delay before results getting posted? Its available in sub 5 minutes. It’s been this way since the beginning! It’s in the UI that we PR’d and your team merged into ZODL, and everyone has been testing with. Is this a 5 day wait for a forum post?

I do want to clarify to folks that for Question 6, if option 1 is selected:

  • extensible tx format
  • Memo bundles

being in the upgrade requires us to be careful were not introducing unspendability risk for users on Ledgers, similar to past transaction format upgrades. Same reason why QR isn’t going to enable sends until Keystone updates. So there is a serious chance they may not make it into the July 15th date. Otherwise everything consensus side is actually code-ready, and its really just zcashd deprecation side. @valargroup has an internal NU7 testnet running with the latest versions of (NSM, Sprout deprecation, Block time reduction), and we plan to make a public one over the next week.

5 Likes
4

It gives people time to move their coins to Zodl if they are stored elsewhere. Flexible timing.

The coinholder poll is only 1 of n polls. It’s worded as “by June 29.”

4 Likes
5

Impressive work, congratulations to all!

2 Likes
6

I’m a little worried about ledger integration too. After so much time, I wouldn’t want the result released in July to break after a few weeks. I hope for effective coordination with their development team. It’s better to release later than to have problems after release imho.

7

Thank you for listening to community feedback and integrating polling into Zodl!

This is a major step forward for Zcash’s governance. I expect significantly stronger participation from coin holders in the upcoming polls. Hopefully other wallets integrate this feature as well.

2 Likes
8

Happy keystone / zodl users can now vote directly, much needed.

In the past we have experimented with ywallet, zkool, and a seperate voting app and now we are adding Zodl. How do you see voting being done in the future? Will each election have to use a certain system or will we consoldate features and unify under some framework? I think having a choice is super important and shouldn’t be minimized.

Yes, yes yes. We need to put the pedal to the metal and get NU7 and zcashd dep done.

Thanks to all the teams who have been working on this behind the scenes, I dont say it enough: Thank you :shield: :zebra: :heart_suit:

8 Likes
9

It’s the intention that coin holder polling can be standardized across all wallets using this PIR-based protocol. Any group should be able to surface polls, and any wallet should be able to offer those polls within their interface.

7 Likes
10

It gives people time to move their coins to Zodl if they are stored elsewhere. Flexible timing.

Great! I’m excited about compressing the time! Mostly suggesting it makes sense to bring this closer to the voting open date. e.g. bring coinholder voting open date beginning closer to june 1st or push the registration date to June 8th.

The coinholder poll is only 1 of n polls. It’s worded as “by June 29.”

Ah thank you! Forgot about the non-coinholder polls is how it works.

I’m a little worried about ledger integration too. After so much time, I wouldn’t want the result released in July to break after a few weeks. I hope for effective coordination with their development team. It’s better to release later than to have problems after release imho.

Agreed, but my bias would actually be to ship the upgrade first (take option 1), and slate those features for a subsequent upgrade! Lets get more upgrades sooner, and do more consensus upgrades.

Will each election have to use a certain system or will we consolidate features and unify under some framework?

Planning to help more wallets integrate. All the code is fully open source, and built to be integrated!

3 Likes
11

so when I open my zodl wallet I see no place to vote is this going to be a upgrade to the app? where do we go to vote?

thx

1 Like
12

Yes, it will be released in conjunction with the first poll.

3 Likes
13

For question 1 about the NSM: Is option 1 easier/quicker to implement than option 2?

For question 4 about Memo bundles: Is it compatible with the upcoming Tachyon pool?

14

Option 2 (smoothing) is easier to implement and a more straightforward design than option 1 (preserve halvings), though both options require relatively minimal code changes. We are prepared to implement either approach in NU7 depending on the outcome of community and coinholder consensus. The difference is that option 2 maintains a single issuance path, while option 1 requires maintaining two issuance paths: the existing issuance logic that halves every four years and the new smoothed curve for recycled NSM funds.

So the main distinction here is less about implementation burden and more philosophical and optical. Many people strongly associate halvings with Bitcoin’s monetary design, so preserving halvings carries important symbolic value for some members of the community even if the long-term economic impact between the two approaches is relatively small.

5 Likes
15

Quick question: why won’t this be recycled via the NSM? If you think like many of us do that ZEC’s price will be much larger in the future, burning 25,400 ZEC (worth ~$12M at current prices) is effectively burning hundreds of millions, if not billions, of dollars of future value that could be used for the security budget.

3 Likes
16

Nice opinion

17

Is it? Or should we poll for support too?

I recognise that providing no alternative is quite useless of my part, but I don’t think this wording achieves anything. Find it unlikely that people will (i) click, (ii) read and (iii) understand. I would expect a high degree of abstains.

Are there nuances we could take the opportunity of trying to clarify? None come to mind, but maybe there’s a way to provide a platform for next step? (whatever that might be)

1 Like
18

While you wait for Josh’s response, I’d like to say that I think the right thing to do is not to use those funds. In some way, they belong to someone, and we don’t know the reasons why they haven’t moved those coins.

This situation is somewhat similar to the issue of Satoshi’s coins in Bitcoin. For me, the most important thing is not to set a precedent of confiscating or controlling other people’s coins.

19

An option could be creating a lock box on orchard managed by the foundation with the same amount of sprout funds (provided by volunteers) and give some time (ie. 10 years) to claim them (1 sprout zec = 1 orchard zec). But I don’t know if someone can be able to provide a proof to claim funds with v4 txs disabled preserving privacy.

1 Like
20

It should be fine. The validation code can be extracted and made to work independently from the tx format. However, it puts the burden on the lockbox trustees to manage disembursement for small amounts.

1 Like