Zcash is moving closer to implementing its major network upgrade, known as NU7, which introduces a contentious protocol change that would effectively close the spending route out of its oldest and original privacy pool, Sprout. According to network data, the legacy pool still held approximately 22,309 ZEC as of mid-October. While holders of these stranded funds will technically retain their private keys, the upgrade’s new consensus rules will strip them of the network-level ability to move or spend those assets, raising critical questions about fund accessibility, migration friction, and long-term asset retention within the privacy-focused cryptocurrency ecosystem.
The exact mainnet activation schedule for NU7 remains officially undecided, though a final decision is planned following ongoing testnet evaluation. The NU7 deployment specification, outlined in ZIP 259, leaves the activation block height unassigned while targeting November 5 as a conditional launch date, subject to performance and stability observed on the testnet.
Dashboard metrics from zkp.baby recorded precisely 22,309.44195128 ZEC remaining within the Sprout pool at block 3,521,260 during an update in mid-October. The mechanism behind this impending freeze is detailed in ZIP 2003, a Zcash improvement proposal authored by Daira-Emma Hopwood. The proposal outlines a hard cutoff that rejects all version 4 transactions starting from the NU7 activation block onward. Because Sprout transfers rely exclusively on this older transaction format, and neither the newer version 5 nor version 6 formats support them, the upgrade effectively removes the cryptographic bridge required to process Sprout spends.
While a private key ultimately authorizes a spend from a cryptographic perspective, the decentralized network must also accept the transaction carrying it. Under the proposed rules of ZIP 2003, holders of funds in the Sprout pool would find themselves with no supported transaction format through which they can exercise that signing authority.
The restriction impacts every iteration of version 4 transactions, including transparent-only transfers and historical Sapling transactions. However, the operational consequences vary drastically depending on the specific pool involved. Users holding assets in non-Sprout pools can simply recreate and rebroadcast their transactions in a modern, supported format. Sprout, by contrast, possesses no equivalent replacement format. Merely re-signing a legacy version 4 transaction cannot fix its inherently invalid structure under the new rules, and even newer formats require cryptographic signatures that align strictly with the updated consensus branch.
ZIP 2003 explicitly leaves Sprout’s remaining balance within the broader issued supply of Zcash. While this design choice preserves the theoretical possibility of re-enabling version 4 transactions or establishing a separate retrieval facility at some point in the distant future, the proposal’s authors openly warn that spending capabilities may never be restored, leaving the funds permanently locked unless migrated prior to the upgrade.
Recovery Takes Work, and Exiting Exposes Amounts
For holders seeking to rescue their stranded assets ahead of the deadline, migrating to current wallet software does not automatically translate to moving the coins safely. Official migration documentation for Zallet, a Zcash wallet implementation, explicitly excludes Sprout spending keys and legacy funds from its standard import process, advising users instead to preserve their original wallet.dat files carefully.
To bridge this gap, independent tools such as the Argos recovery tool have documented specific pathways for holders possessing a legacy wallet file or standalone Sprout spending keys. A wallet containing usable note data alongside a cached witness can successfully bypass a lengthy historical blockchain scan. However, for users equipped only with a raw private key, the recovery process requires reconstructing the complex auxiliary data necessary to construct a valid spend transaction.
Performing a full-block scan for Sprout recovery is resource-intensive. Argos estimates that the process requires roughly 280 GB of data transfer and potentially days of continuous processing time, while ultimately retaining less than 500 MB of local disk space upon completion. Furthermore, the recovery tool directs sweeping operations specifically into Sapling, a newer shielded pool, even when users supply a modern Unified Address. Moving those recovered funds onward from Sapling into newer architectures remains an entirely separate operational step.
Exiting the legacy pool also involves unavoidable privacy trade-offs, alongside transaction fees and heavy recovery workloads. As explained in ZIP 308, which governs the migration design, value moving from Sprout to Sapling must temporarily pass through public pool accounting. This transitional phase exposes the transaction amount publicly, bypassing the strict shielded guarantees of the original pool without necessarily requiring a transparent address.
To mitigate this exposure, the Sprout-to-Sapling scheme specified in ZIP 308 coordinates transaction timing and randomizes amounts to reduce the probability that individual transfers can be linked back to specific holders. Nevertheless, ZIP 2003 warns that a short, rushed, or poorly coordinated exit window can easily make distinctive amounts and transaction timings far easier for external observers to associate with individual holders. Consequently, while the security and maintenance benefits of retiring Sprout are shared collectively by the entire network, the administrative and privacy burdens of the migration fall entirely upon individual holders.
The proposal spearheaded by Hopwood provides a concrete engineering justification for removing Sprout’s spending path entirely. Despite handling very little active volume, Sprout’s specialized verification logic and its handling of private notes and spent-note identifiers continue to introduce unnecessary computational overhead into live transaction acceptance. These verification costs directly impact denial-of-service exposure during pending-transaction validation and block processing.
While some cryptographic components are shared between Sprout and newer architectures like Sapling, and pool accounting checks guard against potential balance violations, the proposal argues that maintaining Sprout-related complexity is no longer justifiable. Retiring the pool entirely would reduce that structural maintenance burden for all implementations responsible for validating the network.
This architectural shift follows a long-term trajectory for the network. An earlier proposal, ZIP 211, successfully halted any new value from entering the Sprout pool while preserving the ability for users to extract existing funds. ZIP 2003, which was initially drafted in late 2024, represents the final logical step of closing those remaining spending routes under the NU7 framework.
A Mainnet Decision Still Lies Ahead
Preparations for the upgrade are already well underway within test environments. The Zcash Foundation announced the release of Zebra 7.0.0-rc.0 in early October, successfully scheduling the NU7 activation on the testnet at block height 4,465,026. Subsequent engineering updates confirmed that the testnet had smoothly passed activation, validating the foundational software code.
A September coordination announcement published on the Zcash community forum indicated broad consensus among ecosystem organizations and core engineering teams following extensive polling and community discussions. While earlier community polling regarding token economics and issuance was designated as advisory, the technical roadmap for NU7 has steadily progressed toward formal adoption.
Under Zcash’s established upgrade mechanism, network activation relies strictly on reaching a designated block height. For NU7, ZIP 259 explicitly waives the traditional recommendation of allowing a three-month buffer between the first supporting software release and mainnet activation, while also relaxing requirements tied to the deprecation of unsupported software. The specification warns network operators that legacy, unsupported software may remain online and attempt to follow pre-NU7 rules, reinforcing the critical need for all node operators to run compatible software to properly validate the upgraded network.
With community recovery discussions and technical documentation circulating widely, the upcoming decision planned for mid-October serves as the next major milestone for the network. Formal approval of the upgrade and the assignment of a definitive mainnet activation height will establish an operational deadline, requiring all remaining Sprout holders to execute their valid migrations before the network permanently seals the oldest privacy pool.
