ZIP: XXX
Title: Version 6 Transaction Format
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
        ‹other ZODL / Valar Group authors›
Status: Draft
Category: Consensus
Created: 2026-06-13
License: MIT
Discussions-To: ‹https://github.com/zcash/zips/issues/XXXX›

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 shielded pool, rather than the Orchard pool. The Ironwood component reuses the Orchard Action encoding and proof system unchanged. This ZIP defines the corresponding 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 ¹¹. 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, signature hash, and authorizing-data commitment 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

This ZIP does not define the Action circuit update for NU6.3 or its disableCrossAddress constraint (see ⁶), the activation height or consensus branch ID (see ⁹), or wallet behaviour associated with migration to Ironwood (see ¹¹).

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

• nVersionGroupId MUST equal the version 6 version group ID, and nConsensusBranchId MUST equal the NU6.3 consensus branch ID, both defined in ⁹.

• The proofs in proofsOrchard and the signatures in vSpendAuthSigsOrchard each correspond 1:1 to the elements of vActionsOrchard, in the same order; 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.)

• In each of flagsOrchard and flagsIronwood:

  • Bits 3..7 inclusive MUST be 0.
  • The semantics of the enableSpends and enableOutputs bits are as in ZIP 224 ⁷.
  • The enableCrossAddress bit is specified in ⁶. Before NU6.3 this bit of flagsOrchard was reserved as 0 in v5 transactions.

• For coinbase transactions,

  • The enableSpends bit of flagsIronwood MUST be 0.

• The anchorOrchard field refers to the Orchard note commitment tree, and the anchorIronwood field to the Ironwood note commitment tree. The Orchard and Ironwood pools have separate, independent note commitment trees and nullifier sets.

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, Signature Hashing, and Block Commitments

Version 6 transaction identifiers (txids), authorizing-data commitments (“auth digests”), and signature hashes 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.

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.

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.

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, the version 6 version group ID, and the NU6.3 consensus branch ID are specified in ⁹.

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