Anyone searching for the Zcash roadmap in 2026 will be shown a company blog post from November 2021 and a foundation engineering plan from 2020. Meanwhile the upgrade that actually reshaped the chain took effect at the end of July 2026 and returns no ranking pages under its own name.
The authoritative answer is public and has been all along. The specification repository publishes an index that carries a status against every formal proposal, and reading it correctly is the whole skill.
what follows reads that index. Our guide to Zcash network upgrades covers how upgrades are deployed, and our guide to Zcash crosslink proof of stake covers the consensus-change proposal that is not on the candidate list.
What the repository actually contains, counted rather than described
The index lists 128 numbered proposals. Their statuses are not distributed the way a reader expects. Draft is the largest category at 35, ahead of Final at 32. Reserved accounts for 24 and Obsolete for 14, while Active reaches 7 against 6 Withdrawn, leaving Proposed to manage only 5 (source: Zcash Improvement Proposals).
Five more carry a different status on different revisions of the same document, so a single proposal can be simultaneously Active, Withdrawn and Draft depending on which revision is being discussed. A further six drafts exist with no number assigned yet.
Those counts were miscounted on a first pass, which is worth admitting because it is the same trap the index sets for every reader. The page prints its proposals five times over, once in each of four grouped sections and once again in a complete master index, so a count that sweeps the whole page roughly doubles everything. The figures above come from the master index alone and are cross-checked against the grouped sections, which sum to the same total.
The distribution matters more than any individual entry. A repository whose largest status is Draft is not a schedule of forthcoming features. It is an archive of what has been written down, most of which has not been agreed.
That distinction is the difference between a roadmap and a filing cabinet, and every page that presents Zcash proposals as a pipeline has quietly converted the second into the first. Reading it the way you would read a block explorer, as a record of what happened rather than a plan for what will, is closer to correct.
What is formally proposed, by number and by status
Only five proposals in the entire repository carry the status Proposed, which is the smallest category apart from those already withdrawn and the closest thing to a live queue that the repository contains (source: Zcash Improvement Proposals). Everything else has either been settled or abandoned.
They are ZIP 155 on peer address messages, ZIP 271 on extending the development fund with a one-time disbursement, ZIP 300 on cross-chain atomic transactions, ZIP 1016 on a community and coinholder funding model, plus ZIP 2005 on quantum recoverability for the current shielded pool. Our explainer on how nodes, miners and wallets divide the work covers why the first of those affects operators long before it affects anyone holding the asset.
Two of those five concern funding rather than the protocol, and our guide to Zcash dev fund owns that subject in full, including who receives what under the arrangement now in force. ZIP 2005 belongs to the node on quantum recoverability, which is a topic that rewards precision about what the word recoverability actually promises and does not get it here.
The remaining two are infrastructure rather than headline features. Peer address handling and cross-chain atomic swaps are the kind of work that changes what the network can do without changing what a holder sees, and neither carries an activation date anywhere in the repository.
Note what is absent from this list. The consensus mechanism change that dominates most discussion of Zcash's future is not among the five, and it is not on the candidate list for the next upgrade either. Our guide to Zcash crosslink proof of stake covers what its actual status is, and it is not Proposed.
The candidate list, and the two places it disagrees with its own page
The index publishes a section headed "NU7 Candidate ZIPs" listing nine proposals that it describes as "under consideration for deployment in NU7". Between them they cover block spacing, memo bundles, three separate network sustainability mechanisms, explicit fees and the disallowing of an older transaction version.
The same section carries its own warning, and it is more useful than the list: "This list is only provided here for easy reference; no decision has been made on whether to include each of these ZIPs". Seven of the nine are Draft.
The eighth is where the page contradicts itself. ZIP 230, listed as a candidate for the next upgrade. It is marked Withdrawn in the same page's status table, and its title in that table is literally "Withdrawn Version 6 Transaction Format" (source: ZIP 230). A reader working from the candidate list and a reader working from the status table reach opposite conclusions about the same document.
The second contradiction sits one level up, around the upgrade itself. ZIP 254, which was the deployment specification for NU7, is Withdrawn. Its replacement is a draft with no assigned number, which the index says "will define which ZIPs are included in NU7". The repository issue tracking that work is still Open (source: zcash/zips).
So the next upgrade currently consists of a candidate list containing a withdrawn document, governed by a deployment specification that has been withdrawn, replaced by a draft without a number. None of that means the work is stalled, and none of it means anything is scheduled either. The honest reading is that the shape of the next upgrade has not been decided.
The upgrade that shipped, and is still marked Draft
Here is the case that should change how anyone reads this index. The Ironwood upgrade, formally NU6.3, took effect at mainnet block 3,428,143, reached on July 28, 2026. A community status thread published three weeks afterwards put the share of the previous shielded pool that had already migrated across it at roughly 80% (source: Zcash Community Forum).
It is enforced by every node on the network, and software that predates it stopped following the chain at that height rather than degrading gracefully. By any operational measure it is the most consequential thing to have happened to Zcash this year.
Its deployment specification, ZIP 258, is marked Draft.
That is not an isolated lapse in bookkeeping, which is what makes it instructive. Each deployment specification before it carries Final instead, running from Heartwood and Canopy through NU5, NU6 and the fixes deployed between the two most recent point upgrades to NU6.2 itself. The pattern breaks exactly once, on the most recent and most significant upgrade of the set.
The lesson extends well past Zcash. A status field in a specification repository records the state of a document maintained by people with limited time and a large backlog, so it tracks the network only as closely as somebody has got around to making it track the network. Chains are hardly the only systems in which the map lags the territory, and anyone who has watched an upgrade fork a network will recognize the pattern of documentation catching up afterwards. The same lag applies to the mining side, where difficulty adjustment responds to a change in the network long before anything describing it is finalized.
The governance principle behind all of it is stated plainly by the foundation that maintains one of the node implementations: the protocol "belongs to its community, and it evolves through the open ZIP process" (source: Zcash Foundation). An open process produces a public paper trail, and a public paper trail is maintained at human speed.
What a status field leaves out
Deployment is not what these labels track. A Draft can be a rule the network has enforced for weeks. ZIP 258 currently demonstrates that, and a Final label tells you a document was completed rather than that anything is running. Checking the chain settles the question and checking the index does not.
Nothing on the candidate list is scheduled. "Under consideration" is the index's own phrase, the disclaimer beneath it says that no decision has been made, and the deployment specification that would fix the contents has been withdrawn without a numbered replacement appearing in its place.
Whether a proposal is any good is a separate question entirely. Status records where a document sits in a process rather than whether the idea inside it survived review, so a Draft may be a strong proposal awaiting attention while an Obsolete one may be a design that worked and was later superseded.
Nothing in the index describes the mechanism that actually decides which rules the network runs, which is proof of work plus the software operators choose to run. A specification becomes consensus at the moment nodes begin enforcing it, rather than at the moment somebody updates a label describing it.
Ranking pages are not going to help. The best-placed roadmap result for this query is dated November 19, 2021 (source: Electric Coin Company), which predates several completed upgrades and the entire candidate list above.
One last thing this page cannot give you is a reason to trade on any of it. Protocol timelines slip and candidate lists change, and the relationship between a specification's status and an asset's price behavior is not something anybody should attempt to model. Our guide to crypto market cycles covers why roadmap news is a poor input, and portfolio basics covers what to do instead.
How to establish what is actually live
Four sources, in the order that resolves a question fastest, because reading them in the wrong order wastes the most time.
Start with the upgrade pages the project publishes for activated changes. Each names an upgrade, gives an activation height, then links the specifications it carries. A change appearing there with a height in the past is live by definition.
Then check the height itself against the chain. An activation height that has passed means every validating node is enforcing those rules now, and that is a fact about the network rather than about any document.
Then read the specifications that upgrade carries. These tell you what the rules actually say. They are written in normative language, and they are the authority for any claim about behavior.
Then, and only then, look at status fields. They are the least reliable of the four for this purpose. They describe editorial position rather than deployment, and the divergence between the two has appeared repeatedly on this chain.
Two habits make the whole procedure faster. Record the date you checked, because everything here moves and an undated note becomes indistinguishable from a guess within months. And when two sources disagree, prefer whichever sits closest to the chain: the chain outranks a specification, and a specification outranks any summary, this one included.
A final observation concerns why so much material about this subject misstates it. Roadmap queries attract organisational writing rather than technical writing, and organisational writing is produced at moments of announcement rather than of deployment. The result is a corpus weighted toward intentions expressed years ago, most of which carries no date visible to a reader and none of which is retracted when superseded. Establishing what is currently enforced therefore requires going to the primary sources, and the procedure above is the shortest route to doing so reliably.
The same asymmetry explains why the index is more useful than it looks. It is unglamorous. It makes no claims, and it is maintained as bookkeeping rather than as communication, which is exactly what makes it the least misleading document in the set. A document attempting no summarization cannot summarize incorrectly, and the reader consequently supplies the interpretation with complete visibility of its evidentiary basis.
The practical upshot for anyone tracking this subject is a short routine rather than a subscription. Consult the index whenever an answer is required, record the date of consultation, and re-consult subsequently rather than relying on that record. Nothing about this area rewards maintaining a mental model of current state, since such a model degrades invisibly while the authoritative source remains available at negligible cost.
Why documentary status and network state diverge
The gap between what the documents say and what the chain enforces is the defining difficulty of this subject, and it has structural causes rather than careless ones.
Specification and deployment are separate workstreams carried out by different people. A document reaches a settled state when its editors agree it is complete; a rule reaches the network when implementations ship and an activation height passes. Nothing in either process obliges the other to keep pace, and in practice the deployment side moves faster under pressure while the editorial side moves faster in quiet periods.
Emergency changes make the gap wider by design. When a defect requires a rapid response, the implementation ships first and the documentation follows, which is the correct ordering under those conditions and produces exactly the discrepancy an outside reader then trips over.
Editorial capacity is finite and unevenly distributed. Updating a status field is unglamorous work that competes with writing new specifications, and it loses that competition routinely on every project of this kind.
The practical consequence is a rule worth applying generally rather than only here. Treat a status field as evidence about a document, treat the chain as evidence about the network, and when the two disagree resolve it in favor of the chain. Anyone quoting a status as though it described deployment has skipped a step that cannot be skipped.
What a reader can establish, and where the index stops
Three things the record supports, and three it does not, stated separately because they get merged constantly.
It supports what has already activated. Upgrades that have passed their activation heights are enforced by every node, and the rules are checkable directly against the chain rather than against anyone's description of it.
It supports what has been formally specified. A numbered document exists or it does not, and its contents are fixed and readable.
And it supports what is under consideration. Candidate lists and discussion threads establish that a subject is being worked on, which is a genuine fact about intent.
What it does not support is any date for anything unshipped. No timetable is published, activation heights are set close to deployment rather than far ahead, and estimates circulating elsewhere are inferences rather than commitments.
Nor does it support reading inclusion on a candidate list as a decision. The list carries an explicit disclaimer against exactly that reading.
And it does not support ordering by importance. A proposal's number reflects when it was submitted rather than anything about its priority, which is a surprisingly common misreading.
Frequently asked questions
What is in the Zcash NU7 upgrade?
Nothing is settled. The specification index lists nine proposals under consideration, covering block spacing, memo bundles, three network sustainability mechanisms, explicit fees and disallowing an older transaction version, and it states directly that no decision has been made about including any of them. Seven of the nine are Draft, one is Withdrawn despite appearing on the list, and the deployment specification that would have defined the final contents has itself been withdrawn without a numbered replacement.
Has Ironwood already happened?
Yes. Ironwood, formally NU6.3, took effect at mainnet block 3,428,143, which the network reached on July 28, 2026, and a status thread published three weeks afterwards put the migrated share of the previous shielded pool at roughly 80%. Node software that predates the upgrade stopped following the chain at that height, so it is enforced rather than optional. Its deployment specification is nonetheless still marked Draft in the index.
Does a Draft ZIP mean the feature is coming?
No, and the inference fails in both directions. Draft is the largest single status in the repository, larger than Final, and most drafts have not been agreed to by anyone. In the opposite direction, the deployment specification for the upgrade that activated in July 2026 is also marked Draft, so a Draft label is compatible with a rule the entire network already enforces. Read the chain for what is live and the index for what has been written down.
Where is the real Zcash roadmap?
There is no single document. The nearest thing is the specification repository's index, which lists every numbered proposal with a status and publishes the current candidate list for the next upgrade. It is a reference table rather than a plan, and it carries an explicit disclaimer against being read as a commitment. Most material published under the word roadmap is older still: organisational posts from 2020 and 2021 that predate several completed upgrades and say nothing about their own age.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are the Zcash Improvement Proposals index and individual specifications, the project repository's issue tracker, a community status thread updated August 20, 2026, and dated posts by the Zcash Foundation and the Electric Coin Company. All facts independently verified against cited documentation current as of August 2026. Every status quoted here is the status printed in the index on that date and statuses change without notice.