Zcash Foundation has released Zebra 7.0.0 with NU7 mainnet support, telling node operators to upgrade before block 3,543,405, expected around Nov. 5.

Zcash Foundation said in its Oct. 22 announcement that mainnet operators must install the upgrade to remain on the consensus chain, while older 6.4.x releases will stop themselves days before activation.

“All Mainnet operators MUST upgrade before height 3,543,405 (~Nov 5) to stay on the consensus chain.”

The foundation listed 25-second blocks, a Network Sustainability Mechanism, and fixes for five security advisories among the release’s features.

Zebra operators face an earlier shutdown

The foundation’s Oct. 6 engineering update put the expected shutdown of Zebra 6.4.x around Nov. 2. Developers shortened the software’s operating period from 15 weeks to 12 weeks to bring that halt ahead of the planned network upgrade.

In the same update, the engineering team said expiry calculations and synchronization estimates had been adjusted to follow the block time in effect at each height. Without that adjustment, faster block production could make software stop earlier than intended.

NU7 reached public testnet at block 4,465,026 on Oct. 4, the foundation confirmed. The testnet activation introduced the consensus changes for observation before mainnet deployment.

As crypto.news previously reported on Oct. 21, developers had selected the mainnet activation height after an Oct. 20 meeting of ZIP editors. At that reporting cutoff, the change still awaited integration into the deployment specification.

The current ZIP 259 text now lists mainnet block 3,543,405. Its compatibility rules say upgraded nodes will disconnect peers advertising an older network protocol version after activation.

The specification warns that unsupported software can remain online and follow a pre-NU7 consensus branch. It does not establish how many operators are still using incompatible software.

Zcash targets faster confirmations without faster issuance

ZIP 218 sets the new block target at 25 seconds, down from 75 seconds. Its authors identify payments, exchange deposits, and cross-chain operations as uses affected by the wait for confirmations.

The proposal does not advise clients to cut their confirmation counts. Its discussion of rollback risk distinguishes between security models, including models based on an attacker’s share of mining power and those based on the economic cost of reversing a payment.

The foundation’s Oct. 2 release-candidate explanation says daily scheduled issuance stays unchanged because the software divides scheduled block rewards by three and adjusts the remaining halving intervals.

Its description retains the four-year halving schedule and the 21 million ZEC supply cap. Faster block production therefore does not mean the scheduled daily mining subsidy triples.

The September coinholder poll recorded roughly 99.9% support for shorter block spacing and 98.9% support for preserving halvings. Nearly 2.4 million ZEC participated, representing around 66% of eligible Ironwood balances at the snapshot, according to the published results covered on Sep. 16.

Voting closed on Sep. 14 after balances were recorded at mainnet block 3,459,350 on Aug. 24. Eligibility depended on spendable shielded funds held in Ironwood at that snapshot.

NU7 redirects fees into future mining rewards

The foundation’s release-candidate explanation describes a split in which 60% of transaction fees leave circulation for a reserve, while miners keep the remaining 40%.

Under the Network Sustainability Mechanism, the reserved funds can return gradually through future block rewards. The Oct. 21 activation coverage identified mainnet block 8,939,664 for the start of reissuance, expected around February 2031.

Coinholders had favored that timing with approximately 96.6% support in September’s poll. The deployment specification lists the reissuance height separately from the NU7 activation height.

The Oct. 2 technical explanation gives mining pools a related instruction. Because a coinbase transaction depends on selected transaction fees and the parent block’s reserve, miners should request a fresh block template instead of changing its transaction set or previous block themselves.

The foundation described shielded activity limits covering individual pools and a shared budget across pools. Its engineering update says those restrictions are designed to protect light wallets from spam while the network produces blocks more frequently.

ZIP 218 places the shared shielded budget at 330 actions per block, alongside separate pool limits. Its authors estimate that the changes cut worst-case daily light-wallet synchronization bandwidth from 271 megabytes to 169 megabytes, a reduction of roughly 37%.

The proposal notes a separate privacy trade-off. More frequent blocks give observers finer timing information, which can be combined with observations from networks or applications. Its authors say the new limits do not prevent traffic analysis or eliminate denial-of-service risk.

Sprout funds face a separate spending deadline

The Oct. 5 testnet coverage described another NU7 change affecting funds in Sprout, Zcash’s original shielded pool. Disabling version 4 transactions prevents spending those funds after activation unless holders move them beforehand.

ZIP 259 specifies that the prohibition applies to every version 4 transaction, including transparent-only and Sapling transactions. Saved transactions signed offline require the same activation checks.

The specification says versions 5 and 6 keep their existing structures, but their signatures commit to a consensus branch identifier. An unchanged transaction format does not guarantee a transaction remains valid across activation.