NU7 Token Holder Vote

[ebfull]

Valar Group and Project Tachyon are calling for a coinholder vote to begin August 25, 2026 and last approximately 18 days. The vote will decide on NU7 Scope, mirroring the previous poll that was cancelled due to the Orchard counterfeiting bug and Ironwood / NU6.3 work.

This thread describes the questions we’ll include in the poll and some information about the voting protocol. We’ll be updating this thread with additional details in the coming days.

The Tokenholder Voting Chain

This vote is happening on a dedicated voting chain, using audited technology developed by Valar Group to replace our previous THV process. We encourage shielded Zcash wallets to allow their users to vote on this chain, as it preserves their users’ privacy while keeping their funds safe.

Wallets can configure different voting chains. It is permissionless to spin up your own voting chain; voters must only modify a configuration to participate in a different process, and we encourage wallets to permit their users to do so.

The default voting chain will permit voting when at least two organizations call for it:

• Five organizations will be configured: Project Tachyon, Valar Group, Zcash Foundation^[1], Zodl, and Shielded Labs. This forms a coordinator multisig. These are adjustable parameters that can be modified in between votes based on feedback and experience.
• There is a distributed election authority that runs the vote and produces its results. It consists of at least 10 validators who exclusively hold per-round decryption key shares. Validators cannot learn the identity of voters, and only the final tally can be recovered by at least two thirds of the validators.
  • Reach out if you’d like to be a validator!

NU7 Scope Poll

Valar Group and Project Tachyon are planning to call for a vote on this chain to begin on August 25, 2026 and last ~18 days. Specifically, eligible voters need spendable shielded funds in Ironwood at the time of a blockchain snapshot that occurs on August 24, 2026 at 19:00 UTC. Funds can be moved immediately after the snapshot. Eligible ZEC can vote until September 12, 2026 at 19:00 UTC. The results will be published shortly after the vote concludes.

We consider the results legitimate and representative of coinholders if at least 1,000,000 ZEC participates. We have confirmed that Vizor will support the voting process, and we hope that Zodl and other wallets do the same.

We plan to ask the following questions, adapted from previous poll questions. Please provide feedback in this thread. We have removed proposals that would involve a transaction format change.

Q1 (NSM Issuance Smoothing)

The fee-burning component of the Network Sustainability Mechanism is already approved. The issuance smoothing component is unresolved. 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 newly minted 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.

Q2 (NSM Reissuance Start Date)

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.

Q3 (Sprout Deprecation)

The Sprout pool was deprecated in 2018. Deposits are disabled, it holds less than 23,000 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. Do not set a v4 transaction deprecation date.
4. Abstain.

Q4 (Faster Block Times)

Should we reduce the target block time from 75s to 25s, and introduce per-pool action limits, per [ZIP-218]?

1. Yes.
2. No.
3. Abstain.

Q5 (NU7 Schedule)

NU7 will include NSM fee recycling, and be consistent with the results of this poll, assuming each feature is implemented by September 30th. How should non-ready features be handled?

1. Ship NU7 as soon as possible, removing any feature that is not implemented by the September 30th deadline.
2. Delay NU7 until every feature in this poll is deemed complete.
3. I do not support this NU7 plan.
4. Abstain.

How to Audit

The voting protocol is intended to be open and reusable: any group should be able to surface polls, any wallet should be able to display them, and anyone should be able to run a chain or audit a result.

• Voting chain code / how to run a validator: https://setup.valargroup.org
• Audit a published tally: https://tally.valargroup.org
• Run your own chain or stand up a self-hosted admin UI: GitHub - valargroup/vote-sdk: Cosmos SDK application chain for private on-chain voting using Zcash-derived cryptography · GitHub
• Run your own PIR server: https://setup-pir.valargroup.org
• Add your infrastructure to the recommended wallet config.
• Documentation: Introduction | Valargroup Docs
• Code
  • vote-sdk (chain):
  • voting-circuits: GitHub - valargroup/voting-circuits · GitHub
  • vote-nullifier-pir: GitHub - valargroup/vote-nullifier-pir: Private Information Retrieval (PIR) system for Zcash nullifier non-membership proofs · GitHub
  • zcash_voting (client): GitHub - valargroup/zcash_voting: Zcash shielded voting library — core protocol, proof generation, storage, and FFI bindings · GitHub

---

1. We have not received a coordination key from the Zcash Foundation yet. ↩︎

[dismad]

@ebfull

• Five organizations will be configured: Project Tachyon, Valar Group, Zcash Foundation , Zodl, and Shielded Labs. This forms a coordinator multisig. These are adjustable parameters that can be modified in between votes based on feedback and experience.

Have yall reached out to each of the key orgs to coordinate this? It does seem a bit rushed, considering everything going on.

[thowar2]

Clearly all the orgs were aware of this:

But a single org should not be able to block a token holder vote. In fact any token holder should be able to call a vote!

The good news is Zcash is getting decentralized and is not dependent on any single organizatiom to make progress. Great for Zcash!

[palmar]

Thanks, Sean. Can you give us more details about multi-signatures and validators? And more generally, how does this new system offer an advantage over the previous voting system? I like the idea of ​​including several organizations, although I wonder the same thing as Dismad.

[ValarDragon]

New features of this voting system:

• Supports voting from hardware wallets (Keystone)!
• Has no registration period, just a snapshot height
  • Leverages PIR to achieve this with no privacy leakage and less bandwidth!
• Maintains far stronger balance privacy guarantees.
  • All votes are homomorphically encrypted to the validator set. Only the aggregate amount of “YES/NO/ABSTAIN” for each question is shown. Previously it could be learned - leaking many people’s balances. The exact problem were solving in Ironwood migrations with ZIP-318 as well
  • All votes are split up into 16 unlinkable ballots, so that even if the validator set colluded, balance-privacy is retained.
• Much easier to run nodes, call votes, and audit the votes
• Available in popular wallets!

The multi-sigs is checked in two parts:

• The chain validators require it to do the requisite processing work to allow a vote
• The wallets check it for a different reason. Wallets dynamically get configs for each live vote, and these are “ratified”, by the multi-sig to fix an edge case.

A longer post on this coming tomorrow.