ZIP: 229
Title: Version 6 Transaction Format
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
        Kris Nuttycombe <kris@nutty.land>
        Dev Ojha <dev@valargroup.dev>
        Sean Bowe <sean@bowe.tech>
Status: Draft
Category: Consensus
Created: 2026-06-13
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/1326>

Terminology

The key words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” 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 term “Recovery Protocol” is to be interpreted as described in ⁵.

The terms below are to be interpreted as follows:

Orchard protocol (or Orchard shielded protocol)

The shared cryptographic design that supports the Orchard pool and the Ironwood pool, including the Pallas and Vesta curves, the Sinsemilla hash, the Action circuit (as modified by ⁶), the note, note commitment, nullifier, and key constructions, and the note encryption (as modified by ⁵) used for these two pools.

Orchard pool (or Orchard shielded pool)

The value pool, with its own note commitment tree, anchor, and chain value pool balance, that was introduced by ZIP 224 ⁷.

Ironwood pool (or Ironwood shielded pool)

A new value pool of the Orchard protocol, introduced by this ZIP, with its own note commitment tree, anchor, and chain value pool balance, distinct from the Orchard pool.

Abstract

This ZIP defines version 6 of the Zcash transaction format, to be activated at NU6.3 ⁸.

NU6.3 ⁸ introduces the Ironwood shielded pool, an Orchard-protocol successor to the Orchard pool, that ensures quantum recoverability ⁵ and has supply integrity supported from the start by formal verification efforts ⁹.

This requires a new transaction version that can hold an Ironwood component: a second Orchard-protocol shielded component that commits to, and spends from, the Ironwood pool rather than the Orchard pool. The Orchard Action encoding and the Halo 2 proof system are reused unchanged. The circuit is also shared between these pools, changed only slightly from the pre-NU6.3 circuit ⁶. This ZIP defines the corresponding transaction format, txid, signature-hash, and block-commitment changes.

The addition of the Ironwood pool does not change address structures or encodings. At the protocol level, Orchard spending-key and viewing-key material grants authority to spend or view notes in both the Orchard and Ironwood pools. However, NU6.3 enforces that outputs to the Orchard pool are sent to an Orchard-protocol-level address for which the transaction creator can authorize spends. The intent is that transfers between users will automatically create notes in the Ironwood pool. The address restriction discourages economic activity between users within the Orchard pool, and encourages faster migration to the Ironwood pool.

This ZIP specifies only the transaction format and its associated hashing. The Action circuit changes needed to restrict address usage within the Orchard pool are specified in ⁶, and implications for wallets are discussed in ¹⁰ and ¹¹. Activation parameters are specified in the NU6.3 deployment ZIP ⁸.

Motivation

The main purpose of the NU6.3 network upgrade is to bolster confidence in Zcash’s supply integrity, after the discovery and remediation of the Orchard soundness vulnerability described in ¹². The turnstile mechanism ¹³ ensures that the overall ZEC supply is bounded. However, since a substantial portion of ZEC was in the Orchard pool at the time this vulnerability was remediated, it is necessary to take further steps to ensure confidence in the supply by migrating funds to a new pool.

All funds in the Ironwood pool will be quantum-recoverable ⁵. The existing Zcash shielded protocols are dependent on the hardness of finding discrete logarithms; an adversary who can do so (via quantum computers or otherwise) would be able to steal or forge funds. In the event of needing to disable these protocols in order to prevent such attacks, it will be possible to use a Recovery Protocol to recover funds from the Ironwood pool. This Recovery Protocol is expected to remain secure against discrete-log-breaking and quantum adversaries. This change does not by itself make Zcash secure against attacks using quantum computers, but is a necessary and substantial step toward that goal.

Recovery would not be possible for funds still in the Sprout, Sapling, or Orchard pools; all such funds would be inaccessible after their respective protocols are disabled. They should be migrated to the Ironwood pool in order to take advantage of this change.

