Zcash Sprout Pool: Why You Must Move Old ZEC Before November 5

If you have ZEC sitting in a wallet file from 2016 or 2017 and your Zcash addresses begin with the letters zc, then your balance is in what is known as the Sprout pool, and you should move it. The reason is set out in a change proposal numbered ZIP 2003, due to ship with the NU7 network upgrade: it disallows transactions of the old v4 format, and that is the only format with which Sprout funds can be spent at all. The planned activation date for NU7 on mainnet is November 5, 2026.

One point of context before the panic sets in: this is not about all ZEC, only about the balance in this single, oldest shielded pool. Anyone who keeps their Zcash on an exchange, uses a modern wallet, or created their addresses only in recent years is very unlikely to be affected. Those affected are the small group who have not looked in years. Which is precisely why they would otherwise hear about it too late.

What the Sprout pool in Zcash is and why it concerns you now

A value pool in Zcash is a separate accounting circle with its own cryptographic machinery, holding shielded funds. Zcash has renewed that machinery several times over the years, and each renewal created a new pool rather than rebuilding the old one. Sprout is the first of them, launched with the network in 2016. It was the first large-scale application of general zero-knowledge proofs anywhere, but suffered from long computation times and high memory requirements. Its successors Sapling and Orchard fixed exactly that and brought additional features such as viewing keys and diversified addresses.

The consequence of that design: your balance does not migrate automatically when the protocol moves up a step. It stays in the pool it once arrived in until you move it yourself. Anyone who sent ZEC to a shielded address in 2016 or 2017 and never touched the wallet again still has that balance in Sprout. The ZIP 2003 specification puts it drily: Sprout is at this point "essentially unused". That low usage is exactly the developers' argument for retiring the pool now.

For the Zcash project this is housekeeping. The parts of Sprout that do not overlap with Sapling, such as the JoinSplit circuit and the handling of Sprout nullifiers, weigh on the complexity and the attack surface of every full-node implementation. Because Sprout is barely used, node developers have little incentive to optimise its verification, which makes denial-of-service attacks at that point comparatively cheap. For you as a holder it is nonetheless simply a deadline.

ZIP 2003 in its own words: why the end of v4 transactions closes the Sprout pool

The technical link is explained in one sentence, and it is worth understanding, because it is why no later wallet version can simply solve the problem. The NU5 upgrade introduced the v5 transaction format. That format plainly does not support Sprout. The specification puts it this way: "The v5 transaction format introduced in the NU5 network upgrade does not support Sprout, and so this will have the effect of disabling the ability to spend Sprout funds." As long as the network still accepts v4 transactions alongside it, there is a way out. ZIP 2003 closes exactly that way out.

Formally, the proposal changes a single consensus rule. Since NU5 the rule has been that the transaction version must be 4 or 5. In future that rule is to apply only "[NU5 and NU6, pre-NU7]", and from NU7 version 4 is no longer to be permitted. The change works identically on mainnet and testnet. The author is Daira-Emma Hopwood; the category is Consensus.

There is one caveat you should know, and it is left out of many short reports: ZIP 2003 still carries the status Draft, and the reference implementation is marked "TBD" in the specification. This is not settled yet. According to Cointelegraph, the Zcash project intends to decide on October 20, 2026 whether the targeted mainnet activation on November 5 will actually take place. You should act now regardless, and the reason is further down, in the section on zcashd.

Are my ZEC burned? What really happens to funds in the Sprout pool

This is where the most common misunderstanding sits, and the answer is more cheerful than the headlines suggest. Nothing is burned. The specification says explicitly that it is not intended to unissue, burn or permanently strand Sprout funds: "It is not proposed in this ZIP to unissue, burn, or otherwise make Sprout funds permanently unavailable." The amounts remain issued and in circulation for accounting purposes. For the planned Network Sustainability Mechanism, too, the Sprout value pool is explicitly not counted towards the "Money Reserve".

