ZIP: 258
Title: Deployment of the NU6.3 Network Upgrade
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
Status: Draft
Category: Consensus / Network
Created: 2026-06-19
License: MIT
Discussions-To: <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 ¹ 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. ²

The character § is used when referring to sections of the Zcash Protocol Specification. ³

The terms “Mainnet” and “Testnet” are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. ⁴

The terms “Orchard protocol”, “Orchard pool”, “Ironwood pool”, “Orchard-pool Action”, and “version 6 transaction” are to be interpreted as described in ⁵.

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 ⁵, the Orchard Action circuit update ⁶, 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 ³
• ZIP 200: Network Upgrade Mechanism ²
• ZIP 229: Version 6 Transaction Format ⁵
• ZIP 2005: Ironwood Quantum Recoverability ⁷
• ZIP 2006: Restricting Transfers into the Orchard Pool ⁶
• ZIP 209: … ⁸ (updated)
• ZIP 213: … ⁹ (updated)

Wallet considerations are covered in:

• ZIP 318: Orchard to Ironwood Migration ¹⁰
• ZIP 326: NU6.3 Consequences for Wallets ¹¹
• ZIP 317: Proportional Fee Mechanism ¹² (updated)

The network handshake and peer management mechanisms defined in ZIP 201 ¹³ also apply to this upgrade.

The following network upgrade constants ² 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 ¹⁴. 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 ⁶, 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 ⁸ 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 ¹⁵.

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 are required in § 4.17 ‘Chain Value Pool Balances’ ¹⁶ 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 ¹⁷ 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:

1. [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].

2. [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].

3. [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 ¹⁸.

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 ¹⁸. 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 ¹⁹ is unaffected beyond this.

ZIP 2005 activation

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