Zcash Foundation announced Zebra 7.0.0 on October 22, 2026, with Mainnet NU7 support at height 3,543,405, estimated around November 5. Node operators need to prepare before the activation height. For a holder planning a transfer, the calendar estimate is not a guaranteed payment time, and the node's database transition is a separate operational change.
There are two transitions to put on the operator's calendar
The network activates rules at a block height. Separately, a local installation changes its own database when the new software first starts. Neither should be described merely as ‘the November update.’ That phrase hides when the operator must act and whether a local rollback would still be possible after the program has touched existing state.
The exact v7.0.0 notes describe a move from database format v28 to v29. They say existing state migrates without a resync, but Zebra 6.x cannot use the resulting v29 database. They advise preserving the v28 state before upgrading; returning to the older version after migration otherwise requires a full resync. Follow the complete instructions for the actual installation.
| Boundary | What determines it | Planning question |
|---|---|---|
| NU7 Mainnet activation | The specified chain height | Will the service be ready before that height? |
| Local database migration | First start of the new installation on existing state | Has the old-state backup and rollback plan been reviewed? |
| A direct database reader | Compatibility with the migrated format | Is the reader being upgraded with the node? |
| A block arriving | Actual network production around a target interval | Has this particular transaction been included? |
| A recipient crediting a payment | The recipient's current processing rules | What confirmation and accounting state applies? |
A service can depend on more than the daemon
The Foundation's operator notes warn that components reading Zebra's state directly need compatible builds when the node changes format. Inventory those readers before maintenance. A running node and a broken dependent service can coexist; the fact that one process starts does not prove the whole application can read the new state or display payments correctly.
Target block spacing is not a receipt deadline
ZIP 218 specifies a reduction in target block spacing from 75 to 25 seconds under NU7. The arithmetic ratio is three to one. That does not promise that an individual transfer reaches its recipient in exactly 25 seconds, or that every service will divide its own crediting policy by three.
For example, a recipient may describe its policy in confirmations, while a wallet first shows a submitted operation. Inclusion, further confirmations and internal crediting remain separate observations. Ask what policy currently applies rather than converting a target interval into an all-inclusive timer. This article has not measured a live transfer or inspected a recipient's account.
A forecast date moves with the chain
Keep the activation height beside the date estimate in any maintenance note. If someone forwards only a November date, return to the official schedule and current release instructions. A calendar reminder helps organize work, but it should not replace the height-based condition. This text was prepared before the planned activation and does not declare it completed.
Separate the node operator's checklist from the holder's actions
- Operators: identify the installed release, state format and dependent services before planning maintenance.
- Review the official upgrade and old-state preservation instructions; include direct database readers in the plan.
- Track the specified Mainnet activation height separately from an approximate calendar date.
- Holders: read the wallet or sending provider's own readiness notice rather than applying server database steps to a personal wallet.
- For an existing payment, inspect its actual transaction and recipient-side record before considering another transfer.
Do not copy a node-state preservation procedure into a seed-recovery workflow. A node's chain-state database and a wallet's spending secrets serve different purposes. If a hosted service manages the node, ask about its readiness rather than attempting to restore its state yourself. No database directories were accessed or changed in researching this article.
Read the full release for the role you operate
The release contains further wallet, RPC, monitoring and compatibility changes beyond this database-and-timing review. An operator should read the applicable sections rather than treating this short matrix as complete deployment instructions. A holder should likewise check the chosen wallet's supported version. Installing a node release alone does not prove a separate wallet application has adopted all required changes.
Keep an exchange order outside the activation estimate
Before a later no-account swap, review the supported assets and exchange process for the actual route. Zebra's release does not confirm KOT.CASH deployment, its Zcash receiving policy or an order extension. The concrete transaction and current order conditions remain the evidence for that operation.
Use the current activation information and supported stable Zebra release for your maintenance plan. Preserve the distinction between a supported future upgrade, a local database migration and an observed payment outcome. None of those three facts can stand in for the other two.
FAQ
Does the Zcash NU7 developer timeline guarantee November 5?
The Foundation gives an approximate date alongside an activation height. Keep the height as the network condition and recheck the current schedule before relying on a calendar reminder.
Can a Zcash NU7 node upgrade be reversed just by starting Zebra 6.x?
The release says Zebra 6.x cannot use the migrated v29 state. Review its old-state preservation and downgrade requirements before changing a real installation.
Does Zcash NU7's shorter block target guarantee a 25-second credit?
No: a target interval is not an individual transfer deadline. Inclusion, additional confirmations and recipient accounting still need their own evidence.