The version 6 transaction format also changes the authorization structure for all supported shielded pools (Sapling, Orchard, and Ironwood) so that anchors are considered to be authorizing data rather than effecting data. This allows a transaction to be pre-authorized and its proofs computed independently after choosing an anchor, and also improves opportunities for parallelism in transaction creation.

Privacy Implications

The turnstile mechanism reveals the amounts in each transaction that cross between pools, including the amounts migrated into the Ironwood pool. This is considered in full detail in ¹⁰.

There is no reason to believe that the soundness vulnerability described in ¹² could have led to any compromise of key material associated with existing addresses. Independent of the soundness bug, we recommend address rotation for quantum privacy implications discussed in ⁵.

Requirements

Changes relative to v5 transactions should be minimized.

The version 6 transaction format must be able to carry an Ironwood-pool component in addition to transparent-pool, Sapling-pool, and Orchard-pool components similar to those in a version 5 transaction.

The Ironwood component must reuse the Orchard Action design and component encoding, so that implementation is shared between them to the maximum extent possible.

The transaction identifier, authorizing-data commitment, and signature digests must commit to the Ironwood-pool component when it is present, using personalizations distinct from those used for the Orchard-pool component.

The changes to the authorization structure must support pre-authorizing transactions using spending key material, and later updating the anchor and proofs (for all supported shielded pools).

Personalizations for nodes in the digest tree must be changed when what is hashed at that node changes.

The flags fields in the Orchard-pool and Ironwood-pool components must support encoding an indication of whether outputs to the Orchard pool are required to use a protocol-level address for which the transaction creator can authorize spends.

The one known Orchard-supporting hardware wallet, Keystone, must continue to be able to sign v5 tx format Orchard -> Transparent unshielding transactions, without firmware update.

Non-requirements

The v6 transaction format need not support ZSAs, the zip233Amount field, the explicit fee field, or per-transparent-input sighash information that appeared in the withdrawn ZIP 230 ¹⁴, or those features and other extensibility affordances planned for ZIP 248 ¹⁵.

The value 6 for the transaction version number need not avoid collisions with the withdrawn ZIP 230 or with the current draft of ZIP 248.

Specification

Transaction Format

A version 6 transaction is encoded as follows. Fields up to and including the Orchard component are as in the version 5 format ¹⁶, except as noted; the Ironwood component is new.

Fields marked in the Note column are conditionally present:

The encoding of the transparent and Sapling fields is unchanged from version 5 ¹⁶. Ironwood Action descriptions use the same OrchardAction encoding as Orchard Action descriptions. Every Ironwood-pool output note uses the quantum-recoverable note plaintext format (lead byte 0x03) defined in ZIP 2005 ⁵; no Orchard-pool output note uses that format. This is the only note-level distinction between the two pools.

Two flagsOrchard bits have been renamed relative to version 5: enableSpendsOrchard → enableSpends and enableOutputsOrchard → enableOutputs. In version 6 these bits —together with enableCrossAddress— are defined with the same meaning in both flagsOrchard and flagsIronwood, so the previous ...Orchard suffix would be misleading.

Consensus Rules

The version 6 transaction format requires the changes below to the transaction consensus rules in § 7.1.2 ‘Transaction Consensus Rules’ ¹⁸, effective from NU6.3 activation. Purely editorial generalizations — such as replacing Orchard pool with Orchard or Ironwood pool, or updating cross-references — are not enumerated.

• Replace

[Pre-NU6.3] The transaction version number MUST be 4 or 5.

with

[NU6.3 onward] The transaction version number MUST be 4 or 5 or 6.

• Add

[NU6.3 onward] If the transaction version number is 6 then the version group ID MUST be 0xD884B698.

• Add

[NU6.3 onward] If effectiveVersion \(\geq 6\kern-0.05em\textsf{,}\) then nActionsIronwood MUST be less than \(2^{16}\kern-0.05em\textsf{.}\)

• Replace

[NU5 onward] If effectiveVersion \(\geq 5\) then this condition MUST hold: tx_in_count \(> 0\) or nSpendsSapling \(> 0\) or (nActionsOrchard \(> 0\) and enableSpendsOrchard \(= 1\kern-0.15em\) ).

