# ZIP 258: Deployment of the NU6.3 Network Upgrade Status: Draft Owners: Daira-Emma Hopwood Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a Source date: 2026-10-16T02:56:04+01:00 [Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a) [Official source](https://zips.z.cash/zip-0258) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0258.md) · [Discussion](https://github.com/zcash/zips/issues/1304) Preamble **ZIP**: 258 **Title**: Deployment of the NU6.3 Network Upgrade **Owners**: [Daira-Emma Hopwood](mailto:daira@jacaranda.org) **Status**: Draft **Category**: Consensus / Network **Created**: 2026-06-19 **License**: MIT **Discussions-To**: [https://github.com/zcash/zips/issues/1304](https://github.com/zcash/zips/issues/1304) ## Terminology The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted as described in BCP 14 [1](#user-content-fn-bcp14) when, and only when, they appear in all capitals. The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [2](#user-content-fn-zip-0200) The character § is used when referring to sections of the Zcash Protocol Specification. [3](#user-content-fn-protocol) The terms "Mainnet" and "Testnet" are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. [4](#user-content-fn-protocol-networks) The terms "Orchard protocol", "*Orchard pool*", "*Ironwood pool*", "*Orchard-pool* Action", and "version 6 transaction" are to be interpreted as described in [5](#user-content-fn-zip-0229). ## Abstract This proposal defines the deployment of the NU6.3 network upgrade, which introduces the Ironwood shielded pool. The consensus changes for NU6.3 are specified across the version 6 transaction format [5](#user-content-fn-zip-0229), the Orchard Action circuit update [6](#user-content-fn-zip-2006), ZIP 2005 [7](#user-content-fn-zip-2005), and this ZIP, which fixes the activation parameters and the consensus rules that gate on NU6.3 activation regardless of transaction version. ## Specification ### NU6.3 deployment The primary sources of information about NU6.3 consensus protocol changes are: - The Zcash Protocol Specification [3](#user-content-fn-protocol) - ZIP 200: Network Upgrade Mechanism [2](#user-content-fn-zip-0200) - ZIP 229: Version 6 Transaction Format [5](#user-content-fn-zip-0229) - ZIP 2005: Ironwood Quantum Recoverability [7](#user-content-fn-zip-2005) - ZIP 2006: Restricting Transfers into the Orchard Pool [6](#user-content-fn-zip-2006) - ZIP 209: ... [8](#user-content-fn-zip-0209) (updated) - ZIP 213: ... [9](#user-content-fn-zip-0213) (updated) Wallet considerations are covered in: - ZIP 318: Orchard to Ironwood Migration [10](#user-content-fn-zip-0318) - ZIP 326: NU6.3 Consequences for Wallets [11](#user-content-fn-zip-0326) - ZIP 317: Proportional Fee Mechanism [^zip-0317] (updated) The network handshake and peer management mechanisms defined in ZIP 201 [12](#user-content-fn-zip-0201) also apply to this upgrade. The following network upgrade constants [2](#user-content-fn-zip-0200) are defined for the NU6.3 upgrade: CONSENSUS_BRANCH_ID : 0x37A5165B ACTIVATION_HEIGHT (NU6.3) : Testnet: 4134000 : Mainnet: 3428143 MIN_NETWORK_PROTOCOL_VERSION (NU6.3) : Testnet: 170160 : Mainnet: 170160 These values are assigned as described in ZIP 204 [13](#user-content-fn-zip-0204). Note that the Testnet and Mainnet protocol versions coincide for NU6.3, as they did for NU6.2; NU6.3 is the last upgrade for which they are permitted to coincide, and the assignment rule in ZIP 204 ensures they are distinct from NU7 onward. For each network (Testnet and Mainnet), nodes compatible with NU6.3 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6.3) for that activation. ### Consensus rules from NU6.3 activation The following consensus rules apply to every transaction in a block mined at a height greater than or equal to the NU6.3 ACTIVATION_HEIGHT, regardless of its transaction version. They ensure that, after NU6.3, the *Orchard pool* can only be spent from (not added to), and that cross-address transfers within the *Orchard pool* are disabled, so that newly created shielded value is directed into the *Ironwood pool*. - A coinbase transaction MUST NOT contain any *Orchard-pool* Actions; that is, its Orchard component MUST be empty. - Every *Orchard-pool* Action MUST be created with cross-address transfers disabled (the `enableCrossAddress` bit set as 0). This restriction is enforced by the Action circuit verifying key, which is selected by consensus branch [6](#user-content-fn-zip-2006), so it applies after NU6.3 activation to *Orchard-pool* Actions in version 5 transactions as well as version 6. - No new value may enter the *Orchard pool*: for every transaction, $\mathsf{v}^{\textit{OrchardPoolBalance}} \geq 0$ (so the encoded `valueBalanceOrchard` is nonnegative). Value may still leave the *Orchard pool*, including across the turnstile into the *Ironwood pool*. ### Changes to ZIP 209 ZIP 209 [8](#user-content-fn-zip-0209) is extended to track an Ironwood chain value pool balance and to require it, like the other shielded pool balances, not to become negative or result in a sum of all chain value pool balances greater than $\mathsf{MAX\_MONEY}$ zatoshis. These changes are expressed relative to those in ZIP 256 [14](#user-content-fn-zip-0256). In the Terminology section, after the paragraph > The "Orchard chain value pool balance" for a given block chain is the negation of the sum > of all `valueBalanceOrchard` fields for transactions in the block chain. (Before NU5 has > activated, the Orchard chain value pool balance is zero.) add > The "Ironwood chain value pool balance" for a given block chain is the negation of the sum > of all `valueBalanceIronwood` fields for transactions in the block chain. (Before NU6.3 > has activated, the Ironwood chain value pool balance is zero.) In the Specification section, replace > If any of the Sprout chain value pool balance, Sapling chain value pool balance, > Orchard chain value pool balance, transparent chain value pool balance, or > deferred development fund chain value pool balance would become negative in the > block chain created as a result of accepting a block, then all nodes MUST reject > the block as invalid. with > If the chain value pool balance for any of the *Sprout*, *Sapling*, *Orchard*, > *Ironwood*, *transparent*, or *deferred development fund pools* would become > negative in the block chain created as a result of accepting a block, then all > nodes MUST reject the block as invalid. Note that the reference to "these chain value pool balances" in the immediately following paragraph that constrains the sum of their values, should be interpreted as including the Ironwood chain value pool balance. ### Changes to the Protocol Specification Changes corresponding to the [ZIP 209 changes above](#changestozip209) are required in § 4.17 ‘Chain Value Pool Balances’ [15](#user-content-fn-protocol-chainvalue) to define an Ironwood chain value pool balance alongside those for the existing *Sprout*, *Sapling*, and *Orchard pools*. These mirror the changes above and are not spelled out here. Many changes are required throughout the specification to disambiguate pools from protocols (some of these were done previously in version 2026.6.4), and to add the *Ironwood pool* as another use of the Orchard protocol. Again these are not spelled out here. The following consensus rules are added, each an *Ironwood-pool* analog of an existing *Orchard-pool* (or *Sapling-pool*) rule: - The *Ironwood-pool* Action transfers of a transaction MUST be consistent with its `valueBalanceIronwood` value (as for `valueBalanceOrchard`). - The `anchorIronwood` field, whenever it exists (i.e. when there are any *Ironwood-pool* Action descriptions), MUST refer to some earlier block's final *Ironwood-pool* treestate (as for `anchorOrchard`). - A block MUST NOT add *Ironwood-pool* note commitments that would cause the *Ironwood-pool* note commitment tree to exceed its capacity of $2^{\mathsf{MerkleDepth}^{\mathsf{Orchard}}}$ leaf nodes (as for the *Orchard pool*). - Any *Ironwood-pool* output of a coinbase transaction decrypted to a note plaintext MUST have note plaintext lead byte `0x03` (the corresponding rule for the *Sapling* and *Orchard pools* requires `0x02`). ### Changes to ZIP 221 The history tree that commits to chain history [16](#user-content-fn-zip-0221) gains Ironwood metadata, exactly as it gained Orchard metadata at NU5. The new fields are computed and aggregated identically to the corresponding `...Orchard...` fields. In the "Tree Node specification" section, after field 14 `nOrchardTxCount`, add: > 15. [NU6.3 onward] `hashEarliestIronwoodRoot` > > > > > Leaf node > Calculated as the note commitment root of the final Ironwood treestate > (similar to `hashEarliestOrchardRoot`). > > > > > Internal or root node > Inherited from the left child. > > > > > Serialized as `char[32]`. > > 16. [NU6.3 onward] `hashLatestIronwoodRoot` > > > > > Leaf node > Calculated as the note commitment root of the final Ironwood treestate > (similar to `hashLatestOrchardRoot`). > > > > > Internal or root node > Inherited from the right child. > > > > > Serialized as `char[32]`. > > 17. [NU6.3 onward] `nIronwoodTxCount` > > > > > Leaf node > The number of transactions in the leaf block where `vActionsIronwood` > is non-empty. > > > > > Internal or root node > The sum of the `nIronwoodTxCount` field of both children. > > > > > Serialized as `CompactSize uint`. Replace > The fields marked "[NU5 onward]" are omitted before NU5 activation > [17](#user-content-fn-zip-0252). > > > > > Each node, when serialized, is between 147 and 171 bytes long (between 212 and 244 bytes > after NU5 activation). [...] with > The fields marked "[NU5 onward]" are omitted before NU5 activation > [17](#user-content-fn-zip-0252). The fields > marked "[NU6.3 onward]" are omitted before NU6.3 activation. > > > > > Each node, when serialized, is between 147 and 171 bytes long (between 212 and 244 bytes > after NU5 activation, and between 277 and 317 bytes after NU6.3 activation). [...] The pseudocode node structure and `serialize` / `make_leaf` / `make_parent` functions are extended with `hashEarliestIronwoodRoot`, `hashLatestIronwoodRoot`, and `nIronwoodTxCount` in the same way the "# NU5 only" Orchard fields were added (present iff NU6.3 has activated; the roots inherited from the left/right child and the count summed, in internal nodes). `hashChainHistoryRoot` continues to be the BLAKE2b-256 digest of the serialized root node; its value changes at NU6.3 only through the added node fields. The `hashBlockCommitments` header field [18](#user-content-fn-zip-0244) is unaffected beyond this. ### ZIP 2005 activation ZIP 2005 [7](#user-content-fn-zip-2005) activates at NU6.3 on each network. The *Ironwood pool* is created at NU6.3 activation; from that point onward, every *Ironwood-pool* output note uses the quantum-recoverable note plaintext format (lead byte `0x03`) defined in ZIP 2005. ### Implementation support It is proposed that `zcashd` will not implement the consensus changes for NU6.3. `zebra` is therefore expected to be the only full-validator implementation able to follow the consensus Zcash block chain from NU6.3 activation onward. ## Backward compatibility Prior to the network upgrade activating on each network, NU6.3 and pre-NU6.3 nodes are compatible and can connect to each other. However, NU6.3 nodes will have a preference for connecting to other NU6.3 nodes, so pre-NU6.3 nodes will gradually be disconnected in the run up to activation. Once the network upgrades, even though pre-NU6.3 nodes can still accept the numerically larger protocol version used by NU6.3 as being valid, NU6.3 nodes will always disconnect peers using lower protocol versions. ## References ### Footnotes 1. [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14) [↩](#user-content-fnref-bcp14) 2. [ZIP 200: Network Upgrade Mechanism](/zip/200) [↩](#user-content-fnref-zip-0200) [↩2](#user-content-fnref-zip-0200-2) [↩3](#user-content-fnref-zip-0200-3) 3. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3] or later](protocol/protocol.pdf) [↩](#user-content-fnref-protocol) [↩2](#user-content-fnref-protocol-2) 4. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) [↩](#user-content-fnref-protocol-networks) 5. [ZIP 229: Version 6 Transaction Format](/zip/229) [↩](#user-content-fnref-zip-0229) [↩2](#user-content-fnref-zip-0229-2) [↩3](#user-content-fnref-zip-0229-3) 6. [ZIP 2006: Restricting Transfers into the Orchard Pool](/zip/2006) [↩](#user-content-fnref-zip-2006) [↩2](#user-content-fnref-zip-2006-2) [↩3](#user-content-fnref-zip-2006-3) 7. [ZIP 2005: Ironwood Quantum Recoverability](/zip/2005) [↩](#user-content-fnref-zip-2005) [↩2](#user-content-fnref-zip-2005-2) [↩3](#user-content-fnref-zip-2005-3) 8. [ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances](/zip/209) [↩](#user-content-fnref-zip-0209) [↩2](#user-content-fnref-zip-0209-2) 9. [ZIP 213: Shielded Coinbase](/zip/213) [↩](#user-content-fnref-zip-0213) 10. [ZIP 318: Orchard to Ironwood Migration](/zip/318) [↩](#user-content-fnref-zip-0318) 11. [ZIP 326: NU6.3 Consequences for Wallets](/zip/326) [↩](#user-content-fnref-zip-0326) 12. [ZIP 201: Network Peer Management for Overwinter](/zip/201) [↩](#user-content-fnref-zip-0201) 13. [ZIP 204: Zcash P2P Network Protocol](/zip/204) [↩](#user-content-fnref-zip-0204) 14. [ZIP 256: Deployment of Consensus Bug Fixes Between NU6.1 and NU6.2](/zip/256) [↩](#user-content-fnref-zip-0256) 15. [Zcash Protocol Specification, Version 2026.8.0 [NU6.3] or later. Section 4.17: Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) [↩](#user-content-fnref-protocol-chainvalue) 16. [ZIP 221: FlyClient - Consensus-Layer Changes](/zip/221) [↩](#user-content-fnref-zip-0221) 17. [ZIP 252: Deployment of the NU5 Network Upgrade](/zip/252) [↩](#user-content-fnref-zip-0252) [↩2](#user-content-fnref-zip-0252-2) 18. [ZIP 244: Transaction Identifier Non-Malleability](/zip/244) [↩](#user-content-fnref-zip-0244) ## Citation relationships Cites: [ZIP 200](https://zips.tools/zip/200), [ZIP 201](https://zips.tools/zip/201), [ZIP 204](https://zips.tools/zip/204), [ZIP 209](https://zips.tools/zip/209), [ZIP 213](https://zips.tools/zip/213), [ZIP 221](https://zips.tools/zip/221), [ZIP 229](https://zips.tools/zip/229), [ZIP 244](https://zips.tools/zip/244), [ZIP 252](https://zips.tools/zip/252), [ZIP 256](https://zips.tools/zip/256), [ZIP 317](https://zips.tools/zip/317), [ZIP 318](https://zips.tools/zip/318), [ZIP 326](https://zips.tools/zip/326), [ZIP 2005](https://zips.tools/zip/2005), [ZIP 2006](https://zips.tools/zip/2006) Cited by: [ZIP 209](https://zips.tools/zip/209), [ZIP 229](https://zips.tools/zip/229), [ZIP 317](https://zips.tools/zip/317), [ZIP 318](https://zips.tools/zip/318), [ZIP 326](https://zips.tools/zip/326), [ZIP 374](https://zips.tools/zip/374), [ZIP 2005](https://zips.tools/zip/2005)