Zcash developers have agreed on a proposed mainnet activation height for NU7, giving the planned faster-block upgrade a concrete deployment point while leaving software integration still to be completed.
Sean Bowe opened a pull request on October 20 setting the height at block 3,543,405. His accompanying note said the number had been agreed at a ZIP editors’ meeting and that changes to proposal statuses and other details were needed alongside the merge.
The request had two approvals but remained open when checked for this report. The published deployment specification still listed the mainnet height as undetermined. Agreement on the number should therefore not be described as a completed release or activation.
A block height turns a timetable into an operating decision
The November 5 target is not itself new. Our earlier report on Zcash’s proposed faster-payment upgrade covered that timetable. The fresh step is selecting the block at which supporting software would begin enforcing the new rules.
A block height is more precise for a blockchain than a clock estimate because nodes can identify the same point from the chain they validate. The date attached to it remains an estimate as block production proceeds.
That gives infrastructure operators a reference for releases, testing and readiness checks. It also creates a distinction between code that knows the new rules and code that will continue applying the older ones.
Faster blocks bring compatibility requirements
NU7’s deployment proposal reduces target spacing from 75 seconds to 25 seconds. At those targets, three blocks would take about 75 seconds rather than 225 seconds on average, before allowing for variability or a service’s own policies.
That calculation does not mean every exchange will credit a deposit three times faster. An operator can change its confirmation requirements, and seeing a block is only one part of processing a customer transaction.
Our report on Gemini’s Zcash infrastructure migration described why synchronisation and recovery capacity matter when blocks arrive more frequently. Selecting an activation height makes that readiness work more concrete.
Older transaction formats face a cutoff
The proposed deployment rules also reject version 4 transactions after activation while retaining versions 5 and 6. Because Sprout transfers require version 4, funds remaining in that older pool would become unspendable under the new rules.
That is a specific compatibility problem rather than a claim that ordinary Zcash balances all face the same restriction. Wallets, saved transactions and services constructing payments need to be evaluated against the formats they actually use.
The work is also distinct from the proposal for one-time viewing keys in cross-chain swaps, which addresses privacy exposure from public receiving addresses.
The next milestones are the deployment proposal’s merge, compatible releases and operator adoption. A selected height advances the plan, but those implementation steps must still be checked before reporting NU7 as ready across the ecosystem.