Zcash Activates NU7, Cutting Block Times and Changing How Fees Fund the Network
The upgrade targets 25-second blocks and sends 60% of transaction fees into a future-reward mechanism. It also ends spending from the legacy Sprout pool.

Zcash activated its NU7 network upgrade early on November 6 UTC, bringing a shorter target interval between blocks and a new mechanism for recycling transaction fees into future network rewards. The change is significant for both payments and the economics of securing the privacy-focused cryptocurrency. It also draws a hard boundary around an older part of the system: funds remaining in the legacy Sprout pool can no longer be spent under the new rules.
The activation occurred at mainnet block 3,543,405, the height specified in the deployment documentation. The ZecStats block tracker records activation at 02:34 UTC on November 6, or 9:34 p.m. Eastern Time on November 5, following preparations that had targeted around November 5. A blockchain upgrade is tied to its activation height rather than an ordinary calendar appointment, so the earlier estimate and the eventual date should not be treated as competing launch announcements.
Shorter blocks address one part of the payment wait
NU7 reduces the target spacing between blocks to 25 seconds from 75. The Zcash Foundation’s Zebra 7.0.0 release notes describe the change as a reduction in the average wait for a first confirmation. A target is a statistical property of the network: it does not promise that every individual block will arrive exactly on schedule.
That improvement does not turn every Zcash payment into an immediately available exchange balance. A receiving service can require several confirmations or impose its own processing controls. Wallet synchronization can also influence when a user sees an updated balance. A faster underlying chain helps one component of that journey, while the full experience still depends on the services through which a payment passes.
The upgrade also adjusts block subsidies and the remaining block-count intervals so that more frequent blocks do not simply triple issuance. The Foundation says daily scheduled issuance, the four-year halving schedule and the 21 million ZEC cap remain unchanged. That is a necessary economic counterpart to the shorter interval: block frequency and currency supply are connected through the reward rules, rather than moving independently.
Transaction fees become a source of later rewards
Under ZIP 235, 60% of each block’s transaction fees is removed from circulation, with the remaining portion available to miners. The intention is later algorithmic reissuance through the Network Sustainability Mechanism. Calling that change a permanent burn would misdescribe its design. The coins are intended to help fund later rewards, rather than disappear forever or become a discretionary investment fund.
ZIP 237 defines the reissuance mechanism, and the deployment specification sets its mainnet starting height at 8,939,664. Reissuance is therefore separate from today’s activation. The reserve balance represents value previously removed from circulation or left unclaimed under the specified rules. Its later distribution does not give the network permission to exceed the existing supply cap.
Economically, the mechanism shifts part of fee revenue across time. The amount accumulated will depend on actual transaction fees, while the later contribution to rewards will depend on the defined formula. Stronger network use could increase the fee base; the existence of the mechanism cannot demonstrate that such use will occur or that the resulting rewards will meet every future security need.
This is distinct from the separate proposal to redirect the grants program’s subsidy previously covered by TTN. That debate concerns a proposed funding allocation. NU7’s fee rules concern an activated consensus change. Combining the two would make a governance discussion appear settled merely because another reserve-related mechanism has gone live.
Sprout’s retirement has an immediate consequence
NU7 rejects version 4 transactions, while versions 5 and 6 remain valid. ZIP 2003 explains that Sprout transfers can only be represented through version 4, which makes the remaining Sprout funds unspendable. The effect is broader than a wallet interface changing: a compatible wallet cannot bypass a transaction format that the consensus rules no longer accept.
The same document explicitly distinguishes that restriction from permanently burning or unissuing the coins. A future consensus change could theoretically restore a retrieval mechanism, but the specification warns that spending may never be re-enabled. It would therefore be misleading either to describe recovery as guaranteed or to say the funds have already been permanently destroyed.
Deployment quality now matters as much as the specification
The Foundation warned that older nodes could follow a different chain after activation and instructed operators to upgrade. It also described new shielded-activity limits intended to bound processing and synchronization costs as blocks arrive more frequently. A payment improvement has to remain practical for the infrastructure validating and serving the network, not merely attractive in a headline.
For users and investors, the immediate measures of success are operational: compatible services, reliable synchronization and payment handling under the new rules. Those are different from a forecast for ZEC’s market price. As with the distinction between token mechanics and financial rights in TTN’s DeFi guide, a protocol improvement needs to be assessed on the specific function it changes. NU7 supplies new rules; sustained use will determine their economic importance.
Sources and methodology
- Zcash Foundation: Zebra 7.0.0 release and NU7 implementation
- ZIP 259: deployment, activation heights and included changes
- ZIP 218: 25-second block target spacing
- ZIP 235: transaction fee removal and later reissuance
- ZIP 237: Network Sustainability Mechanism
- ZIP 2003: version 4 rejection and Sprout consequences
- ZecStats: observed activation block and UTC timestamp