Zcash Coinholder Voting Explained: How ZEC Holders Direct Retroactive Grants

Most people know they can hold ZEC. Fewer know that ZEC holders can also vote on whether specific pieces of completed ecosystem work get paid out of a shared fund. This guide explains how that works: what the Zcash Improvement Proposals (ZIPs) say, what has changed from one voting round to the next, and, just as important, what the vote does not do.

The one idea to keep in mind: coinholder voting directs a specific funding program. It does not give ZEC holders direct control over the Zcash protocol, and it is not general-purpose on-chain governance.

Zcash Coinholder Voting in 60 seconds

• What it is. A process where ZEC holders vote on grant proposals for completed work. Approved grants are paid from the Coinholder-Controlled Fund.
• Where the money comes from. The funding model in ZIP 1016 sends 12% of the block subsidy toward that fund and a separate 8% to Zcash Community Grants (ZCG), a different program.
• Who can vote. The ZIP restricts no one and sets no personal minimum. Voting is weighted by ZEC. The tools, snapshot rules and eligible pools are set per round and have changed.
• What makes a proposal pass. At least 420,000 ZEC participating in that proposal's vote, and a simple majority in favor.
• Who pays. Three Key-Holder Organizations hold the keys to a 2-of-3 multisig, so any two must sign a payment. They can stop a grant only in narrow cases, and they cannot override a rejection.
• What it does not do. It cannot change consensus rules or activate a network upgrade.

Specification vs. practice vs. proposed changes

The ZIP repository labels the key documents "Proposed", not "Final". That label is about the document's place in the ZIP process. It does not mean nothing has been implemented, and it does not mean the system is final. This table keeps the three layers apart.

Why Coinholder Voting exists

Until the second halving in November 2024, Zcash directed part of each block's subsidy to development organizations. Under the rules in place then, from that halving on, 100% of the subsidy would have gone to miners and nothing automatically to development funding. ZIP 1015 set up two replacements for the following year: a stream for Zcash Community Grants and a protocol-tracked "lockbox" of deferred funds.

ZIP 1016 was written because those streams were due to stop in November 2025. It aims to decentralize decision-making, hold stakeholders accountable for outcomes, stay flexible enough to change, and make clear who decides. Its answer is to split funding into two channels: one decided by a committee (ZCG), and one decided by the people who hold ZEC.

Where the money comes from

During the funding period, the block subsidy is divided like this (see the mining explainer for how the rest reaches miners):

• 8% goes to Zcash Community Grants, the committee-run program.
• 12% goes toward the Coinholder-Controlled Fund.
• The remainder goes to the miner.

ZIP 1016 limits this arrangement in time: it runs until the third halving, "allowing enough time to determine whether it should be changed or codified for longer." At today's block spacing that is block 4,406,400, and the halving explainer tracks the estimated date. Draft ZIP 214 Revision 3 would adjust the end height if NU7 activates first, and NU7 is not active — see the NU7 explainer.

ZIP 1016 describes the Coinholder-Controlled Fund as seeded by the existing Deferred Dev Fund Lockbox and supplemented by the 12% stream. Those are two different things, and it is easy to confuse them.

The 78,750 ZEC initial fund vs. the ongoing 12% stream

Read together, ZIP 1016 and ZIP 271 mean that the spendable part of the fund today is the initial disbursement. The ongoing 12% is real, accruing, and counted at the protocol level, but it cannot be paid out to grant recipients by the multisig. Any description of "the fund" that blurs those two is overstating what can currently be spent. ZIP 1016 itself leaves details of the voting model to a further ZIP, marked "TBD".

Who can vote?

The stable rule comes from ZIP 1016: no organizations or individuals are restricted from voting their coins. The ZIP sets no minimum personal balance and mentions no identity requirement for voters.

Two things are easy to confuse with that:

• The 420,000 ZEC figure is not a personal minimum. It applies to each proposal's vote as a whole (see below).
• Know-your-customer rules apply to recipients, not voters. The Financial Privacy Foundation (FPF) application material requires grant recipients funded above $50,000 USD to provide KYC information. That is a condition of being paid, and it has nothing to do with whether an ordinary ZEC holder may vote.

The practical details are not stable: which wallets support voting, whether there is a registration window, which shielded pool counts and at what snapshot. Those are set per round. See the dated box further down and the official announcements.

How voting power works