What is lost is the ability to move the balance. The door could in theory be reopened by permitting v4 transactions again or by creating a dedicated recovery mechanism. But the specification itself does not rely on that; it states the call to action unambiguously: "since it is possible the ability to spend Sprout funds will never be re-enabled, holders of these funds should move them out of the Sprout pool without delay."

In practice, then, you should treat this as a final deadline. A later recovery effort would be a political decision by the Zcash community that nobody has promised you, and it would depend on developer capacity that is currently being invested in the opposite direction.

zc, zs and t1: how to spot a Sprout address in your wallet

The check takes a minute once you can reach your old addresses, because the prefixes are unambiguous. The official Zcash documentation describes the types as follows:

• Begins with zc — a shielded Sprout address, the legacy type. This is the case at issue here. Such addresses are conspicuously long; the example in the documentation runs to well over eighty characters.
• Begins with zs — a shielded Sapling address, introduced with the Sapling upgrade. Not affected by ZIP 2003.
• Begins with t1 or t3 — a transparent address, technically comparable to a Bitcoin address and without privacy properties. Likewise not affected.
• Begins with u1 — a unified address, the newer combined type used by modern wallets. Likewise not affected.

A second point from the same documentation matters at least as much in practice and is mentioned almost nowhere: HD support is not enabled for Sprout addresses or for transparent addresses. With Sapling the entire set of addresses can be restored from a master seed; with Sprout it cannot. So anyone who only has a recovery phrase on paper but has lost or overwritten the old wallet file can no longer reach a Sprout balance. The file itself is the backup. If you still have it, copy it before you do anything else, and put the copy on a second medium.

It is also useful to know that Sprout supports incoming viewing keys only. You may therefore be able to see incoming payments without that implying any ability to spend. A visible balance is no proof that you hold the key to spend it.

Why the retirement of zcashd is the harder deadline than November 5

This is the point that determines your window, and it appears in ZIP 2003 as a subordinate clause rather than a headline. The zcashd software is the only maintained application that still provides wallet functionality for Sprout at all, and its discontinuation is explicitly planned for before NU7. In the wording: "The deprecation of zcashd, planned to be in advance of NU7, will also remove the only maintained software that still provides wallet functionality for Sprout, which would in any case make it impractical to move funds out of the Sprout pool."

An uncomfortable sequence follows. November 5 is the outer limit at which the network closes the door. The practical limit lies before it, namely on the day the last piece of software disappears with which you can operate that door at all. The specification names no fixed date for it, and that is precisely what makes this awkward: you cannot rely on a calendar entry, only on being early.

The Zcash project has been working for some time on replacing zcashd with the Zebra node implementation and the new Zallet wallet software. For everyday use that is the better foundation. For Sprout holders it means the successors are not meant to carry the old function over at all. If you have a working zcashd installation or a backup of one, that is your most valuable tool right now.

The zcashd migration tool: how z_setmigration works

A migration tool has been built into zcashd since version 2.0.5-2, and the documentation explicitly recommends using it instead of migrating by hand. The reason is privacy, not convenience, and it leads to a quirk that matters in a moment.

The background: zcashd's ordinary payment commands, z_sendmany and z_mergetoaddress, forbid sending directly from a Sprout address to a Sapling address. Anyone who wants to take that route by hand has to use a transparent address as a staging post, and in doing so the amount becomes publicly visible and stays linked to that transparent address. At the consensus level a direct transition is possible, but even then the amount passes through the transparent value pool and becomes visible. Because that is not obvious to users, the function was deliberately kept out of the standard commands and moved into a tool of its own, whose design is set out in ZIP 308.

The tool is controlled by two commands. zcash-cli z_setmigration true switches it on, zcash-cli z_setmigration false switches it off again. You read the progress with z_getmigrationstatus. By default the destination is the first Sapling address derived from your wallet's master seed; if you want a different one, you enter it as -migrationdestaddress in the zcash.conf file before starting. The tool consolidates all Sprout addresses in the wallet onto a single Sapling destination address.

