Zcash’s published NU7 deployment proposal reaches beyond block timing to the transaction formats that the network would accept. The document remains marked Proposed, so its specified activation height and consequences should be read as a plan rather than evidence that the upgrade is adopted or live.
TL;DR: The NU7 proposal specifies block 3,543,405 and 25-second target spacing. If activated as specified, it would invalidate version 4 transactions, with particular consequences for funds in the legacy Sprout pool.
The block height determines the transition
ZIP 259 sets out the proposed mainnet height and consensus changes. An earlier developer timeline targeted November 5, but the proposed activation rule depends on block height rather than a fixed calendar time.
This distinction matters for operational planning. Services should not assume an upgrade occurs at midnight on a date appearing in an event calendar. Monitoring the network and running compatible software are the relevant checks when a consensus transition is triggered by block production.
The specification warns that unsupported software can remain online while following pre-upgrade rules. A process appearing healthy is therefore not enough to establish that it is following the intended chain after activation.
Faster blocks would change waiting-time assumptions
ZIP 218 proposes a target-spacing reduction from 75 seconds to 25 seconds, alongside limits on shielded actions. It would also adjust issuance per block so that simply producing more blocks does not mechanically triple scheduled daily issuance.
For an application, a lower interval can shorten expected waiting time under an appropriate confirmation policy. It does not mean every transaction will arrive at perfectly regular 25-second intervals or that all businesses should use the same confirmation count.
A service that expresses a timeout only as a number of blocks should review its intended elapsed time. A reporting system may also need to distinguish a genuine change in activity from the mechanical increase in block frequency. Comparing raw counts across the upgrade without that context can produce misleading charts.
Version 4 retirement reaches beyond Sprout
ZIP 2003 explains that the proposed prohibition would apply to all version 4 transactions. It is not limited to transactions using Sprout. Versions 5 and 6 would remain available under the deployment plan, but they cannot represent Sprout transfers.
The resulting warning is specific: Sprout funds would become unspendable under the proposed post-upgrade rules. The proposal leaves open a theoretical future consensus change, while explicitly providing no assurance that spending will ever be restored. That should not be presented as a promised recovery route.
Other saved transactions require attention too. An unsigned template, offline-signed transfer or queued transaction can cross the activation boundary before broadcast. A signature does not make an obsolete format acceptable to the new rules.
Preparation should test the entire transaction path
For a wallet or exchange, the practical review spans transaction construction, signing, broadcasting and the error shown to the user. A failure message should distinguish an invalid transaction format from insufficient funds or a temporary connectivity issue.
Operators also need to verify the software responsible for indexing and crediting deposits. A compatible node with an incompatible downstream parser can still leave customers waiting for balances to update correctly.
Teams can prepare a compatibility inventory while tracking the proposal’s status. That inventory should identify which component constructs transactions, which signs them and which decides whether a deposit is complete. A software version recorded for one component does not establish readiness for every service in the chain.
The useful readiness question is whether the complete system could follow the specified rules if the deployment proceeds. The proposed shorter interval is visible in performance discussions; the transaction-format boundary deserves equal attention. Final operational decisions should follow the project’s authoritative deployment updates as well as the proposal text.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply