ZEC View

Zcash guides

Zcash Ironwood: NU6.3 Upgrade and Pool Migration

Quick Answer

ZIP 258 describes NU6.3 as introducing the Ironwood shielded pool, with Mainnet activation parameter 3428143 and Testnet parameter 4134000. The pinned ZIP still says Draft, while Zebra’s publisher changelog describes Mainnet support at that height. This project has not independently verified live chain activation or migration completion.

Key Takeaways

  • Ironwood and the older Orchard pool are distinct pool labels.
  • The Orchard protocol is not synonymous with the historical Orchard pool.
  • Pool balance changes do not establish how many users migrated.

What the deployment document actually establishes

The pinned ZIP 258 specifies a consensus branch identifier, separate Mainnet and Testnet activation heights and a minimum network protocol version. A height is a consensus parameter, not a wall-clock guarantee.

The header’s Draft status is preserved here rather than silently relabeled Activated. Zebra’s separately pinned changelog says version 6.0.0 supports NU6.3 at Mainnet height 3,428,143.

That is evidence of a publisher-stated implementation boundary, not an independently validated activation block observed by this project. Researchers should not combine the document status and release statement into a stronger chain claim.

Orchard protocol is not the same thing as Orchard pool

ZIP 258 distinguishes the Orchard protocol from the historical Orchard pool and the new Ironwood pool. Its post-NU6.3 rules prohibit new value entering the Orchard pool, disable cross-address Orchard-pool transfers and allow value to leave it, including through the turnstile into Ironwood.

It also prohibits Orchard-pool Actions in coinbase transactions. These are source-described consensus rules.

They should not be simplified into a claim that all Orchard protocol addresses stop working, that all funds have already migrated, or that an aggregate pool balance measures users.

Migration guidance is not a wallet compatibility test

ZIP 318 describes migration best practices with light-client reliability and privacy concerns in view. ZIP 326 discusses scanning, key-generation constraints and wallet consequences, and distinguishes protocol-level receivers from pools.

Documentation of those consequences does not prove an installed wallet implements them. The wallet database preserves source-stated platform and commit scope; its current YWallet publisher non-support notice remains separate from historical capability descriptions.

This site does not import keys, construct migrations, connect to a wallet or ask readers to move funds.

Pool accounting must preserve every named pool

The deployment ZIP extends chain-value-pool rules to include Ironwood alongside Sprout, Sapling, Orchard, transparent and deferred-development pools. Its specification constrains negative balances and the sum of balances; it does not supply today’s pool amounts.

The local dashboard only renders captured third-party pool records, with missing fields and reconciliation issues retained. A missing Ironwood field cannot be assumed to be zero, and a report’s old pool example cannot establish current accounting after a protocol change.

Independent chain verification remains a separate blocked workstream.

Why a reserved document is not an implementation proof

The pinned ZIP 2006 file has a Reserved header and only a short metadata stub. ZIP 258 references it, but the stub itself cannot prove a complete circuit design or implementation.

This guide therefore cites substantive deployment and wallet documents plus Zebra release text, and records the incomplete source instead of inventing an explanation from the stub. Formal verification claims in the publisher documents are reported as claims, not as a proof independently audited by this project.

No assertion of absence of historical counterfeit activity is made.

FAQ

Has this site independently verified NU6.3 activation?

No. Deployment parameters and publisher implementation statements are preserved, but independent activation block validation has not been performed.

Does Draft mean no software implements the upgrade?

No. Document status and release support are different evidence layers; neither should be silently substituted for live chain validation.

Does a missing Ironwood pool value mean zero?

No. Missing is not zero, and current pool accounting requires a complete source snapshot and reconciliation.

Does this guide migrate funds or certify a wallet?

No. It explains source documents only; it accepts no keys and performs no transaction or device validation.

Sources and Methodology

Page updated: . Source observation dates remain separate.

zip258

Source checked: 2026-10-01T20:31:47.512621+00:00

Source version and supporting details
  • Draft deployment document identifies Mainnet 3428143 and Testnet 4134000.
  • Post-NU6.3 restrictions and Ironwood chain-value-pool accounting are specified.

Immutable repository commit a735caf76ed8d3fa0a50e4f6b706ca9dac39079b; document status and implementation claims are separate from independently observed activation.
79c0aaa9b53ddfad79c8ee3e3103ce3945abd25ba86d4efebd76d27940bab19b

zip318

Source checked: 2026-10-01T20:31:47.777968+00:00

Source version and supporting details
  • Migration best practices address wallet privacy and reliability, not independent device certification.

Immutable repository commit a735caf76ed8d3fa0a50e4f6b706ca9dac39079b; document status and implementation claims are separate from independently observed activation.
f64a90a020190731f752fa7a3e1cad33a160c89a0b06273dab021986aeebfead

zip326

Source checked: 2026-10-01T20:31:47.981125+00:00

Source version and supporting details
  • Draft wallet guidance separates Orchard-protocol receivers and pools and covers scanning and key restrictions.

Immutable repository commit a735caf76ed8d3fa0a50e4f6b706ca9dac39079b; document status and implementation claims are separate from independently observed activation.
162c4007e14ffa33f0a0a7562da9ae7d786cb1c6ea19c57e7fdd5ecf295815b6

zip2006

Source checked: 2026-10-01T20:31:48.173269+00:00

Source version and supporting details
  • Reserved metadata stub is not sufficient implementation evidence.

Immutable repository commit a735caf76ed8d3fa0a50e4f6b706ca9dac39079b; document status and implementation claims are separate from independently observed activation.
602bcfffad3a37054b7776955cabc20b993f12893847952927480cd4ebbc2bf9

zebra-changelog

Source checked: 2026-10-01T20:31:48.330534+00:00

Source version and supporting details
  • Publisher changelog for Zebra 6.0.0 dated 2026-07-10 states NU6.3 Mainnet activation support at height 3,428,143.

Immutable repository commit 846faaf29c5f0b58d6ec0a30089f372779b34ac3; document status and implementation claims are separate from independently observed activation.
5530de334cf53e35ab4708173993357bb62e83375138c2991c9dd9f938624a5e

Methodology and technical limitations

Method, source conflict and open verification

Five public repository snapshots were fetched at pinned commits and SHA-256 checked. ZIP 258 and ZIP 326 retain Draft status; ZIP 2006 retains Reserved status; the Zebra changelog describes implementation support. Different publishers and artifact types can have different update cadences. This guide reports their scoped statements without treating an index, merge or changelog as live-chain evidence. Activation block/hash validation, current migration totals, node reconciliation, complete device compatibility and expert review remain incomplete. The entire guide is local/private noindex and requires review and public reuse approval before publication.

Source dates describe the referenced observation or document, not a live price. How data is checked · Corrections