with

[NU5, pre-NU6.3] If effectiveVersion \(= 5\) then this condition MUST hold: tx_in_count \(> 0\) or nSpendsSapling \(> 0\) or (nActionsOrchard \(> 0\) and enableSpendsOrchard \(= 1\kern-0.15em\) ).

[NU6.3 onward] If effectiveVersion \(\geq 6\) then this condition MUST hold: tx_in_count \(> 0\) or nSpendsSapling \(> 0\) or (nActionsOrchard \(> 0\) and enableSpendsOrchard \(= 1\kern-0.15em\) ) or (nActionsIronwood \(> 0\) and enableSpendsIronwood \(= 1\kern-0.15em\) ).

and likewise for the corresponding output-side condition, with tx_out_count, nOutputsSapling, enableOutputsOrchard, and enableOutputsIronwood in place of tx_in_count, nSpendsSapling, enableSpendsOrchard, and enableSpendsIronwood respectively.

• Add

[NU6.3 onward] If effectiveVersion \(\geq 6\) and nActionsIronwood \(> 0\kern-0.05em\textsf{,}\) then at least one of enableSpendsIronwood and enableOutputsIronwood MUST be 1.

• Add, parallel to the Orchard-pool binding-signature rule,

[NU6.3 onward] If effectiveVersion \(\geq 6\) and nActionsIronwood \(> 0\kern-0.05em\textsf{,}\) then bindingSigIronwood MUST represent a valid signature, under the Ironwood pool’s transaction binding validating key, of the SIGHASH transaction hash — with the binding validating key and SIGHASH as defined for the Ironwood pool in § 4.14 ‘Balance and Binding Signature (Orchard)’. As for the Orchard pool, validation of the R component of the signature prohibits non-canonical point encodings.

• Add

[NU6.3 onward] A coinbase transaction MUST NOT have any Orchard-pool Action Descriptions.

• Replace

[NU5 onward] In a version 5 coinbase transaction, the enableSpendsOrchard flag MUST be 0.

with

[NU5 onward] In a version 5 or version 6 coinbase transaction, the enableSpendsOrchard flag MUST be 0.

• Add

[NU6.3 onward] In a version 6 coinbase transaction, the enableSpendsIronwood flag MUST be 0.

• Replace

[NU5 onward] In a version 5 transaction, the reserved bits 2..7 of the flagsOrchard field MUST be zero.

with

[NU5 onward] In a version 5 or version 6 transaction, the reserved bits 2..7 of the flagsOrchard field MUST be zero.

• Add

[NU6.3 onward] In a version 6 transaction, the reserved bits 3..7 of the flagsIronwood field MUST be zero.

The enableCrossAddress bit is specified in ⁶. Note that the reserved-bit rules above leave bit 2 of flagsOrchard reserved as 0 (bits 2..7), while bit 2 of flagsIronwood is the enableCrossAddress bit (reserved bits 3..7); the Orchard pool’s cross-address restriction is enforced for its Actions from NU6.3 onward as specified in ⁶.

This ZIP additionally specifies, for the version 6 format, that the proofs in proofsOrchard and the signatures in vSpendAuthSigsOrchard each correspond 1:1 to the elements of vActionsOrchard, in the same order; and likewise the proofs in proofsIronwood and the signatures in vSpendAuthSigsIronwood to the elements of vActionsIronwood. (Conditional presence of fields is given in the format table above.)

Version 4, version 5, and version 6 transactions are all valid from NU6.3 activation onward; this ZIP defines only the version 6 format (the version 4 and version 5 formats are unchanged). The NU6.3 consensus rules on Orchard actions apply regardless of transaction version. In particular, the Orchard-protocol cross-address restriction is enforced for every Orchard-pool Action mined from NU6.3 onward ⁶, so that it cannot be bypassed by using a version 5 transaction.

