Key points
- NU7 would make Sprout funds unspendable under its rules; the proposal does not burn or unissue those coins.
- Zebra PR #11830 proposes block 3,543,405; the published deployment draft still shows mainnet height as TBD.
- A 25-second block target is not a guaranteed exchange deposit time; v4 compatibility checks also affect non-Sprout workflows.
PANTHER JOURNAL #046 · NEWS
The upgrade promises a shorter wait. For an old corner of Zcash, it also threatens to close the exit.
Zcash NU7 would reduce target block spacing from 75 to 25 seconds and make funds remaining in the legacy Sprout pool unspendable under the new rules. An October 20 code proposal sets mainnet activation at block 3,543,405; the deployment specification still showed the height as undecided when Panther checked on October 21. This is preparation for an upgrade, not confirmation that it is already live.
For holders of Zcash ($ZEC), the useful question is not simply whether the chain gets faster. It is whether their wallet or service still depends on functionality scheduled to disappear.
What changed in Zcash NU7 planning?
An October 20 pull request in Zcash Foundation’s Zebra repository proposes adding mainnet height 3,543,405 and raising the network protocol version to 170190. The request remained open at this check. A proposed code change is not a released node binary.
CoinDesk’s October 21 report places that height around November 5 and reports agreement among ZIP editors. That calendar date is an estimate tied to block production, not a guaranteed appointment.
Meanwhile, the published ZIP 259 deployment draft still listed mainnet activation as TBD. Readers should keep the agreed or proposed target, its integration into specifications, and software delivery separate. An exchange or wallet needs an implementation it can actually deploy.
What happens to Sprout funds at NU7?
ZIP 2003 proposes rejecting every version 4 transaction from NU7 onward. Sprout transfers require that format, so coins left in that pool would have no supported spending route after activation.
That does not mean the proposal burns or unissues those coins. Its authors leave open a theoretical future recovery mechanism, while warning that spending may never be re-enabled. Calling the change a guaranteed temporary freeze would therefore be misleading too.
The draft also flags a practical complication: the retirement of zcashd removed the only maintained wallet software with Sprout functionality. Owning a seed does not by itself establish that a current application can perform the needed operation.
This is a reason to identify the pool and consult trusted maintainers early, not to enter a recovery phrase into a migration website promoted in a reply or direct message. A ticker balance on a screen is not enough to tell you which transaction format a wallet constructs.
Do 25-second blocks mean instant deposits?
ZIP 218 proposes cutting target spacing to one-third of today’s interval. It also sets action limits to constrain processing and shielded-wallet synchronization costs.
For illustration, three target intervals fall from 225 seconds to 75 seconds. That arithmetic is not a service-level promise: actual block arrivals vary, and an exchange can choose its own confirmation policy. Faster blocks and a guaranteed threefold improvement in every customer’s deposit time are different claims.
The proposal explicitly does not argue that clients should lower confirmation counts. It also adjusts issuance per block to preserve the mined ZEC-per-day schedule. More blocks do not automatically mean three times the daily coin issuance.
What should holders and operators check?
The deployment draft warns that unsupported nodes could keep running on a pre-NU7 branch. It also says the v4 rejection extends beyond Sprout to transparent-only and Sapling transactions built in that format.
For holders, the next useful information is wallet-specific: which pool holds the funds, which formats the software uses, and what the maintainer recommends before activation. Do not assume every ZEC balance is affected in the same way.
For operators, check release notes, activation constants and transaction construction. Saved or offline-signed transactions also need upgrade checks; a familiar transaction format alone does not establish validity across a consensus change.
Panther’s recovery-phrase explainer covers why exposing seed words creates a separate danger. Upgrade preparation should not become a reason to disclose them.
Panther Takeaway
The speed headline matters. The compatibility cutoff matters more to anyone still using the old path.
Check the pool, check the supported software and watch the final activation releases. November 5 is the reported estimate—not a reason to wait until the last day to find out what your wallet actually holds.
Sources and verification
Primary evidence: Zebra PR #11830, ZIP 259, ZIP 2003 and ZIP 218. Independent reporting: CoinDesk, October 21, 2026. Checked October 21. Proposal status may change. This article does not verify any individual wallet balance or offer a migration service. Cover: conceptual illustration, not a product screenshot.
Responses
No responses yet. Start the conversation.
Panther Journal — The intelligence brief
Stay ahead of the story.
Free. New investigations delivered when published. Unsubscribe anytime.
