Ironwood Quantum Recoverability

By the argument in ⁴⁰, the best known generic quantum attack on a hash function is simply the classical attack of ⁴⁴. (In particular, the Brassard–Høyer–Tapp algorithm ⁴⁵ is entirely unimplementable for a 253-bit output size: to achieve the claimed speed-up, it would require running Grover's algorithm with a quantum circuit that does random accesses to a $2^{92.3}$-bit quantum memory.) Therefore, an output size of 253 bits does not exclude a hash function from being collapsing.

$\mathsf{Extract}_{\mathbb{P}}$ does not interfere with the QROM lift: it is a deterministic 2-to-1 map on non-identity Pallas points (sending $P$ and $-P$ to the same $x$-coordinate) and does not query $\mathsf{H^{rcm}}$ or any other random oracle, so it composes with the underlying random oracle the same way classically and quantumly. The factor of 2 from the 2-to-1 reduction is already absorbed into the break-probability bound (each $\mathsf{cm}_x$ has exactly two valid $\mathsf{cm}$ values, hence exactly two valid $\mathsf{rcm}$ values, as stated in the Spendability proof above).

This factor-of-2 absorption relies on the fibres $\{P, -P\}$ of $\mathsf{Extract}_{\mathbb{P}}$ forming a uniform partition of the non-identity points of $\mathbb{P}$ — the free $\mathbb{Z}/2$ negation action gives every fibre for non-identity points exactly size 2 — which is what lets birthday-style bounds substitute $r_{\mathbb{P}} \to r_{\mathbb{P}}/2$ cleanly. A non-uniform mapping would not admit such a substitution.

QROM lift of the security arguments

The classical-ROM reductions for both Spendability and key binding satisfy the standard conditions for a "clean" lift to the quantum random-oracle model:

• Straight-line. Neither reduction rewinds the adversary or measures intermediate state; both inspect the adversary's classical output and bound the probability over the random oracles' randomness. Rewinding-based QROM techniques ^{34 36} are therefore not needed.
• No adaptive reprogramming. Both reductions treat their random oracles as fixed random functions throughout; neither reprograms responses to adversary-queried inputs.

Concrete QROM bounds. By Zhandry's compressed-oracle technique ⁴⁶ (see also ⁴⁷ for a classical-style derivation), the classical $q^2 / N$ collision probability transfers to $O(q^3 / N)$ in QROM: an adversary making at most $q$ quantum queries to a random oracle with output space of size $N$ finds a collision with probability $O(q^3 / N)$. Applied to our reductions:

• $\varepsilon^{\mathsf{QROM}}_{\mathsf{Spendability}} \leq O\!\left(q_{\mathsf{rcm}}^3 / r_{\mathbb{P}}\right) + \varepsilon^{\mathsf{QROM}}_{\mathsf{kb}}$.
• $\varepsilon^{\mathsf{QROM}}_{\mathsf{kb}} \leq O\!\left(q_{\mathsf{kb}}^3 / r_{\mathbb{P}}\right)$.

These are worst-case theoretical bounds. An adversary that saturates them would need to mount a BHT-style attack, which is unimplementable for a 253-bit output (as discussed above, the BHT algorithm would require a quantum circuit randomly accessing a $2^{92.3}$-bit quantum memory). In practice the achievable bound remains close to the classical $q^2 / r_{\mathbb{P}}$, since the best known generic quantum attack is the classical attack of ⁴⁴ — Bernstein ⁴⁰ is careful to flag this as best-known rather than provably best.

For the parameters relevant to Zcash ($q_{\mathsf{rcm}}, q_{\mathsf{kb}} \ll 2^{60}$ and $r_{\mathbb{P}} \approx 2^{254}$), the $O(q^3 / r_{\mathbb{P}})$ worst-case bound is at most $\sim 2^{-74}$, while the practically achievable $O(q^2 / r_{\mathbb{P}})$ bound stays closer to $\sim 2^{-134}$.

Effects of discrete-logarithm-breaking attacks before the switch to the Recovery Protocol

A practical discrete-logarithm-breaking attack —either by a sufficiently large quantum computer running Shor's algorithm, or a major advance in classical cryptanalysis of the discrete logarithm or Diffie–Hellman problems— would compromise the cryptographic primitives underlying Zcash's shielded protocols.

Note and value commitments in the Orchard[ZSA] and Sapling protocols are Pedersen-style and lose binding; the proof systems used in the shielded protocols (Halo 2 over Vesta in Orchard[ZSA], Groth16 over BLS12-381 in Sapling or Sprout) lose soundness; and the RedDSA binding and spend authorization signatures in Orchard[ZSA] and Sapling can be forged. Sprout's note commitments are SHA-256-based and survive a discrete logarithm break, but the broken proof system is sufficient to forge JoinSplit statements, and the Ed25519 spend authorization and JoinSplit signatures can be forged. In addition, the ECDSA signatures used for transparent spend authentication can be forged.

The combined effect is severe. An adversary can:

• break Balance for any current shielded pool by forging Groth16 or Halo 2 proofs of balanced transactions;
• break Balance (alternatively) for the Sapling, Orchard, or Ironwood pools by forging value-commitment openings or binding signatures;
• break Spend authentication (i.e. steal funds, independently of a Balance break) for any current shielded pool by forging alternative note witnesses for any commitment on chain, or by forging Groth16 or Halo 2 proofs of valid spends;
• break Spend authentication (alternatively) for the Sapling, Orchard, or Ironwood pools by forging RedJubjub or RedPallas spend authorization signatures;
• break Spend authentication for the transparent pool by forging ECDSA-over-secp256k1 signatures used in scripts, provided that the public key has been revealed (i.e. if the address has been spent from previously, or if an attack is possible in the period between a transaction being exposed and it being confirmed);
• break Spendability for any current shielded pool via roadblock attacks or Faerie Gold attacks, preventing users from spending their own funds;
• break Privacy of note plaintexts for any current shielded pool by finding the $\mathsf{ivk}$ or $\mathsf{sk_{enc}}$ for any known shielded receiver address, or by breaking the Diffie–Hellman-based note encryption (again only for a known shielded receiver address).

Attacks against Balance for any current shielded pool, and against Spend authentication and Spendability for any (potentially unknown) shielded address, can be performed after finding only a single discrete logarithm. (More precisely, one logarithm on BLS12-381 suffices for attacks against Sprout and Sapling, and one on Pallas/Vesta for attacks against Orchard and Ironwood.)

Note that any current shielded pool includes the Ironwood pool. The Quantum Recoverability feature of the Ironwood pool does not make the Orchard protocol secure against quantum attacks. It is still imperative that Zcash switches off the Orchard, Sapling, and Sprout protocols, before attacks using quantum computers become feasible.

If a balance violation occurred in any pool before its protocol was switched off, it would not necessarily be detected. The only constraint on such attacks is the ZIP 209 turnstile mechanism ⁴⁸. If there were evidence of balance violation having occurred, confidence in Zcash as a whole could potentially be undermined despite the turnstile constraints (especially if the violation was in the largest pool, currently the Orchard pool). Therefore, it will be essential to ensure that the pre-quantum protocols are switched off well in advance of the potential availability of cryptographically relevant quantum computers.

Attacks on transparent spend authentication are not addressed by this proposal. ⁴⁹ discusses these attacks in the context of Bitcoin. For Zcash, we should note that P2PK and legacy P2MS (non-P2SH) scripts have never been supported by Zcash wallets, but Zcash is vulnerable to "on-spend" attacks in a similar way to Bitcoin, with the additional consideration that some Zcash wallets might be more likely to reuse transparent addresses. The discussion of Segwit in ⁴⁹ is not relevant to Zcash. The possibility of Quantum Recoverability support for a subset of transparent addresses is discussed in ⁵⁰.

Effects of discrete-logarithm-breaking attacks after the switch to the Recovery Protocol

We assume for this section that the legacy Orchard, OrchardZSA (if deployed), Sapling, and Sprout protocols will be switched off. Any remaining funds in the Orchard, Sapling, and Sprout pools would be rendered permanently unspendable.

It is anticipated that from the Ironwood pool onward, any future pools would be quantum-recoverable.

It is possible to enable the Recovery Protocol in advance of switching off the legacy protocols, but the benefit is only obtained for the protocol as a whole after the latter has happened.

The Balance, Spend authentication, and Spendability attacks affecting the Sprout (if ZIP 2003 is not deployed first ⁵¹), Sapling, Orchard, and Ironwood pools, or any future pool using discrete-logarithm-based cryptography, are possible only while spends using the corresponding legacy protocols remain enabled.

If the transparent protocol is not switched off, then the situation with respect to transparent spend authentication is unchanged. Balance for the transparent protocol cannot be violated directly by a discrete-logarithm break (but funds created by a balance violation in a shielded pool can be moved into the transparent pool up to that shielded pool's turnstile limit).

The changes made by ZIP 2005 are only intended to address Balance preservation, Spend authentication, and Spendability for Ironwood-pool notes. The situation with respect to Privacy is unchanged for any pool.

In particular, the note encryption for Ironwood, Orchard, Sapling, and Sprout pools is subject to "Harvest Now, Decrypt Later" attacks: that is, a discrete-logarithm-breaking attack can be attempted as long as an adversary has both the ciphertext (which is published on the block chain) and the receiver address. Other protocol changes are under consideration to mitigate this risk for future transfers.

Due to the zero-knowledge property, Groth16 and Halo 2 proofs do not leak further information relevant to Privacy when addresses are unknown. The same is true of Sapling or Orchard[ZSA] spend authentication signatures, due to key rerandomization.

Attacks addressed by the Recovery Protocol

The Recovery Statement's $\mathsf{BindKeys}$ constraint pins the key witness via $\mathsf{PRF^{expand}}$ (modelled as collapsing), not via discrete-logarithm hardness. So (if no mistakes are made in the design or instantiation), fresh Balance, Spend authentication, or Spendability attacks against the Recovery Protocol should require breaking post-quantum binding rather than just discrete logarithms. Funds in Ironwood-pool notes can therefore be spent through the Recovery Protocol after the switch. However, if the adversary attacked either Spendability (e.g. via a roadblock attack) or Spend authorization before the switch to the Recovery Protocol, then it could affect the legitimate holder's ability to spend the funds afterward. The window between the activation height of this ZIP and the switch is the critical exposure period for recoverable Ironwood-pool funds.

Note that we can precisely identify the set of note commitments for recoverable notes, even though we cannot decrypt them: the recoverable notes are exactly the Ironwood-pool notes, so their commitments are exactly those in the Ironwood pool's note commitment tree ⁵.

We can likewise identify the precise set of nullifiers for recoverable notes: they are exactly the Ironwood-pool nullifiers, which form a nullifier set separate from that of the Orchard pool ⁵.

Within the Recovery Statement we also know that the note being spent is recoverable.

Deployment

The activation height of this ZIP is the NU6.3 ACTIVATION_HEIGHT ⁵².

As far as the author of this ZIP is aware, all existing Zcash wallets already derive $(\mathsf{ak}, \mathsf{nk}, \mathsf{rivk})$ from a spending key $\mathsf{sk}$ in the way specified for the $\mathsf{use\_qsk} = \mathsf{false}$ case in § 4.2.3 ‘Orchard Key Components’ ¹⁵.

FROST distributed key generation requires the $\mathsf{use\_qsk} = \mathsf{true}$ case. There is no significant existing deployment of FROST, so we can write this into ZIP 312 from the start.

The part of the protocol that is new is the different input for $\mathsf{pre\_rcm}$. It would have been possible to use a separate pq-binding commitment, but $\mathsf{H^{rcm}}$ is already pq-binding and so doing it this way involves fewer components. This also allows us to avoid any security compromise and use 256-bit cryptovalues for both integrity and randomization, which would otherwise have been difficult.

Two options were considered for deployment:

1. Deploy this change prior to the next network upgrade. This would optimize the time to deployment if there were a significant time before the next upgrade. An activation height is still needed, in order to identify a height from which wallets must re-scan if they are missing recoverable notes due to late deployment.
2. Deploy this change at the same time as the next network upgrade (NU6.3), at the same time as v6 transactions.

The second option has been chosen. (The first had been the plan, until the Orchard circuit soundness vulnerability was discovered.) Deploying at an upgrade makes the set of recoverable notes easy to identify (they are exactly the Ironwood-pool notes), and it strengthens the case for migrating funds out of the Orchard pool: a migrating user gains both quantum recoverability and the improvement in supply-integrity confidence that NU6.3 provides.

This change is enforced from NU6.3: every Ironwood-pool output note is a recoverable note, and no Sapling or Orchard-pool output note is ⁵. When a compliant wallet receives a Sapling or Orchard-pool note, the associated funds need to be sent to the Ironwood pool in order to make them recoverable.

Note: if we prioritize spending non-recoverable notes, it is conceivable that an adversary could exploit this to improve arity leakage attacks. On the other hand, adversaries can already choose note values to manipulate the note selection algorithm to some extent.

References

Footnotes

1. Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" ↩

2. ZIP 200: Network Upgrade Mechanism ↩

3. Zcash Protocol Specification, Version 2026.8.0 [NU6.3] ↩ ↩²

4. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet ↩

5. ZIP 229: Version 6 Transaction Format ↩ ↩² ↩³ ↩⁴ ↩⁵

6. ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩ ↩² ↩³ ↩⁴

7. ZIP 227: Issuance of Zcash Shielded Assets ↩ ↩² ↩³

8. Post-Quantum Zcash (video, slides). Presentation by Daira-Emma Hopwood at ZconVI. ↩ ↩²

9. ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling child key derivation ↩

10. ZIP 32: Shielded Hierarchical Deterministic Wallets — Sapling internal key derivation ↩

11. ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard child key derivation ↩

12. ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard internal key derivation ↩ ↩² ↩³

13. ZIP 231: Memo Bundles ↩ ↩²

14. ZIP 312: FROST for Spend Authorization Multisignatures ↩

15. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 4.2.3: Orchard Key Components ↩ ↩² ↩³

16. ZIP 312: FROST for Spend Authorization Multisignatures — Threat Model ↩

17. SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes ↩

18. Zcash Protocol Specification, Version 2026.7.0 [NU6.2] ↩

19. Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.2.3: Orchard Key Components ↩ ↩²

20. Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.7.2: Sending Notes (Sapling) ↩ ↩²

21. Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.7.3: Sending Notes (Orchard) ↩ ↩²

22. Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 4.20: In-band secret distribution (Sapling and Orchard) ↩ ↩²

23. Zcash Protocol Specification, Version 2026.7.0 [NU6.2]. Section 5.3: Constants ↩

24. ZIP 312: FROST for Spend Authorization Multisignatures — Key Generation ↩ ↩²

25. BLAKE3: One Function, Fast Everywhere. Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox, 2020. See § 2.1.2 for the derive_key mode. ↩

26. ZIP 226: Transfer and Burn of Zcash Shielded Assets — Split Notes ↩

27. Understanding Zcash Security (video, slides). Presentation by Daira-Emma Hopwood at Zcon3. ↩ ↩²

28. Computationally binding quantum commitments. Dominique Unruh. Also published in EUROCRYPT 2016, LNCS vol. 9666. ↩ ↩²

29. Collapse-binding quantum commitments without random oracles. Dominique Unruh. Also published in ASIACRYPT 2016, LNCS vol. 10032. ↩ ↩² ↩³

30. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 4.7.3: Sending Notes (Orchard) ↩

31. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.7.1: Spend Authorization Signature (Sapling and Orchard) ↩

32. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.1.9: Sinsemilla Hash Function ↩

33. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.1.9: Sinsemilla Hash Function — Security argument ↩

34. Post-Quantum Succinct Arguments: Breaking the Quantum Rewinding Barrier. Alessandro Chiesa, Fermi Ma, Nicholas Spooner, and Mark Zhandr. Also published in FOCS 2021. ↩ ↩²

35. Collapseability of Tree Hashes. Aldo Gunsing and Bart Mennink. Also published in PQCrypto 2020, LNCS vol. 12100, pp. 524–544. ↩ ↩²

36. Quantum Rewinding for IOP-Based Succinct Arguments. Alessandro Chiesa, Marcel Dall'Agnol, Zijing Di, Ziyi Guan, and Nicholas Spooner. ↩ ↩²

37. The Sponge is Quantum Indifferentiable. Gorjan Alagic, Joseph Carolan, Christian Majenz, and Saliha Tokat. ↩ ↩²

38. A Graduate Course in Applied Cryptography (Version 0.6). Dan Boneh and Victor Shoup. See the "reasonable adversary" step in the proof of Theorem 8.4 (Davies–Meyer). ↩

39. Indistinguishability of Random Systems. Ueli Maurer. Also published in Advances in Cryptology — EUROCRYPT 2002, LNCS vol. 2332, pp. 110–132. ↩

40. Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete? Daniel J. Bernstein. Presented at SHARCS 2009. ↩ ↩² ↩³

41. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.4.9.7: Coordinate Extractor for Pallas ↩

42. Post-quantum security of the sponge construction. Jan Czajkowski, Leon Groot Bruinderink, Andreas Hülsing, Christian Schaffner, and Dominique Unruh. Also published in PQCrypto 2018, LNCS vol. 10786. ↩

43. Classical Proofs for the Quantum Collapsing Property of Classical Hash Functions. Serge Fehr. Also published in TCC 2018, LNCS vol. 11240, pp. 315–338. ↩

44. Parallel collision search with cryptanalytic applications. Paul C. van Oorschot and Michael Wiener. ↩ ↩²

45. Quantum Algorithm for the Collision Problem. Gilles Brassard, Peter Høyer, and Alain Tapp. Also published in LATIN 1998, LNCS vol. 1380, pp. 163–169. ↩

46. How to Record Quantum Queries, and Applications to Quantum Indifferentiability. Mark Zhandry. Also published in CRYPTO 2019, LNCS vol. 11693. ↩

47. On the Compressed-Oracle Technique, and Post-Quantum Security of Proofs of Sequential Work. Kai-Min Chung, Serge Fehr, Yu-Hsuan Huang, and Tai-Ning Liao.. Also published in EUROCRYPT 2021, LNCS vol. 12826. ↩

48. ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances ↩

49. Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations. Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar, Hartmut Neven, Thiago Bergamaschi, Justin Drake, and Dan Boneh ↩ ↩²

50. zcash/zips issue 1302: [ZIP 2007] Quantum recoverability of a subset of the transparent protocol ↩

51. ZIP 2003: Disallow version 4 transactions ↩

52. Deployment of the NU6.3 Network Upgrade) ↩