Last checked: October 21, 2026.
Zcash's upcoming NU7 network upgrade is specified to disable version 4 (v4) transactions. Miners with Sprout balances should urgently verify whether their original wallet has a viable migration path before activation. Other pool miners should check their ZEC payout destination and receiving wallet, while node operators and services that build transactions should verify NU7 software compatibility.
The risk depends on the funds and transaction software, not simply on a wallet's age. The prohibition covers every v4 transaction; Sprout faces the greatest consequence because it has no alternative supported transaction format. Updating an ASIC's connection settings does not resolve either issue (ZIP 2003).
NU7 disables v4 transactions, not "old addresses"
Four concepts are easy to conflate and worth separating before making any changes to a mining or payout setup:
- A wallet or address type — for example, a transparent address, a Sapling shielded address, or a legacy Sprout address.
- A transaction version — the serialization format (v4, v5, or v6) that a transaction uses when broadcast to the network.
- A pool account payout setting — the withdrawal destination configured in a mining pool account.
- Mining connectivity — the Stratum endpoint and worker identifier an ASIC uses to submit shares.
An address does not carry a transaction version on its own. The transaction version is determined by the software that constructs the spend — a wallet, a payout processor, or node software — at the moment it builds the transaction. According to the NU7 deployment proposal, the upgrade does not introduce a new transaction format; it disables v4 while leaving v5 and v6 as the valid formats going forward (ZIP 259). This means a transparent-only or Sapling transaction built in v4 becomes invalid after activation in exactly the same way a Sprout v4 transaction does — the prohibition applies to the serialization version, not to a specific value pool.
Why Sprout wallets need urgent attention
Sprout is the original Zcash shielded pool, and Sprout spends can only be represented inside a v4 transaction. No alternative transaction format for Sprout currently exists in the protocol. As a direct consequence, any Zcash left in the Sprout pool that is not moved before NU7 activation will become unspendable under the currently specified consensus rules, absent a future protocol change (ZIP 2003).
A historical zc... address is a useful screening signal — Sprout shielded addresses commonly use that prefix, distinct from Sapling addresses (commonly zs...) and transparent addresses (commonly t...). However, the prefix should be treated as a starting point for investigation rather than definitive proof of risk; the actual wallet software should be used to confirm the address type and check for a remaining balance.
Miners who received early ZEC payouts — including historical pool payouts routed to shielded destinations before Sapling became the dominant shielded pool — should search self-custody wallets, archived backups, and old withdrawal records for any balance still sitting in a Sprout address.
There is an important practical limitation: ZIP 2003 states that the deprecation of zcashd removed the only maintained software that still provided Sprout wallet functionality. Consensus rules permitting a transfer before NU7 do not mean a maintained migration tool is available. Holders need to verify a viable recovery and transfer path for their original wallet; simply updating to a current wallet should not be assumed to provide Sprout support (ZIP 2003).
If a viable path is available, the transfer must be confirmed before activation. Re-signing a v4 transaction does not change its version, and Sprout transfers cannot be rebuilt as v5 or v6 transactions.
What pool miners should check
Disabling v4 transactions does not itself normally require pool miners to change ASIC configuration. Follow any specific compatibility instructions from the mining pool or hardware provider. The Stratum connection and worker name used to submit shares are unrelated to how the mining pool constructs ZEC payout transactions on the miner's behalf.
ViaBTC's ZEC mining setup, for example, uses a Stratum endpoint combined with a worker name in the userID.workerID format for submitting shares (ViaBTC ZEC Mining documentation). The ZEC withdrawal destination is configured separately in the account's asset settings.
The practical checklist for a pool miner is therefore:
- Confirm the ZEC withdrawal address currently configured in the pool account, rather than assuming it has not changed since it was first set.
- Confirm that the destination wallet or exchange account still accepts deposits to that specific address and address type in its current deposit interface, since support for a given address format can vary by service and can change over time.
ViaBTC's auto-withdrawal feature, documented separately from mining connectivity, lets an account route accumulated ZEC to a configured address once it reaches a published minimum of 0.001 ZEC, processed on a daily schedule (ViaBTC Auto Withdrawal documentation). This threshold and schedule are platform-specific settings, not Zcash network rules, and reviewing them is a reasonable step when confirming that a payout destination is current and correctly typed.
What solo miners and infrastructure operators should check
Miners who run their own full node, or services that construct Zcash transactions on behalf of users, face a broader set of requirements than a typical pool miner. NU7 changes network-level compatibility, not only transaction validity: nodes advertising a pre-NU7 network protocol version may be disconnected by upgraded peers, and blocks produced under the old consensus rules will not be accepted once the new rules are active (ZIP 259).
This is directly relevant to:
- Solo miners who run a node and build their own block templates or coinbase transactions.
- Pool operators responsible for payout processing.
- Wallet providers, custodians, and transaction-broadcast services.
- Block explorers and chain indexers that parse transaction data.
Any unconfirmed transaction prepared before activation should be reviewed to determine whether it was built in v4 format. If it was, and the funds are not Sprout funds, it generally needs to be recreated using NU7-compatible software rather than simply resubmitted; the deployment specification is explicit that software must stop constructing v4 transactions intended for inclusion after activation.
The NU7 timeline published on September 17, 2026 targets November 5, 2026 for mainnet activation and scheduled the final activation decision for October 20. When checked on October 21, 2026, ZIP 259 still displayed Draft status and a TBD mainnet activation height, while Zebra's mainnet-height implementation task remained open. These are observations about the published documents, not proof that developers have made no subsequent decision.
A developer decision, an updated deployment specification, and a released node implementation are separate milestones. Operators should verify the agreed mainnet height and a release that implements it before deployment. Zcash upgrades activate at a block height, so November 5 should not be treated as a guaranteed clock-time deadline for moving funds.
NU7 checklist for miners
- Search wallets, backups, and historical payout records for Sprout balances. If found, verify a viable migration path for the original wallet and complete any transfer before activation; maintained Sprout wallet support is no longer available according to ZIP 2003.
- Confirm whether the wallet software in use can construct valid post-NU7 transactions, rather than assuming compatibility based on age alone.
- Review the ZEC withdrawal destination configured in the mining pool account, separate from the mining connection settings.
- Confirm the receiving wallet or exchange currently accepts deposits to the specific address and address type being used.
- Check unconfirmed or offline-signed transactions prepared before activation. For non-Sprout v4 transactions, use compatible software to recreate them in a supported format where possible. Sprout transactions cannot be converted to v5 or v6; their funds must be moved before activation.
- If operating a full node, pool infrastructure, or a transaction-building service, upgrade to NU7-compatible software before the finalized activation height.
Conclusion
Sprout holders face both a protocol deadline and a practical recovery challenge: their funds depend on v4, and maintained Sprout wallet support has ended. Pool miners should verify their receiving wallet and payout destination, while infrastructure operators must prepare compatible software. Use current deployment documentation and node release notes to verify the activation height and implementation status.
Does NU7 require an ASIC firmware update?
Disabling v4 transactions does not itself normally require an ASIC firmware update for pool mining. It changes which transaction versions the network accepts and introduces no new transaction format. Check any specific firmware or configuration guidance from your pool and hardware provider.
Will my shielded ZEC balance stop working after NU7?
It depends on the shielded pool, not on the fact that an address is old. Sapling and other non-Sprout shielded transactions can still be represented in the v5 or v6 formats that remain valid after NU7. Only Sprout transfers depend exclusively on the v4 format that NU7 disables.
Do I need to change my ViaBTC worker configuration because of NU7?
Generally no. The Stratum endpoint and worker name used to submit shares are separate from the ZEC withdrawal address configured in the account's payout settings; NU7 affects transaction construction, not share submission.
Is November 5, 2026 a confirmed activation date?
November 5 is the target in the September 17 community timeline. On October 21, 2026, the ZIP 259 page checked for this article still showed a TBD mainnet height. That page status alone does not establish whether a newer developer decision exists. Verify the latest agreed height, deployment specification, and supporting node release; the actual activation follows block height rather than a fixed calendar time.