Zcash governance has a specification. It is numbered ZIP 0, its own status is Active, and it names the 9 people who can assign a proposal a number. It lists which organization each is associated with, and prints their declared conflicts of interest alongside their names.
Almost nobody opens that document, which is the reason the usual account of how this chain is governed is considerably vaguer than the specification it could simply be quoting from.
what follows reads that document and reports what it establishes. Our guide to what Zcash is covers who builds Zcash, and our guide to Zcash roadmap nu7 and ironwood covers what its status labels do and do not track about the network itself.
Who assigns a number, and who they work for
A proposal enters the process as a pull request carrying an alias rather than a number. What happens next is stated plainly: "the ZIP Editors will assign the ZIP a number (if that has not already been done) and one or more Categories, and merge the pull request" (source: ZIP 0).
The same paragraph then constrains that power in a single sentence. "The ZIP Editors will not unreasonably reject a ZIP", followed immediately by an enumerated list of what does legitimately count as a reason for rejection. An unbounded editorial gate would be a very different institution from a bounded one, and the document is explicit about which of the two it intends to establish.
So the gatekeeping function is a named and bounded editorial role rather than a vote. Who holds it is published: three people listed "in their individual capacities", two associated with the Zcash Foundation, two with Shielded Labs, two with Project Tachyon, plus one with Valar Group. Nine editors distributed across five separate organizations.
Two structural details make that list considerably more interesting than a masthead. The document requires that "there are always at least two ZIP Editors, including at least one from the Zcash Foundation", which is a floor written into the process rather than a convention. And editors "MUST declare any potential or perceived conflict of interest", with those declarations printed in the process document itself rather than filed elsewhere.
That last part is worth sitting with. A governance document publishing its own gatekeepers' conflicts, by name, in the same file that defines their powers is doing something most protocol governance does not, and it constitutes a stronger signal than any general claim about decentralization.
The status ladder as the process defines it
Every proposal in the repository carries a status, and our guide to Zcash sketches the ladder those statuses form. What an outline of that kind cannot give a reader is the definitions themselves, which is precisely where the useful precision turns out to be sitting.
Draft is where everything starts: "all initial ZIP submissions have this status". Proposed is "typically the stage after Draft, added to a ZIP after consideration, feedback, then rough consensus from the community". Implemented means a working reference implementation exists although the change has not activated. Final means "a Consensus or Standards ZIP is both implemented and activated on the Zcash network".
Hold that definition of Final and reconsider something our guide to Zcash roadmap nu7 and ironwood established. An upgrade has been enforced by every node on the network since July 2026, and the document deploying it carries the status Draft.
By the terms of its own process document, that is a specification sitting two rungs below where it belongs. Our guide to Zcash roadmap nu7 and ironwood reports the observation and treats the labels as descriptions of paperwork rather than of the network, which is the right practical conclusion. What ZIP 0 adds is that the gap is not ambiguity in the ladder. The ladder is defined precisely and the label simply has not been moved.
There is a second rule most readers will not know about. "If no progress on a Draft or Proposed ZIP has been made for one year, the ZIP Editors SHOULD move it to Rejected status" (source: ZIP 0).
Be careful with that one. The condition is no progress, not elapsed time, and a status field records neither, so a three-year-old Draft may be under active work or may not be. The rule exists. It is discretionary, and nothing visible in the index tells you which drafts it applies to.
Where a coinholder vote decides something
Here is the question everybody asks about a chain that has no token voting attached to its consensus rules, and the honest answer turns out to be considerably more interesting than either a plain yes or a plain no would have been.
Search ZIP 0 for a coinholder vote and there is nothing whatsoever there. The words coinholder, poll and binding appear zero times in the process document. The mechanism it defines runs on editors assigning numbers and on "rough consensus from the community", which is a judgment call rather than a count.
Coinholder votes nonetheless exist, and they are binding over something specific. A live grants program announced in August 2026 states directly that "coinholders will decide which proposals to fund through a coinholder vote scheduled for September", with a mandatory review period first and a poll window running to the end of that month (source: Zcash Community Forum). Proposals are filed through a public template repository (source: GitHub), and a separate grants body runs its own application process alongside (source: Zcash Community Grants).
So coinholders determine who receives money, and have no defined role whatsoever in changing consensus rules. Those are two different powers exercised through two different processes, and the common summary that polling is merely advisory blurs a distinction worth keeping.
The foundation maintaining one of the node implementations has stated the protocol side of this as a governance principle, disclaiming any special authority for itself and locating the protocol's evolution in the open proposal process instead (source: Zcash Foundation). Our guide to Zcash roadmap nu7 and ironwood quotes that statement in full.
Limits of the ZIP process
A ZIP reaching Final does not by itself make anything happen anywhere. The process produces documents while nodes produce consensus, and the two are connected only by operators individually choosing to run software that implements a given specification (source: ZIP 0).
That is not a technicality. Our explainer on nodes, miners and wallets sets out the three roles, and the one that matters here is the node operator, who decides which rules their machine enforces. A specification everyone agreed to and nobody ran would change nothing at all.
The reverse is also possible and is the more common failure. Software can implement and activate a rule while the document describing it sits at Draft, which is exactly what the July 2026 upgrade demonstrates.
The process also cannot compel anybody to do anything. Editors may not unreasonably reject, and nothing obliges them to act quickly, obliges an implementation to adopt a Final ZIP, or obliges anyone to write one. Every step depends on people choosing to do it, which is what contentious forks look like when that choosing goes in different directions.
What ultimately enforces a rule is the same thing that enforces every other rule on a chain of this kind, which our explainer on proof of work sets out. A specification is an instruction to software, and software runs where somebody decides to run it.
Checking what the network actually enforces, rather than what any document asserts it should, is what a block explorer and a full node exist to let you do. Our guide to Zcash network upgrades covers how an upgrade actually activates.
What the process leaves open
It does not settle any live proposal whatsoever. Articles 29 and 42 cover the funding question in detail, this node covers only the machinery surrounding it, and nothing written here takes a position on what any pending document ought to become.
It does not tell you a status is trustworthy. ZIP 0 defines the ladder precisely and the labels are applied by people with limited time, which our guide to Zcash roadmap nu7 and ironwood covers at length and which the July 2026 example demonstrates.
It does not make Zcash a democracy or a corporation. Nine named editors with published conflicts, rough consensus rather than counting, plus a separate coinholder vote over grant money, is a specific arrangement fitting neither label. Reaching for either one loses the detail that matters.
Nor does it establish that the arrangement is a good one. Conflicts declared publicly are preferable to conflicts undeclared, an editorial gate is faster than a vote while being considerably less legible, and reasonable people disagree about that trade. what follows reports the mechanism and declines the evaluation.
It also says nothing about how any of this performs under pressure. A process that functions when participants agree is not thereby demonstrated to function when they do not, and the record for that is a matter of history rather than of specification (source: ZIP 0).
And it decides nothing whatever about the asset. How a protocol is governed constitutes a genuine input into how it may subsequently change, and it is not a view on holding anything, which our portfolio basics guide covers instead. Governance risk and market behavior are separate subjects, and market cycles covers why the second rarely tracks the first.
What the process is, structurally
The governance arrangement here is unusual enough that describing its structure explicitly prevents most of the misreadings that follow from assuming a more familiar one.
There is no corporate control and no token-weighted vote over consensus rules. Protocol changes are specified in numbered documents, discussed publicly, implemented by independent teams, then activated at block heights that every validating implementation enforces. Authority is therefore distributed across the specification process, the implementers, and ultimately the operators who choose which software to run.
That last point is the one most descriptions omit and it is the operative one. A specification acquires force only when implementations enforce it and operators deploy them. A document with an authoritative-looking status field that nothing enforces has changed nothing, which is why documentary status and network state have to be checked separately rather than treated as a single fact.
The numbering and status vocabulary is editorial bookkeeping about documents rather than a description of deployment. A document may be finalized while its change awaits activation, and a change may be live while its specification still carries an earlier label, and both situations have occurred here. Treating a status field as a statement about the chain is the single most productive source of incorrect claims about this project.
Coinholder signalling exists but is scoped narrowly. Where it has been used, it has informed decisions about funding arrangements rather than determined consensus rules, and conflating the two overstates considerably what holders decide.
The trade the arrangement makes
Two properties are bought and two are paid for, and the exchange is deliberate rather than accidental.
What it buys is auditability and durability of the record. Nearly every consensus change on this chain has a written specification that anyone can read, which is what makes claims about the protocol checkable rather than merely assertable. It also buys resistance to unilateral change, since no single organization can alter rules that independent implementations must all enforce.
What it costs is speed and legibility. A process requiring specification, independent implementation and coordinated activation resolves nothing quickly, which is a genuine cost when a defect or an unresolved allocation sits waiting. And the resulting record is voluminous, technical and cross-referential enough that reading it correctly is itself a skill, which is why so much secondary coverage of this subject misstates it.
Whether that exchange is worthwhile depends on what is being governed. For rules determining the disposition of other people's money on an adversarial network, slow and checkable is a defensible preference rather than an obvious failing.
How to look something up in the process yourself
The value of an open process is that you can check a claim rather than trust one, and doing so takes minutes.
Start from the specification index. Every numbered proposal appears there with a title and a status, and the index is the authoritative list of what exists.
Read the status field carefully, and read it as a statement about the document. A document can be finished while the change it describes has not activated, and a change can be live while its document still says otherwise. That gap has appeared more than once on this chain.
Read the proposal's own preamble before its body. It names the category, the authors and the intended deployment target, and those three tell you what kind of thing you are reading before you have to interpret any of it.
Then check the network separately. A proposal that describes an upgrade should correspond to a set of consensus rules the chain is actually enforcing, and whether it does is a question about the chain rather than about the document.
If those two disagree, the chain is right. That sounds obvious and it is routinely reversed, because the document is easier to read.
What the process is good at, and where it stops
Three strengths and three limits, stated plainly, because a process gets judged on both.
It is good at producing a written record. Almost every consensus change on this chain has a specification you can read, which is not true everywhere and which is the reason claims here can be checked at all.
It is good at making disagreement visible. Arguments happen in public, under names, with the reasoning attached, and that is worth more than a tidy outcome arrived at privately.
It is good at slowing things down, which is a strength when the thing being changed is the rules governing other people's money.
Its limits are the same properties viewed from the other side. It is slow, which means real problems can sit unresolved for years. Its documents lag the network often enough that a status field is unreliable as a description of what is live. And it settles specification questions rather than value questions: it can tell you exactly what a change would do and it cannot tell you whether the change should happen.
Three claims the process will not carry
Statements about Zcash governance fail in predictable ways, and three of them account for most of the errors.
That a proposal represents a commitment. It does not. A numbered document is a specification of what a change would do, and the index carrying those documents has an explicit disclaimer against being read as a plan.
That a status field describes the network. It describes the document. Establishing what the chain enforces requires checking the chain.
That holders decide protocol changes. They do not. Signalling has informed funding questions, while consensus rules are settled by specification, implementation and then activation at a height every node enforces.
A fourth belongs with those three because it causes the most practical trouble. That a numbered document, once finalized, obliges anyone to implement it. Nothing in the process compels an implementation to adopt anything, and the discretion sits with the teams that write the software and the operators who choose to run it. Finality is a statement about the document's editorial state rather than about anyone's obligations.
The reason all four errors take the same shape is worth noticing. Each one reads a piece of writing as though it were an instrument of authority. In a system where authority rests on what independently written software actually enforces, the writing is evidence about intent and nothing more.
Frequently asked questions
Who controls Zcash?
No single party. The process document, ZIP 0, names nine ZIP Editors across five organizations who assign numbers and merge proposals, and it constrains them by stating they "will not unreasonably reject a ZIP". Beyond that, changes take effect only when node operators run software implementing them, so the editors gate documents rather than the network. The foundation maintaining one implementation states that the protocol evolves through the open ZIP process rather than through any one organization, itself included.
Do Zcash holders get to vote?
On grants, yes. A live coinholder-directed grants program states that coinholders will decide which proposals to fund through a vote, with a published review period and a published poll window. On consensus rules, no: ZIP 0 contains no coinholder vote anywhere in it, and moves proposals forward on editorial judgment and rough consensus instead. Those are two entirely distinct powers, exercised through two entirely distinct processes, and conflating them is the most common error in accounts of this subject.
What do the Zcash ZIP statuses mean?
ZIP 0 defines them. Draft is where every submission starts. Proposed follows consideration, feedback and rough consensus. Implemented means a working reference implementation exists but has not activated. Final means the change is both implemented and activated on the network. Reserved, Withdrawn, Rejected and Obsolete cover the remaining cases. One further rule says a Draft or Proposed ZIP with no progress for a year should be moved to Rejected.
Why is a shipped Zcash upgrade still marked Draft?
Because nobody has moved the label, not because the ladder is ambiguous about it. ZIP 0 defines Final as a Consensus or Standards ZIP that has been both implemented and activated, and the document deploying an upgrade enforced across the network since July 2026 still reads Draft. Our guide to Zcash roadmap nu7 and ironwood covers the wider pattern, which is that these labels track editorial bookkeeping rather than network state, and what follows adds only the definition that turns an oddity into a discrepancy.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are ZIP 0 and the Zcash Improvement Proposals index, a dated grants program announcement, the program's public proposal repository, the grants body's own site, and a Zcash Foundation post. All facts independently verified against cited documentation current as of August 2026. what follows describes the governance mechanism and takes no position on any pending proposal.