Why the migration takes weeks and is not done in one evening

This is where most people underestimate the deadline. The tool does not send your balance in one transaction; it deliberately spreads it out. According to the documentation it creates at most five transactions each time the blockchain reaches an interval of 500 blocks, with the amounts randomly distributed. That way your move disappears into the crowd of everyone else's moves happening at the same time. The process only ends once the wallet's Sprout balance falls below 0.01 ZEC.

Work that through once and the timing problem becomes clear. At the current target of 75 seconds per block, 500 blocks come to about ten and a half hours — that is a simple multiplication of block time by interval size, not a figure from the project. Per interval, at most five part-transfers are possible. How many intervals you need depends on how many individual notes make up your balance. With a holding grown over years, that can easily turn into several days or weeks.

On top of that comes a condition that often fails in practice: the node has to keep running until all funds have been transferred. A laptop you close in between extends the whole thing accordingly. So anyone who starts only in late October can do everything right and still be too late. The clock that counts is not the one running to November 5, but the one running to the end of your own migration. And if you intend to dispose of the holdings anyway, settle early which crypto trading venue that should run through, rather than picking the first available one under time pressure at the end.

Which dates in the NU7 timetable matter for you

So that you can place the reports of the coming weeks, here are the dates on the table as things stand. Two of them are decision dates; one is the event itself:

1. October 20, 2026 — the decision. According to Cointelegraph, the project intends to settle on that day whether mainnet activation takes place as targeted. Until then ZIP 2003 remains a draft.
2. November 5, 2026 — the targeted activation of NU7 on mainnet. From that point v4 transactions are to be invalid, and with them the ability to spend in the Sprout pool ends.
3. No fixed date: the discontinuation of zcashd, planned per the specification for before NU7. For Sprout holders this is the date that really counts, and it is the only one of the three you cannot look up in a calendar.

Besides the Sprout question, NU7 brings further changes that affect all ZEC holders, among them a markedly shorter target block time of 25 seconds instead of 75. What else this upgrade changes, and who actually has to do something about it, we set out in our overview of the NU7 upgrade on November 5. One qualification on our own account: that piece says holders of ZEC need not move anything. For Sapling, Orchard and transparent holdings that is correct. For Sprout funds, ZIP 2003 says the opposite, and this text is the addition to it.

Holding period and tax: what the move out of the Sprout pool triggers in Germany

A transfer between addresses that belong to you is, on the reading customary in Germany, not a disposal. Simply shifting funds out of the Sprout pool into your own Sapling address therefore does not in itself trigger a taxable event, and the original acquisition date remains the relevant one. The one-year holding period under Section 23(1) sentence 1 no. 2 of the Income Tax Act thus continues to run and does not start afresh. With ZEC untouched since 2016 or 2017 it has long since expired in any case.

The authority for the treatment of crypto-assets in Germany is the Federal Ministry of Finance circular on individual questions of the income tax treatment of crypto-assets of March 6, 2025, which updates the earlier 2022 version. Two things are still worth observing. First, document the move cleanly, meaning date, amount, source and destination address, because otherwise you will struggle to show the tax office that this was a transfer and not a sale. With Sprout that is particularly delicate, because shielded transactions by their nature leave little public evidence; your own wallet records are then your proof. Second, a migration in which the amount passes through the transparent value pool remains a transfer for tax purposes, even though it becomes visible on chain.

If, on the other hand, you sell in the course of the exercise, or swap ZEC for another cryptocurrency, that very much is a disposal with all the consequences. Anyone holding several tranches of differing age should work that through beforehand. Tools that handle exactly this allocation exist as a category of their own; the comparison is linked below. This section is a general orientation and does not replace tax advice in an individual case.

Where to put the ZEC after migration: Sapling wallet, hardware wallet or exchange

The migration tool first brings your balance onto a Sapling address in your own wallet. That settles the deadline and gives you time for the second decision. In principle three routes are open to you, and which one fits depends on what you intend to do with the holdings.

