Add draft NU6.3 deployment and Version 6 Transaction Format ZIPs

[daira]

This PR adds two draft ZIPs for NU6.3 ("Version 6 Transaction Format" and "Deployment of the NU6.3 Network Upgrade"), together with a retitle and terminology rework of ZIP 2005 ("Ironwood Quantum Recoverability").

Version 6 Transaction Format (draft-zodl-valargroup-ironwood-txformat)

A draft (modelled on ZIP 225) specifying version 6 of the Zcash transaction format: a version 5 transaction extended with an Ironwood component — a second Orchard-protocol shielded component that commits to, and spends from, the new Ironwood pool, reusing the Orchard Action encoding and proof system unchanged.

• Framing (Abstract / Motivation / Privacy Implications): the Ironwood pool as a quantum-recoverable (ZIP 2005) Orchard-protocol successor; the supply-integrity motivation following the NU6.2 Orchard fix; the rule that Orchard outputs must be sent to an address the creator can authorize spends from (steering transfers into Ironwood); and the rationale for treating anchors as authorizing rather than effecting data.
• Transaction format: the v6 field layout (Ironwood component = Orchard component shape; no ZSAs, no zip233Amount, no explicit fee, no per-input sighash info), with presence markers for conditionally-present fields.
• Consensus rules: field presence and the flag bits (including enableCrossAddress at bit 2), with a pointer to ZIP 258 for the rules that gate on NU6.3 activation regardless of transaction version.
• Transaction identifiers, signature hashing, and block commitments: the Ironwood txid and auth digests with their 16-byte personalizations; the v6 move of the Sapling, Orchard, and Ironwood anchors from effecting to authorizing data (binding is via the proofs, not the signatures), with the resulting digest trees and per-node personalization changes; and the hashAuthDataRoot update.
• Changes to ZIP 221: Ironwood history-tree MMR node fields. (The ZIP 209 / § 4.17 chain-value-pool changes now live in ZIP 258.)

ZIP 258: Deployment of the NU6.3 Network Upgrade

Fixes the NU6.3 activation parameters (activation heights, consensus branch ID 0x37A5165B, v6 version-group ID) and the consensus rules that gate on NU6.3 activation regardless of transaction version:

• coinbase transactions MUST have an empty Orchard component;
• every Orchard-pool Action MUST set enableCrossAddress = 0 (enforced by the height-selected Action circuit verifying key, so it also covers Orchard Actions in v5 transactions);
• no new value may enter the Orchard pool ($\mathsf{v}$^{OrchardPoolBalance} $\geq 0$).

Also: the ZIP 209 Ironwood-chain-value-pool extension (with the corresponding § 4.17 protocol-spec change), ZIP 2005 activation at the NU6.3 height (note-plaintext lead byte 0x03), and the note that zcashd will not implement NU6.3 (so zebra is the full-validator of record). Closes #1304.

ZIP 2005 changes

Retitled to "Ironwood Quantum Recoverability" and aligned with the NU6.3 ZIP set: pool terminology ("Ironwood pool" naming, Raleway Italic pool names), cross-references, and the changes reviewed at the 2026-06-23 ZIP sync.

Status

The ZIPs were reviewed, ACKed, and feedback applied in the 2026-06-23 ZIP sync meeting.

A number of items are deferred to a follow-up PR:

• move the Changes to ZIP 221 into ZIP 258 (alongside the ZIP 209 changes);
• ZIP 317 changes: account for Ironwood actions in logical-action / fee accounting (they are counted the same as Orchard actions);
• the "Signature Hashing" section-title fix;
• a possible ZIP 246 cross-reference;
• proof-system wording;
• clarifying the anchor presence-conditions in the digest definitions;
• whether the recovery-protocol detail belongs in the Ironwood book.

Open spec item: the [0, MAX_MONEY] chain-value-pool check in the ZIP 209 changes (now in ZIP 258), pending the ZIP 256 update (#1295).

Drafted with the assistance of Claude Opus 4.8 (1M context).

[TalDerei]

some first pass observations over draft.

[TalDerei]

question, wondering what the v6 transaction format's relation to ZIP 246 is (specifically their overlapping digest sections), and whether it warrants a reference?

[TalDerei]

misleading section title; mentions "signature hashing", but doesn't define a signature digest like ZIP 244. it correctly defines txid_digest_v6 and auth_digest_v6, but not what spend authorization / binding signatures actually sign in this context.

[TalDerei]

small spec ambiguity: the way sapling_auth_digest_v6 is defined reads to me like it unconditionally commits to anchorSapling. i get that the serialization table only includes anchorSapling when nSpendsSapling > 0, but it'd be clearer if the digest section carried that condition over explicitly. mostly just trying to keep the consistency local here rather than make readers reason across sections. for instance, i'd need to figure out how to handle the anchor in the case of a transparent to sapling transfer wherenOutputsSapling > 0 && nSpendsSapling == 0.

[TalDerei]

semantics are normative to ZIP 225 instead of ZIP 224?

[TalDerei]

related to fees, can you remind me why the conventional fee logic in ZIP 317 doesn't need to be modified in an update ZIP to account for ironwood bundles? it may still be worth an explicit note that Ironwood actions are counted the same as Orchard actions for logical action accounting.

[ValarDragon]

Daira in ZIP call says it does

[ValarDragon]

Revisit proof system wording in follow-up

[ValarDragon]

The words "flag" or "enableSpends" do not appear in 224, likely as 225 as a ref?

[ValarDragon]

Agreed that this does not block merge, it's in the protocol spec

[ebfull]

4096000

@nuttycom says:

ghci> activationDate 4096000 4088173
2026-06-30 16:41:01.781410625 UTC

[ValarDragon]

LGTM, we reviewed in ZIP editor meeting

[TalDerei]

post-merge ACK, assuming follow-ups.