See ⁸ for additional consensus requirements that apply to all transactions from NU6.3 onward, regardless of transaction version. (Briefly and non-normatively, these are that coinbase transactions must have an empty Orchard component; that the enableCrossAddress bit of flagsOrchard must be 0; and that \(\mathsf{v}^{\textit{OrchardPoolBalance}}\) must be nonnegative.)

Transaction Identifiers, Auth Digests, and Signature Digests

Version 6 transaction identifiers (txids), authorizing-data commitments (“auth digests”), and signature digests are computed as in ZIP 244 ¹⁹, with two changes: an Ironwood component digest is added, and for version 6 the Sapling, Orchard and Ironwood anchors move from effecting data to authorizing data. The version 5 algorithm is unchanged.

Ironwood component digest

Relative to the txid digest for v5 transactions ²⁰, the version 6 txid digest adds an Ironwood component digest as the last child, after the Orchard component digest:

txid_digest_v6 = BLAKE2b-256("ZcashTxHash_" || consensusBranchId,
                             header_digest || transparent_digest || sapling_digest_v6 ||
                             orchard_digest_v6 || ironwood_digest_v6)

Relative to the auth digest for v5 transactions ²¹, the version 6 auth digest adds an Ironwood auth digest as the last child, after the Orchard one:

auth_digest_v6 = BLAKE2b-256("ZTxAuthHash_" || consensusBranchId,
                             transparent_auth_digest || sapling_auth_digest_v6 ||
                             orchard_auth_digest_v6 || ironwood_auth_digest_v6)

Anchor commitment (version 6)

In version 5, the Sapling anchor (encoded redundantly as anchor in each sapling_spends_noncompact_digest) and the Orchard anchor (anchorOrchard in orchard_digest) are part of the effecting data: they are committed to in txid_digest, while the Sapling and Orchard auth digests commit only to proofs and signatures ²¹.

In version 6, for Sapling, Orchard, and Ironwood components, the anchor is instead part of the authorizing data. Relative to ZIP 244, for version 6 transactions:

• sapling_spends_noncompact_digest_v6, orchard_digest_v6, and ironwood_digest_v6 omit the anchor.
• sapling_auth_digest_v6, orchard_auth_digest_v6, and ironwood_auth_digest_v6 additionally commit to anchorSapling, anchorOrchard, or anchorIronwood respectively, after the existing fields. As in the serialization, each anchor is present only when its component has a spend or action referencing it: anchorSapling iff nSpendsSapling > 0, anchorOrchard iff nActionsOrchard > 0, and anchorIronwood iff nActionsIronwood > 0. In particular, a Sapling component with outputs but no spends (for example a transparent-to-Sapling transfer) commits to no anchorSapling.

This lets the anchor be updated (re-anchored to a more recent note commitment tree root) without changing the transaction ID, while the proofs still bind to the specific anchor used.

ironwood_digest_v6 and ironwood_auth_digest_v6 are computed with the same structure as orchard_digest_v6 and orchard_auth_digest_v6, but with Ironwood-specific 16-byte BLAKE2b-256 personalizations at each node. Also, distinct personalizations are used for Sapling and Orchard nodes where what is directly hashed has been affected as a result of moving the anchor commitments to auth data, as follows:

As in the case of Sapling and Orchard, when a version 6 transaction has no Ironwood actions, ironwood_digest_v6 and ironwood_auth_digest_v6 are the hashes of empty input under the component and auth personalizations respectively, i.e. BLAKE2b-256("ZTxIdIronwd_H_v6", []) and BLAKE2b-256("ZTxAuthIrnwdH_v6", []), which are distinct from the Orchard empty-component digests.

Summary of the resulting digest structure

Below, (*) indicates a node that is directly changed relative to v5, and (+) indicates a node that is added relative to v5.

The txid digest structure becomes:

