Ironwood and Branch Identifiers

Ironwood is the shielded pool introduced by Zcash network upgrade NU6.3 as the successor to Orchard for new shielded activity.¹ It activated on mainnet in July 2026, at block 3,428,143, in response to a soundness vulnerability found in Orchard that May; no exploitation was found.² It keeps Orchard’s action encoding and Halo 2 proof system but has its own note commitment trees, its own value balance, and different personalization strings in its transaction digests. Because the shapes of nullifiers, commitments, ephemeral keys and the 52-byte ciphertext head are unchanged, Skyhook’s accept path kept working through the upgrade without modification. The upgrade did, however, establish an operational rule for transaction builders: the consensus branch identifier must always be read from the live chain, never pinned.

Pool succession

Version-6 transactions can carry both pools at once. New shielded activity settles in Ironwood, while Orchard is restricted to withdrawals: funds leave it through Zcash’s turnstile into Ironwood, and coins already in Orchard stay there until their owners move them.² Both pools share the same underlying cryptography.³

Digest personalizations

Ironwood actions are hashed under new personalizations, the domain-separation strings fed into the hash function; ZTxIdIrnActCH_v6, for example, covers the compact digest, and related strings cover its sibling digests. They differ entirely from Orchard’s. A single wrong byte in a personalization produces a transaction identifier that matches nothing on-chain, with no diagnostic to explain why: the result is simply a different 32 bytes. The pipeline therefore pins every personalization with byte-level tests.

Separate trees

Each pool has its own commitment trees and anchors, and they must never be mixed. An Ironwood note proves its membership only against the Ironwood root, and an Orchard witness presented against an Ironwood anchor fails. The pipeline keeps the state of the two pools strictly separate through scanning, opening and witnessing, and its tests enforce the separation continuously.

Branch identifiers

Every Zcash transaction is stamped, in fixed header bytes, with the consensus branch under which it was built, and the branch changes at each network upgrade. During the NU6.3 era the testnet branch moved from 0x37a5165b to 0x77190ad9. A builder that copied the branch of the note funding its transaction stamped the old value, and the network rejected the transaction outright.

That failure produced a standing rule. Activation heights may appear in comments but never in consensus-critical code paths. At build time, a builder queries the chain for the current branch and the tip height together and stamps both fresh. With this rule, network upgrades are non-events rather than outages; the procedure has been used live since it was adopted, with no recurrence.

See also

• Anatomy of a Note
• The Pipeline
• How It Works, for the v6 transaction tree

References

1. ZIP 229: Version-6 transactions and the Ironwood component under NU6.3. ↩

2. “Ironwood is live on Zcash”, Zodl; “Zcash activates Ironwood upgrade, launching new shielded pool after Orchard vulnerability”, The Block. ↩ ↩²

3. ZIP 326: Wallet behavior across NU6.3, covering pools, scanning rules and use_qsk. ↩