ZIP 1016 weights votes by ZEC. For competing proposals, it picks the winner by "the highest total ZEC value committed in support." In plain terms: more ZEC means more weight, and the weight is measured in ZEC, not in head count. Because of that, how concentrated the participating ZEC is can shape outcomes, and that varies from round to round.

What is not a permanent rule is the measurement mechanism. Earlier rounds used a registration window; the Q1 2026 polling announcement said the voting mechanism had changed and told voters to use a specific wallet app. When the Q2 2026 round was postponed, the announcement explained that the voting protocol then relied on Orchard notes to determine voting power. Those details are historical or round-specific, and the Zcash Community Forum's retroactive grants announcements are where each round's rules are posted. If you want a wallet to start with, see our wallet guide.

The 420,000 ZEC threshold

ZIP 1016 sets the approval rule: a minimum of 420,000 ZEC (2% of Zcash's eventual 21 million supply) "MUST be voted, with a simple majority cast in favor, for a grant proposal to be approved." That is two separate tests:

1. Participation: at least 420,000 ZEC must take part in that proposal's vote.
2. Majority: a simple majority must be in favor, under the round's vote-counting rules.

Every vote is independent. The same ZEC can be used in many proposal votes at once, which is deliberate: it avoids vote-splitting, where a plurality rather than a majority could win. Nobody needs 420,000 ZEC in a wallet. The ZIP also lists the threshold as an open question ("Is 420,000 ZEC the right threshold?"), so treat it as the current rule, not a fixed constant.

Approve, Reject and Abstain

The ZIP names approval and a majority in favor, but it does not define the ballot options or say how abstentions are counted: the word "abstain" does not appear in ZIP 1016 or ZIP 271. Each round's procedure fills that in, and the options have varied:

• The Q1 2026 polling announcement says each proposal had three options (Abstain, Approve, Reject) and that Abstain was the default selection. A preselected Abstain is not a vote for a project.
• The Q3 2026 announcement describes four options: Accept; Reject (do not support the proposed project); Reject (would reconsider in a future round at a lower amount); and Abstain. It says both Reject options are tallied as "no" votes, and that Abstain is the default selection.

Whether abstentions count toward the participation floor, and whether they affect the majority calculation, is not set by ZIP 1016's text. That is why participation and approval percentage are different concepts. A hypothetical, with invented numbers: if 500,000 ZEC take part in a vote, split 200,000 Approve, 100,000 Reject and 200,000 Abstain, then the result depends on whether the rules measure the majority against the 300,000 ZEC that took a side or against all 500,000. Read the counting rules and results post of the round you care about rather than assuming one interpretation.

How a retroactive grant moves from application to payment

A retroactive program pays for results after the fact. A conventional program works the other way round: promise, then funding, then work. Here, the order is work, then demonstration, then public review, then a vote, then possible funding.

Things to weigh, neutrally:

• Benefits. Voters judge delivered work instead of promises, and there are no milestones to manage.
• Trade-offs. Builders typically have to fund the work themselves first, funding is never guaranteed (coinholders are not obliged to fund any grant and may leave funds at rest), valuing finished work is subjective, and, because weight follows ZEC, participation and concentration can influence outcomes.

Who are the Key-Holder Organizations?

Current specification (ZIP 271). The one-time disbursement goes to a 2-of-3 multisig whose keys are held by three "Key-Holder Organizations": the Zcash Foundation, the Electric Coin Company and Shielded Labs.

What they do, per ZIP 1016:

• They administer the fund according to coinholder votes, and should sign the payment transactions for approved grants.
• They are bound by a legal agreement to use the money only as the ZIP specifies.
• They can veto a grant in two cases: any one of them declares that funding it would breach a legal or reporting obligation, or two or more of them declare a principled objection on grounds of harm to Zcash users or the community's values. A veto can stop payments even after a passing vote, which the ZIP expects to be unusual.
• They cannot veto a coinholder rejection.

The veto path exists in practice, not only on paper: FPF's public tracker has a "Vetoed by Key Holder" label, and it is applied to at least one application that coinholders had approved. The tracker does not publish the reasons, so this page does not describe that case.

The security model. Any two of the three keys can move the funds, so the structure resists the loss of one key. ZIP 271 states that compromise or loss of two of the three keys would mean total loss of the funds, and that if a single key is lost or compromised the holders must set up a new multisig and move the funds. This is a design trade-off, not a prediction of trouble.

ZCG vs. Coinholder-Directed Retroactive Grants

These are two programs, run side by side. Neither replaced the other.

Q3 2026: a real-world example

The example illustrates the stages above: a fixed calendar, a public review before any ballot, independent votes per proposal, and results that depend on both participation and majority. Future rounds may differ.

What Coinholder Voting does — and does not — control

These votes direct funding decisions under one program. They do not automatically:

• modify Zcash's consensus rules;
• activate a network upgrade;
• oblige node-software developers to implement a proposal;
• replace the normal ZIP and network-upgrade process.

ZIP 1016 says this itself: changes to Zcash protocol governance are outside its scope. Its own note reads: "Nothing forces developers of Zcash consensus node software to implement any particular proposal." A process like this "fundamentally cannot affect the autonomy" of those developers, or of the node operators who choose what to run.

Three different things are easy to blur:

1. Funding votes, covered here: ZEC holders direct a specific fund.
2. Sentiment polls, such as the coinholder polls run in 2026 about NU7's scope. They gauge opinion. A Draft ZIP (ZIP 259, NU7's deployment) cites them in its rationale; a poll by itself enacts nothing.
3. Consensus changes: a ZIP, an implementation, a release, and adoption by the network. See the network upgrade tracker and the governance explainer.