If you want to stay shielded, a current Zcash wallet with Sapling or Orchard support is the obvious place. The same lesson applies here that you have just learned, though: Sapling and Orchard are not built for eternity either, and the project has already shown that it retires old pools. How a migration between newer pools works, and how to tell whether your balance still has to move, we have already described using the Orchard pool and its turnstile as the example.

If your concern is above all secure long-term custody, there is much to be said for a hardware device, provided it supports ZEC in the address form you want. Check that before buying rather than after, because support for shielded addresses is considerably rarer among hardware wallets than support for transparent addresses. And if you intend to sell or actively trade the holdings anyway, an exchange is the easier place, with the familiar drawback that the keys are then no longer with you.

Beware of wallet recovery offers: how to spot dubious help

Whenever a deadline goes through the trade press, offers appear that use exactly that deadline as leverage. The pattern is predictable, and you should know it before someone writes to you in a forum or by direct message. Work from these principles:

• Nobody helping you legitimately needs your wallet file, your private keys or your recovery phrase. Anyone asking for them gains full access to your funds with that data, immediately and irreversibly.
• Supposedly official help desks that contact you unprompted are a warning sign. The specification and the documentation are publicly available, and the tools are part of the software.
• Time pressure as a sales argument is a warning sign in itself. The real deadline is real, but it does not change the fact that every step can be checked calmly.
• Paid recovery that demands payment up front is a classic pattern in the crypto space. Reputable providers bill on success and do not work with your keys in the clear.
• Download wallet software exclusively from the project's official source and, where possible, check the file's signature.

If you have found an old wallet file, the safest order is: first make a copy, then work on a machine that holds nothing else of importance, and take the file offline again afterwards.

If your ZEC sit on an exchange: why this mostly does not concern you

For most readers the matter ends here with an all-clear. If you hold ZEC on a trading platform, that platform manages the addresses, and the vast majority of venues moved their holdings out of Sprout long ago, because they have to keep adapting their systems to new protocol versions. In that case you do not have a Sprout address yourself, but a claim against the platform.

What you can still do is a simple check. Look through your records for withdrawal addresses from the years 2016 to 2018 and check whether one of them begins with zc. If you withdrew to your own shielded address back then, there may be a remainder sitting there that you have not thought about in years. Precisely such forgotten remainders are the typical case this whole deadline is about.

Also worth noting: anything you hold in ZEC through an exchange-traded product is untouched by the Sprout question. There you hold not a network balance but a security, and the protocol's pool mechanics do not reach you. How these products work in Germany we have described using the first European Zcash ETP as the example.

Moving Zcash Sprout funds: what to take away

The situation boils down to three steps, and the first costs you five minutes.

1. Check whether you are affected at all. Look through old wallet files, backups and withdrawal records for addresses beginning with zc. If you find none, you are done. If you find one, copy the wallet file onto a second medium immediately, because with Sprout there is no recovery from a seed phrase. Which current application shows you the address form in plain text is set out in the software wallet comparison.
2. Start the migration early, not just before the date. With a working zcashd installation you switch the tool on with z_setmigration true and track progress with z_getmigrationstatus. Reckon with several days, keep the node online throughout, and budget the time until zcashd is discontinued, not the time until November 5. Where the ZEC then go for long-term custody is settled by the hardware wallet comparison.
3. Document the move and plan the tax side with it. Record the date, the amount and the source and destination addresses so the transfer stays provable. If you sell or swap in the same move, check the holding periods of your individual tranches first; suitable tools are listed in the comparison of crypto tax software and portfolio trackers.

You can read the wording of the planned rule yourself at any time: the specification is public as ZIP 2003 "Disallow version 4 transactions", and the operation of the migration tool is described in the official documentation on the Sprout-to-Sapling migration. Both pages are the solid ground, while reports about the upgrade may still change over the coming weeks.

(As of September 23, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)