Zcash’s proposed NU7 upgrade would close the spending route out of its oldest privacy pool, Sprout, which still held about 22,309 ZEC on Oct. 17. Holders could keep their private keys and still lose the ability to move those funds on the upgraded network.
Mainnet activation remains undecided. The NU7 deployment specification leaves the activation height unassigned, with a final decision planned for Oct. 20 after testnet experience. Nov. 5 remains the target, conditional on that decision.
The zkp.baby dashboard recorded 22,309.44195128 ZEC in Sprout at block 3,521,260, updated at 19:10:09 UTC on Oct. 17.
The change is set out in ZIP 2003, a Zcash improvement proposal whose listed owner is Daira-Emma Hopwood. It proposes rejecting version 4 transactions from NU7 onward. Sprout transfers require that format; neither version 5 nor version 6 supports them.
A private key authorizes a spend, but the network must also accept the transaction carrying it. Under the proposed rules, Sprout holders would have no supported format in which to exercise that authority.
The restriction reaches every version 4 transaction, including transparent-only and Sapling transactions. The consequences differ by pool. Users can recreate non-Sprout transactions in a supported format where possible. Sprout has no equivalent replacement. Merely re-signing a version 4 transaction cannot fix its invalid format, and even newer formats need signatures appropriate to the consensus branch.
ZIP 2003 explicitly leaves Sprout’s remaining balance in issued supply. It allows the theoretical possibility of re-enabling version 4 transactions or creating another retrieval facility, while warning that spending may never be restored.
Recovery takes work, and exiting exposes amounts
Moving to current wallet software does not necessarily move the coins. Zallet’s migration documentation explicitly excludes Sprout spending keys and funds from its import process and tells users to preserve their original wallet.dat.
The Argos recovery tool documents a route for holders with a legacy wallet file or standalone Sprout spending keys. A wallet containing usable note data and a cached witness can avoid a historical scan. With a key alone, recovery may require reconstructing the additional data needed to build a valid spend.
For that full-block scan, Argos estimates roughly 280 GB of transfer and potentially days of processing, while retaining less than 500 MB on disk.
Argos also documents a specific destination: its Sprout sweeps land in Sapling, a newer shielded pool, including when a Unified Address is supplied. Moving the recovered funds onward is a separate operation.
Exiting carries a privacy trade-off as well as fees and recovery work. ZIP 308’s migration design explains that Sprout-to-Sapling value passes through public pool accounting, exposing the amount without requiring a transparent address.
In the Sprout-to-Sapling scheme specified by ZIP 308, transaction timing is coordinated and amounts are randomized to reduce the chance that individual transactions can be linked. ZIP 2003 warns that a short or poorly coordinated exit period can make distinctive amounts and timing easier to associate with holders.
The security benefit is shared, while the migration burden falls on individual holders.
Hopwood’s proposal gives a concrete reason to remove Sprout’s spending path. Its specialized verification and handling of private notes and spent-note identifiers still add work to live transaction acceptance despite little use. Verification costs also matter for denial-of-service exposure in pending-transaction and block processing.
Some protections are already shared with newer systems. Sprout uses cryptographic components also used by Sapling, and pool accounting checks limit potential balance violations. The proposal argues that these safeguards still leave Sprout-specific complexity to maintain. Retirement would reduce that burden for implementations validating the network.
The direction has a history. ZIP 211 stopped new value entering Sprout while preserving the ability to extract existing funds. ZIP 2003, created on Oct. 31, 2024, would take the further step of closing spending under NU7.
A mainnet decision still lies ahead
Testnet implementation is already running. The Zcash Foundation announced Zebra 7.0.0-rc.0 on Oct. 2, scheduling NU7 at testnet height 4,465,026 around Oct. 6. An Oct. 10 engineering reply confirmed that testnet had passed activation.
The September coordination announcement, posted by the forum account ebfull, reported agreement among ecosystem organizations and engineering teams after polling and discussions. CryptoSlate’s earlier poll coverage described the coinholder result as advisory.
Zcash’s upgrade mechanism makes activation depend on a specified block height. For NU7, ZIP 259 also waives the usual recommendation of roughly three months after the first supporting release and the requirement tied to deprecation of unsupported software. It warns that unsupported software may remain online and follow pre-NU7 rules. Operators need compatible software to validate the upgraded network.
A community recovery thread published Sept. 20 adds to the public notice history. The decision planned for Oct. 20 is the next concrete signal. Approval and an assigned mainnet height would establish an operational cutoff. Sprout holders would need to confirm a valid migration before that height.