How to participate in future rounds

The concept is steady, even though the tools change:

1. Hold ZEC in a wallet that supports coinholder voting for the active round.
2. Read that round's official announcement for the eligibility rules (which ZEC counts, any snapshot or registration step).
3. Review the proposals during the public review period.
4. Cast your ballot in the tool the announcement names, before the deadline.

Do not follow instructions from older rounds, since earlier procedures differed. Treat any request for your seed phrase, or to send ZEC to an unfamiliar address, as a red flag and confirm instructions through the official channels below.

Timeline

Risks, limitations and open questions

• Status gap. The ZIPs still read "Proposed" while their funding streams operate. Readers should not infer finality from either the label or the operation.
• Unfinished pieces. The ongoing 12% stream awaits a disbursement mechanism, and ZIP 1016 leaves parts of the voting model as "TBD."
• Trust model. Payments depend on Key-Holder Organizations signing, and on a 2-of-3 key structure that has real key-management risk.
• Weighting and concentration. Votes are weighted by ZEC, so influence follows holdings.
• Subjectivity. Putting a price on finished work is a judgment call.
• Changing procedure. Tools, snapshots and counting rules change between rounds; abstention handling is not defined by the ZIP.
• Time limit. The model is scheduled to end at the third halving unless it is renewed or replaced.

Learn more

• Who Runs Zcash? Governance explained
• Zcash network upgrades timeline and the Network Upgrade Tracker
• How Zcash mining works and the halving explainer
• Glossary: ZIP, block subsidy, lockbox, Zcash Community Grants, coinholder voting
• The Zcash ecosystem hub, for the projects these grants fund

Sources & methodology

Checked directly on October 1, 2026, in the zcash/zips repository at commit a735caf:

• ZIP 1016: Community and Coinholder Funding Model
• ZIP 271: Dev Fund Extension and One-Time Disbursement
• ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding
• ZIP 255: Deployment of the NU6.1 Network Upgrade
• ZIP 214: Consensus rules for a Zcash Development Fund
• Draft: Update to ZIP 1016 & ZIP 271: Key-Holder Organizations
• Zcash ZIP index
• Financial Privacy Foundation: Coinholder Grants Program repository (application form, and the public tracker of applications and result labels used for the Q3 counts)

Official round announcements (linked rather than reproduced; procedures and dates change by round):

• NU6.1: Coinholder-Directed Retroactive Grants Program
• Registration: Coinholder Poll to Ratify the Retroactive Grants Program
• Polling Closed: Q1 round
• Q2 2026: 30-day review (postponed to Q3)
• Q3 and Q4 program dates
• Q3 call for proposals
• Shielded Labs: Zcash Coinholders Approve Retroactive Grants Program

What we did not do. We did not independently inspect the on-chain 78,750 ZEC disbursement, and we could not open the forum's Q3 results post. The Q3 counts come from labels on FPF's public tracker (read October 1, 2026), with the requested amounts summed from each entry; voter participation figures are omitted because we could not confirm them against a primary source. The specifications are described as of the date above and ZIP statuses can change.

Something outdated? Tell us in the @ZecZcash Telegram channel and we'll fix it.