txid_digest_v6
├── header_digest
├── transparent_digest
│   ├── prevouts_digest
│   ├── sequence_digest
│   └── outputs_digest
├── sapling_digest_v6
│   ├── sapling_spends_digest_v6
│   │   ├── sapling_spends_compact_digest
│   │   └── sapling_spends_noncompact_digest_v6 (*)
│   │       ├── cv
│   │       └── rk
│   ├── sapling_outputs_digest
│   │   ├── sapling_outputs_compact_digest
│   │   ├── sapling_outputs_memos_digest
│   │   └── sapling_outputs_noncompact_digest
│   └── valueBalance
├── orchard_digest_v6 (*)
│   ├── orchard_actions_compact_digest
│   ├── orchard_actions_memos_digest
│   ├── orchard_actions_noncompact_digest
│   ├── flagsOrchard
│   └── valueBalanceOrchard
└── ironwood_digest_v6 (+)
    ├── ironwood_actions_compact_digest_v6
    ├── ironwood_actions_memos_digest_v6
    ├── ironwood_actions_noncompact_digest_v6
    ├── flagsIronwood
    └── valueBalanceIronwood

The auth digest structure becomes:

auth_digest_v6
├── transparent_scripts_digest
├── sapling_auth_digest_v6 (*)
│   ├── vSpendProofsSapling
│   ├── vSpendAuthSigsSapling
│   ├── vOutputProofsSapling
│   ├── bindingSigSapling
│   └── anchorSapling (+)
├── orchard_auth_digest_v6 (*)
│   ├── proofsOrchard
│   ├── vSpendAuthSigsOrchard
│   ├── bindingSigOrchard
│   └── anchorOrchard (+)
└── ironwood_auth_digest_v6 (+)
    ├── proofsIronwood
    ├── vSpendAuthSigsIronwood
    ├── bindingSigIronwood
    └── anchorIronwood

Note that the nodes under each of sapling_digest_v6, orchard_digest_v6, ironwood_digest_v6, and their auth_digests are present only if the corresponding component is non-empty.

Block Commitments

The hashAuthDataRoot component of hashBlockCommitments ¹⁹ incorporates the version 6 auth digest — which now includes the Ironwood auth digest, and (per the change above) the anchors — with no further structural change.

Rationale

The main purpose of the NU6.3 network upgrade is to bolster confidence in Zcash’s supply integrity, after the discovery and remediation of the Orchard soundness vulnerability described in ¹².

The urgency of this motivation called for an accelerated timeline, which necessitated a high bar for feature inclusion. Therefore, even fairly straightforward improvements (such as ²², which had been “queued” for inclusion in the next transaction format update), were omitted from this upgrade.

Reuse of the Orchard protocol with minimal changes

Carrying the Ironwood pool as a second Orchard-protocol component, rather than defining a new shielded protocol, keeps the transaction-format and implementation surface small: the Action encoding, proving system, authorization, and note encryption (modulo the new note plaintext format defined by ⁵) are inherited unchanged. The pools are distinguished by their note commitment trees, nullifier sets, value pool balances, and component position, not by separate circuits.

Separate state

Giving the Ironwood pool its own note commitment tree, anchor, and nullifier set creates a state boundary from the Orchard pool, so that their chain value pool balance can be accounted for independently.

enableCrossAddress polarity

This flag is encoded in the enabled sense (1 = cross-address transfers enabled, the normal case for Ironwood-pool actions; 0 = action outputs restricted to use the same protocol-level address as the action’s spend), with bit 2 reserved as 0 before NU6.3. This is backward-compatible: an Orchard-pool spend after NU6.3 requires the restricted state, which is bit 2 = 0 — exactly the value that signers treating bit 2 as a reserved-zero bit already produce. The in-circuit constraint and the equivalent internal disableCrossAddress instance value are discussed in ⁶.

Deployment

This transaction format is deployed at NU6.3. Activation heights and the NU6.3 consensus branch ID are specified in ⁸; the version 6 version group ID is specified in § 7.1.2 ¹⁸.

Acknowledgements

We thank the developers of Penumbra ²³ for demonstrating the advantages of treating the note commitment tree anchor as authorizing data rather than effecting data.

References