Zcash is moving closer to a major protocol evolution that could permanently alter access to its earliest days, with the proposed NU7 upgrade threatening to close the spending path out of its oldest privacy pool, Sprout. According to blockchain data, the legacy pool still held approximately 22,309 ZEC as of mid-October. While holders of these funds would retain their private keys following the network upgrade, the architectural changes set in motion by the upgrade would strip them of the ability to move or spend those assets on the modern network, leaving a historical fraction of the cryptocurrency locked in place unless migrated beforehand.
The exact timing for the mainnet activation of the NU7 upgrade remains undecided as development teams weigh testnet performance. The formal NU7 deployment specification, outlined in ZIP 259, currently leaves the activation height unassigned. Ecosystem stakeholders plan to make a definitive decision on October 20, drawing insights from ongoing testnet experiences. Providing this green light holds the door open for a conditional target activation date of November 5.
On-chain tracking tools, including the zkp.baby dashboard, captured the exact scale of the remaining funds, recording 22,309.44195128 ZEC sitting inside the Sprout pool at block 3,521,260, based on updates logged in late 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 protocol rule: rejecting all version 4 transactions starting from the NU7 activation onward. Because Sprout transfers rely exclusively on this older version 4 format—and because neither the newer version 5 nor version 6 formats support Sprout transactions—the network would effectively orphan any attempt to spend from the legacy pool.
Cryptographically, a private key remains the tool required to authorize a spend, but a blockchain network must also be programmed to accept the transaction carrying it. Under the proposed consensus rules, holders of Sprout-based ZEC would find themselves with no supported transaction format through which they could exercise that authority.
The sweep of this restriction touches every version 4 transaction type, encompassing both transparent-only and Sapling transactions, though the real-world consequences vary drastically depending on the specific pool involved. Users holding assets in non-Sprout pools can easily recreate their transactions in a supported, modern format where possible. Sprout, however, possesses no equivalent replacement. Simply attempting to re-sign an old version 4 transaction cannot bypass its fundamentally invalid format under the new rules, and even newer formats require signatures strictly appropriate to the updated consensus branch.
Notably, ZIP 2003 explicitly chooses to leave Sprout’s remaining balance within the broader issued supply of ZEC. The proposal leaves open the theoretical possibility of re-enabling version 4 transactions or engineering a separate retrieval facility down the line, though it explicitly warns stakeholders that spending functionality may never be restored once the upgrade goes live.
Recovery Takes Work, and Exiting Exposes Amounts
For holders seeking to rescue stranded funds, transitioning to current wallet software does not automatically safeguard the coins. Official documentation for Zallet, a Zcash wallet implementation, explicitly excludes Sprout spending keys and legacy funds from its standard import process, advising users instead to carefully preserve their original wallet.dat files.
Alternative paths exist for dedicated users, such as the Argos recovery tool, which documents a specialized route for holders possessing a legacy wallet file or standalone Sprout spending keys. A wallet containing usable note data and a cached witness can successfully bypass a historical blockchain scan. However, attempting recovery with a bare key alone may require reconstructing the additional data needed to construct a valid spend.
For such full-block scans, Argos estimates that users must contend with roughly 280 GB of transfer data and potentially days of processing time, even though the resulting tool data retains less than 500 MB on local disk storage. Furthermore, the tool points recovered funds toward a specific destination: its Sprout sweeps land natively in Sapling, a newer shielded pool, even if a Unified Address is supplied by the user. Moving those recovered funds onward to modern shielded pools remains a separate, subsequent operation.
Exiting the legacy pool also introduces notable privacy trade-offs, alongside transaction fees and heavy recovery workloads. According to the migration design outlined in ZIP 308, value moving from Sprout to Sapling must pass through public pool accounting mechanics. This transition exposes the exact transaction amount to public visibility, although it avoids tying the movement directly to a transparent address.
To mitigate privacy leakage, the Sprout-to-Sapling scheme specified in ZIP 308 coordinates transaction timing and randomizes amounts to reduce the statistical probability that individual transactions can be definitively linked to their owners. Even with these mitigations, ZIP 2003 warns that a short, rushed, or poorly coordinated exit period can create distinctive patterns in amounts and timing, making it significantly easier for third parties to associate the migrations with specific holders. Consequently, while the ultimate security and maintenance benefits of retiring Sprout are shared across the network, the logistical and privacy burdens of the migration fall squarely onto individual holders.
Hopwood’s proposal provides clear technical justifications for permanently removing Sprout’s spending path. The pool’s specialized cryptographic verification and unique handling of private notes and spent-note identifiers continue to impose processing overhead on live transaction acceptance, despite the pool seeing virtually negligible active use. Verification costs remain a critical consideration for network health, particularly regarding denial-of-service attack vectors during pending-transaction and block processing phases.
While Sprout shares certain cryptographic components with newer architectures like Sapling, and existing pool accounting checks help limit potential balance violations, the proposal maintains that these safeguards still leave behind unnecessary, Sprout-specific complexity that developers must continuously maintain. Retiring the pool entirely would permanently reduce that maintenance burden for all implementations validating the Zcash network.
This architectural shift follows a long-term trajectory for the privacy coin. An earlier protocol update, ZIP 211, successfully halted new value from entering the Sprout pool while preserving the ability of users to extract their legacy funds. ZIP 2003, originally drafted in late October 2024, represents the logical next step, effectively closing the spending door altogether under the NU7 framework.
A Mainnet Decision Still Lies Ahead
Development and testing are already well underway on public test networks. The Zcash Foundation announced the release of Zebra 7.0.0-rc.0 in early October, successfully scheduling the NU7 upgrade at testnet height 4,465,026. Subsequent engineering updates confirmed that the testnet had smoothly passed this critical activation milestone.
This progress follows a September coordination announcement, published on community forums, which reported a broad consensus among ecosystem organizations and engineering teams following community polling and extensive technical discussions. Previous polling efforts regarding tokenomics and upgrades were characterized as advisory by community leadership.
Under Zcash’s formal upgrade mechanism, network activation relies strictly on reaching a designated block height. For the upcoming NU7 rollout, ZIP 259 explicitly waives the network’s traditional recommendation of a three-month buffer following the first supporting software release, as well as requirements tied to the formal deprecation of unsupported software. The specification warns network operators that legacy, unsupported software may remain online and continue to follow pre-NU7 consensus rules unless properly updated. Consequently, operators must run compatible software to successfully validate and participate in the upgraded network.
With a community recovery discussion thread published in late September adding to the historical record of public warnings, all eyes now turn to the upcoming October 20 decision. Securing final approval and assigning an official mainnet activation height will establish a hard operational deadline, requiring any remaining Sprout holders to execute their valid migrations before the network barrier drops.
