Zcash guides
Zcash Network Upgrades: Timeline and Activation Heights
Quick Answer
This reference lists source-defined Mainnet parameters, not an independently observed chain timeline. The pinned zcashd file covers Overwinter through NU6.2; ZIP 258 and Zebra’s changelog add source evidence for NU6.3. NU7 candidate and advisory evidence remains a separate tracker. OVERWINTER — Mainnet height 347500; SAPLING — Mainnet height 419200; BLOSSOM — Mainnet height 653600; HEARTWOOD — Mainnet height 903000; CANOPY — Mainnet height 1046400; NU5 — Mainnet height 1687104; NU6 — Mainnet height 2726400; NU6.1 — Mainnet height 3146400; NU6.2 — Mainnet height 3364600.
Key Takeaways
- Zcash upgrades change consensus rules at specified block heights.
- Proposal status and publisher release support are different from observed activation.
- Wallet support must be checked against the relevant upgrade and release.
Mainnet parameter sequence
OVERWINTER — Mainnet height 347500; SAPLING — Mainnet height 419200; BLOSSOM — Mainnet height 653600; HEARTWOOD — Mainnet height 903000; CANOPY — Mainnet height 1046400; NU5 — Mainnet height 1687104; NU6 — Mainnet height 2726400; NU6.1 — Mainnet height 3146400; NU6.2 — Mainnet height 3364600. NU6.3 — Mainnet height 3428143 is from ZIP 258 and the separately pinned Zebra changelog, not this older zcashd parameter list.
These values were extracted only from the Mainnet parameter class, not from the repeated Testnet and regression-test sections. Source-check timestamps are retrieval dates; they are not dates on which these blocks were mined.
Heights are recorded as integers in blocks, not as timestamps, prices or total supply.
Why more than one source version is necessary
The preserved zcashd parameter file at its commit does not include an NU6.3 upgrade entry. It cannot support an assertion that NU6.3 never happened or that the old list is a complete current timeline.
ZIP 258 specifies NU6.3 Mainnet 3428143 and Testnet 4134000 while retaining Draft status. Zebra’s publisher changelog reports NU6.3 support at Mainnet height 3,428,143 in version 6.0.0.
Those scoped documents fill a source-coverage gap without pretending that this site independently validated the activation block or tested a running node.
Heights, calendar estimates and settled history
A configured activation height says which consensus rules a compatible node is intended to apply at a boundary. A projected calendar time depends on block production and must not be presented as an exact activation timestamp.
A historical activation claim requires an actual block and chain evidence, including the network and relevant rule version. This guide has code parameters and publisher text; it has not independently fetched and validated all activation blocks or mapped them to settled UTC timestamps.
Consequently no synthetic calendar dates are populated.
Document status and governance do not override consensus evidence
A ZIP can have a document status, an advisory poll can have an outcome, a release can include code and a chain can cross a configured height. They are separate records.
In particular, February and August NU7 advisory rounds must not be merged, and a question announcement is not a final tally. The NU7 tool preserves actual poll-source limitations and an immutable version difference rather than deriving activation from the most recent document edit.
NU6.3 and NU7 are not synonyms.
Upgrade interpretation changes pool and wallet questions
A new protocol or pool can change which accounting fields and wallet operations are needed. The Ironwood guide explains why a new pool must not be omitted or filled with zero when a third-party response is incomplete.
The wallet directory does not treat repository identity as support for every upgrade or platform. A supply reference based on old code is scheduled subsidy arithmetic, not proof of current circulating supply or a complete post-upgrade node implementation.
Researchers should inspect the matching tool limitations before using a historical parameter as an answer to a current operational question.
FAQ
Are these heights independently validated activation observations?
No. They are source-defined parameters and publisher implementation evidence; independent chain activation history is incomplete.
Why does the zcashd source stop at NU6.2?
The preserved source version has no NU6.3 entry. Newer deployment and Zebra evidence is cited separately; absence in an older file is not proof of absence on the chain.
Can I convert an activation height into an exact future time?
No. Block-production estimates are not guaranteed timestamps and must remain distinct from observed activation history.
Is NU7 activated because a ZIP or poll mentions it?
No. Document, advisory, implementation and chain activation evidence are separate; the NU7 tracker retains missing outcome and activation states.
Sources and Methodology
Page updated: . Source observation dates remain separate.
Source checked: 2026-10-01T16:25:34.040474+00:00
Source version and supporting details
- Pinned Mainnet parameter class sets upgrade heights from Overwinter 347500 to NU6.2 3364600.
- This source version lacks an NU6.3 upgrade entry.
Immutable repository commit 558f686599586f55def3db86955d74d3be44605e; source parameters, not independently observed activation history.
06392f1604c1fe643f7bb5ebd6b504a771cc78458b5945e16199d1167cbd26ba
Source checked: 2026-10-01T20:31:47.512621+00:00
Source version and supporting details
- Draft NU6.3 deployment source specifies Mainnet 3428143 and Testnet 4134000.
Immutable repository commit a735caf76ed8d3fa0a50e4f6b706ca9dac39079b; source parameters, not independently observed activation history.
79c0aaa9b53ddfad79c8ee3e3103ce3945abd25ba86d4efebd76d27940bab19b
Source checked: 2026-10-01T20:31:48.330534+00:00
Source version and supporting details
- Publisher release text for Zebra 6.0.0 identifies NU6.3 Mainnet support at 3,428,143.
Immutable repository commit 846faaf29c5f0b58d6ec0a30089f372779b34ac3; source parameters, not independently observed activation history.
5530de334cf53e35ab4708173993357bb62e83375138c2991c9dd9f938624a5e
Methodology and technical limitations
Reproducible method and limitations
The local installer validates source hashes and extracts the Mainnet section before the Testnet class, then checks the expected parameter sequence. NU6.3 is cited separately rather than spliced into the old source. This provides reproducible source reading, not independent activation, compatibility, security or current node verification. Review and reuse clearance are required before publication, and a changed upstream parameter should trigger a new pending review rather than silently replace a claimed historical observation.
Source dates describe the referenced observation or document, not a live price. How data is checked · Corrections