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 ².
The version 6 transaction format ⁵, the Orchard Action circuit update ⁶, and ZIP 2005 ⁷.

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: TBD; Mainnet: TBD
MIN_NETWORK_PROTOCOL_VERSION (NU6.3): Testnet: TBD; Mainnet: TBD

The version group ID for version 6 transactions ⁵ is:

TX_VERSION_GROUP_ID (v6): TBD

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 block height ⁶, so it applies 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.

[TODO take account of changes that should be (but are not currently) made in ZIP 256. The check for each pool is now that the chain value pool balance stays within [0, MAX_MONEY].]

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”, or “Orchard 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 any of the “Sprout chain value pool balance”, “Sapling chain value pool balance”, “Orchard chain value pool balance”, or “Ironwood 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.

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.

ZIP 2005 activation

ZIP 2005 ⁷ activates at NU6.3: its \(\mathsf{ZIP2005ActivationHeight}\) (also referenced by § 3.2.1 ‘Note Plaintexts and Memo Fields’) is the NU6.3 ACTIVATION_HEIGHT for each network. From that height, 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.