#Terminology

The key words "MUST", "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’. ⁴

We use the convention followed in the protocol specification that an $\underline{𝗎𝗇𝖽𝖾𝗋𝗅𝗂𝗇𝖾𝖽}$ variable indicates a byte sequence, and a variable suffixed with $\star$ indicates a bit-sequence encoding of an elliptic curve point.

The notation $\left(\genfrac{}{}{0px}{}{k}{n}\right)$ denotes the binomial coefficient — the number of ways of choosing $n$ items from a set of $k$, which is equal to $\frac{k!}{n!(k-n)!}$ for $0\le n\le k$.

For brevity, in the discussion sections of this ZIP we abbreviate ${𝖧}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ as ${𝖧}^{𝗋𝖼𝗆}$, $𝖯𝖱{𝖥}^{𝗇𝖿𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ as $𝖯𝖱{𝖥}^{𝗇𝖿}$, ${𝒦}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ as $𝒦$, and similarly for other Orchard-protocol-specific hash function names. The changes to the protocol specification and to other ZIPs use the full forms.

We will use the syntax ${𝖢𝗈𝗇𝗌𝗍𝗋𝗎𝖼𝗍𝗈𝗋}_1(T_1)|{𝖢𝗈𝗇𝗌𝗍𝗋𝗎𝖼𝗍𝗈𝗋}_2(T_2)$ for a tagged union type with tags ${𝖢𝗈𝗇𝗌𝗍𝗋𝗎𝖼𝗍𝗈𝗋}_1$ and ${𝖢𝗈𝗇𝗌𝗍𝗋𝗎𝖼𝗍𝗈𝗋}_2$. Such types can be destructured using a $\text{match}$ construct:

$\text{match }e\text{ with}\{\begin{array}{cc}{𝖢𝗈𝗇𝗌𝗍𝗋𝗎𝖼𝗍𝗈𝗋}_1(t_1)& \Rightarrow f(t_1)\\ {𝖢𝗈𝗇𝗌𝗍𝗋𝗎𝖼𝗍𝗈𝗋}_2(t_2)& \Rightarrow g(t_2)\text{.}\end{array}$

The terms "Ironwood pool" and "Orchard pool" are to be interpreted as described in ⁵. Following the convention in the protocol specification, we use slanted text to refer to pool names, in order to more clearly distinguish them from shielded protocols.

The terms "recoverable note" and "recoverable note plaintext" refer to a note or note plaintext that was created according to this proposal. As initially deployed, these are necessarily Ironwood-pool notes or note plaintexts.

The term "Recovery Protocol" refers to a potential new shielded protocol that would allow recovery of funds held in recoverable Ironwood-pool notes. This ZIP describes the Recovery Protocol in outline but not in detail: many of its design decisions are intentionally left open. The Recovery Protocol would also allow recovering notes created according to the ZSA extension to the Orchard protocol ^{6 7} if that were deployed.

#Abstract

This ZIP proposes a change to the construction of notes, to be deployed for the Ironwood pool ⁵, designed to improve Zcash's long-term resilience against a significant potential threat to its security from quantum computers. It does not by itself make the protocol secure against quantum adversaries, but is intended to support a smoother transition to future versions of Zcash designed to be so.

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-logarithm-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.

#Motivation

If quantum computers —or any other attack that allows finding discrete logarithms on the elliptic curves used in Zcash— were to become practical, it would raise difficult issues for the Zcash community. An adversary able to compute discrete logarithms (in fact, a single discrete logarithm is sufficient) could cause arbitrary inflation or steal users' funds.

Critically, the note commitment algorithms used by the Sapling and Orchard shielded protocols are not post-quantum binding. This means that even if the proof system were upgraded to one that is believed to be secure against quantum computers, and even if the note commitment tree were to be reconstructed (from public information) to use a suitable hash function, it would still be possible for a quantum or discrete-logarithm-breaking adversary to forge and spend notes that are not actually in the commitment tree — thus breaking the Balance property.

This ZIP proposes a small change to the way Orchard-protocol notes are derived, that would apply to all notes in the new Ironwood pool. If this change is made well in advance of quantum computers becoming viable, it would provide time for users to move their funds to the Ironwood pool, keeping them safe and recoverable after a subsequent post-quantum transition. This would not require any change to the Orchard-protocol (or proposed OrchardZSA-protocol) circuits for the time being, and would not require deciding on the particular proof system or note commitment tree hash used in the future protocol.

Recovering these funds after the post-quantum transition would involve checking a more expensive and complicated statement in zero knowledge, but it is expected that this will be entirely practical for the intended usage of recovering funds into another shielded pool. The current privacy properties of the Orchard protocol would be retained against pre-quantum adversaries, and also against post-quantum adversaries without knowledge of the notes' addresses. ⁸

To reduce overall protocol complexity and analysis effort, we do not propose a similar change for Sapling. Instead, Sapling funds can be migrated to the Ironwood pool in order to make them quantum-recoverable. (Note that this analysis effort needs to include the child and internal key derivations defined in ZIP 32, which differ significantly between the Sapling ^{9 10} and Orchard ^{11 12} protocols.)

This proposal is implementable at low risk, and required changes to existing libraries and wallets are small. It is compatible with Memo Bundles ¹³ and/or ZSAs ⁶.

#Requirements

• Ironwood-pool notes constructed according to this proposal should be spendable via a Recovery Protocol (to be introduced, potentially, in a future upgrade) that is expected to be secure against discrete-logarithm-breaking and quantum adversaries.
• No particular choice of post-quantum proving system or commitment tree hash should be assumed for that alternate protocol.
• The proposed scheme should be fully compatible with FROST threshold multisignatures ¹⁴, hardware wallets, and the combination of both.
• The proposed scheme should not require regeneration of existing non-multisignature keys or addresses.
• It should be possible for wallets to identify what subset of a user's funds have been made recoverable.
• The changes made to the pre-quantum protocol should not cause a significant regression in performance, applicability, or security against any given adversary class, or require significant re-analysis of that protocol's pre-quantum security.
• The Recovery Protocol should ensure no loss of security against pre-quantum adversaries — including when FROST threshold multisignatures and/or hardware wallets are used.
• Recovery of funds from hardware wallets that support this protocol should not require exposing the pre-quantum spend authorizing key $𝖺𝗌𝗄$ to theft.
• The proposal should be compatible with Zcash Shielded Assets with minimal additional complexity ^{6 7}.

#Non-requirements

• It is not required to address discrete-logarithm-breaking or quantum attacks on privacy with this proposal, as long as it does not cause any regression in privacy properties.
• It is not required to add support for the Recovery Protocol to consensus rules now.
• It is not required for spends using the Recovery Protocol to be as efficient as spends using the Orchard or Sapling protocols.
• It is not anticipated that spends using the Recovery Protocol will need to be indistinguishable from non-Recovery spends.

#High-level summary of changes

This subsection and the flow diagram below are non-normative.

This proposal defines a new note plaintext format to be used for recoverable notes (that is, those in the Ironwood pool), with lead byte $\mathrm{𝟶}𝚡\mathrm{𝟶𝟹}$. The $𝗉𝗋𝖾\_𝗋𝖼𝗆$ value is computed differently for this new format, by including all of the note fields in $𝗉𝗋𝖾\_𝗋𝖼𝗆$. This means that an adversary constrained to treat the PRF used to derive $𝗋𝖼𝗆$ from $𝗉𝗋𝖾\_𝗋𝖼𝗆$ as a random oracle, could not vary any note field without producing a different $𝗋𝖼𝗆$. This lets us argue that the overall commitment scheme is post-quantum binding, as long as the new derivation of $𝗋𝖼𝗆$ is checked in the Recovery Protocol.

Essentially the same technique also needs to be applied to the function $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ that is used to derive Orchard-protocol incoming viewing keys. The randomness $𝗋𝗂𝗏𝗄$ in $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ is derived directly or indirectly from $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$, which is in turn derived from one of two random oracles, depending on which key material the user holds:

• For existing Orchard-protocol keys, $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$ is derived from the secret key $𝗌𝗄$ via ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}(𝗌𝗄)$, with $𝖺𝗄$ and $𝗇𝗄$ also derived from $𝗌𝗄$. The Recovery Protocol checks all three derivations.
• For keys generated via FROST distributed key generation, or for hardware wallets where exporting $𝗌𝗄$ is undesirable, an alternative "quantum spending key" $𝗊𝗌𝗄$ and "quantum intermediate key" $𝗊𝗄$ are used, with $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)$. The Recovery Protocol checks this derivation together with a $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$ proof of knowledge of $𝗊𝗌𝗄$ such that ${𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)=𝗊𝗄$.

Both branches (and both cases $𝗋𝗂𝗏𝗄\in \{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,{𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)\}$) are covered uniformly by the Security argument for key binding: each binds the keys $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ —and $𝗊𝗄$, including whether it is in use— to the incoming-viewing key $𝗂𝗏𝗄$ post-quantumly, up to a small advantage against collision-finding in the random oracles used for $𝗋𝗂𝗏𝗄$ derivation. The FROST and hardware-wallet use cases are described in Usage with FROST and Usage with hardware wallets.

#Flow diagram for the Orchard protocol

This diagram shows, approximately, the derivation of Orchard-protocol keys, addresses, notes, note commitments, and nullifiers. All of the flow diagrams in this ZIP omit type conversions between curve points, field elements, byte sequences, and bit sequences, and so are not sufficiently precise to be used directly as a guide for implementation.

---
title: "Key to flow diagrams"
---
graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef keybox stroke:#808080, fill:#ffffff;
  classDef spacer opacity:0;

  key([sensitive key]):::sensitive ~~~ function:::func
  value([value]) ~~~ cond{{conditional value}}
  dummyA( ) -->|existing| dummyB( )
  dummyC( ) ==>|new| dummyD( )
  dummyE( ) -.->|optional| dummyF( )

The bold lines are changes introduced by this ZIP, which all take the form of additional inputs to derivation functions or alternative derivations. The derivations shown in the box labelled Proposed Recovery Statement are, roughly speaking, those enforced by the section of that name. The diagram shows the recoverable-note case ($𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟹}$); for $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$ the existing Orchard-protocol derivation $𝗋𝖼𝗆=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟻}]||\underline{\text{ρ}}))$ applies, and the additional fields feeding into $𝗉𝗋𝖾\_𝗋𝖼𝗆$ are absent.

graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef circuit stroke:#000000, fill:#fffff0;
  classDef spacer opacity:0;

  PostQC:::circuit
  subgraph PostQC[<div style="margin:1.1em;font-size:20px"><b>Proposed Recovery Statement</b></div>]
    direction BT
    rivk_ext([rivk_ext]) --> Hrivk_int[H<sup>rivk_int</sup>]:::func
    ak([ak]) --> Hrivk_int[H<sup>rivk_int</sup>]:::func
    nk --> Hrivk_int
    rivk_ext -->|¬is_internal_rivk| rivk
    Hrivk_int -->|is_internal_rivk| rivk{{rivk}}
    rivk --> Commitivk[Commit<sup>ivk</sup>]:::func
    ak([ak]) ----> Commitivk
    nk([nk]) ----> Commitivk
    Commitivk ---> ivk([ivk])
    gd ---> ivkmul[［ivk］g<sub>d</sub>&nbsp;]:::func
    ivk --> ivkmul
    rseed --> Hpsi[H<sup>ψ</sup>]:::func
    rho --> Hpsi
    v([#8239;v#8239;]) ==> pre_rcm([pre_rcm])
    pkd ====> pre_rcm
    gd ==> pre_rcm
    psi ===> pre_rcm
    rho([#8239;ρ#8239;]) --> pre_rcm
    v ~~~~ rcm
    ivkmul --> pkd([pk<sub>d</sub>])
    pre_rcm --> Hrcm[H<sup>rcm</sup>]:::func
    rseed([rseed]) --> Hrcm
    Hrcm --> rcm([rcm])
    Hpsi --> psi([#8239;ψ#8239;])
    gd --> NoteCommit:::func
    pkd --> NoteCommit
    psi --> NoteCommit
    v --> NoteCommit
    rcm --> NoteCommit
    rho --> NoteCommit
    cm --> DeriveNullifier:::func
    psi --> DeriveNullifier
    rho --> DeriveNullifier
    nk --> DeriveNullifier
    NoteCommit --> cm([cm])
    DeriveNullifier --> nf([nf])
    cm --> cmx([cm<sub><i>x</i></sub>])
  end

  d([#8239;d#8239;]) --> HashToCurve:::func ------> gd([g<sub>d</sub>])

#Specification

#Proactive movement of funds to recoverable notes

Once this proposal is deployed, wallets SHOULD move all of the funds they control (including transparent, Sprout, and Sapling funds) into recoverable Ironwood-pool notes as soon as practically possible. Other wallets are REQUIRED, as part of supporting the NU6.3 upgrade, to be able to receive these notes.

Non-recoverable funds may be received after existing funds have been made recoverable. Wallets SHOULD therefore treat the movement of funds to recoverable notes as an ongoing process.

#Usage with FROST

When generating Orchard-protocol keys for FROST, $𝖺𝗄$ will be derived jointly from the participants' shares of $𝖺𝗌𝗄$ according to the FROST Distributed Key Generation (DKG) protocol.

This ZIP further constrains FROST key generation for the Orchard procotol as follows: participants MUST privately agree on a value $𝗌𝗄$, and then use it with $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$ to derive $𝗇𝗄$, $𝗊𝗌𝗄$, $𝗊𝗄$, and (using the $𝖺𝗄$ output by the DKG protocol) $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$, as specified in § 4.2.3 ‘Orchard Key Components’ ¹⁵.

graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef circuit stroke:#000000, fill:#fffff0;
  classDef spacer opacity:0;

  sk([sk]):::sensitive --> Hnk[H<sup>nk</sup>]:::func ----> nk([nk])
  sk --> Hqsk[H<sup>qsk</sup>]:::func --> qsk([qsk]):::sensitive
  qk ==> Hrivk_ext
  nk ==> Hrivk_ext
  FROST_DKG --> ak([ak]) --> FROST_Sign
  FROST_DKG ~~~ s( ):::spacer ~~~ FROST_Sign
  FROST_DKG --> ask([ask<sub>i</sub>]):::sensitive --> FROST_Sign
  ak ==> Hrivk_ext[H<sup>rivk_ext</sup>]:::func
  Hrivk_ext ==>|use_qsk| rivk_ext([rivk_ext])

  HWW1:::circuit
  subgraph HWW1[<div style="margin:1.6em;font-size:20px"><br><br><br><br><br><br><br><br><br><b>SoK<sup>qsk</sup></b></div>]
    qsk([qsk]):::sensitive ==> Hqk[H<sup>qk</sup>]:::cefunc
    Hqk ==> qk([qk]):::semi_sensitive
  end

The protocol MUST ensure that all participants obtain the same values for $𝖺𝗄$, $𝗇𝗄$, and $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$. (Provided that the participants have followed § 4.2.3, this implies that they have the same $𝗊𝗌𝗄$ and $𝗊𝗄$, by collision resistance of ${𝖧}^{𝗊𝗄}$ and ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$.)

Each participant MUST treat $𝗊𝗌𝗄$ as a secret held at least as securely and reliably as $𝖺𝗌𝗄$. Note that $𝗊𝗌𝗄$ will not be needed to sign unless and until the Recovery Protocol is needed, but it is essential that it be retained, otherwise funds could be lost if and when the current Orchard protocol is disabled.

The Recovery Protocol will still require a RedDSA signature verifiable by the Spend validating key $𝖺𝗄$, in addition to knowledge of $𝗊𝗌𝗄$. RedDSA is not secure in the long term against a quantum or discrete-logarithm-breaking adversary. However, during any period in which the adversary cannot find discrete logarithms on the Pallas curve, checking this RedDSA signature will ensure that spend authorization continues to require a $t$-of-$n$ threshold of participants. An important advantage of FROST —that the parties can sign using their shares without reconstructing $𝖺𝗌𝗄$, the Spend authorizing key— is retained.

Note that a quantum adversary may be able to steal the funds with only access to $𝗊𝗌𝗄$, which is held by every participant (see below for more detail on Key storage options). Therefore, it is RECOMMENDED that as soon as a fully post-quantum protocol that supports threshold multisignatures is available, all funds held under FROST keys be transferred into that protocol's shielded pool.

#Usage with hardware wallets

The same $𝗎𝗌𝖾\_𝗊𝗌𝗄$ option can help to improve the efficiency of using the Recovery Protocol with hardware wallets. If the keys $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$, $𝗇𝗄$, and $𝖺𝗄$ are generated from $𝗌𝗄$, then the circuit for the Recovery Protocol will need to prove their correct derivation using ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$, ${𝖧}^{𝗇𝗄}$, ${𝖧}^{𝖺𝗌𝗄}$, and $𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼$ as shown in the $𝖲𝗈{𝖪}^{𝗌𝗄}$ box of the diagram below.

graph BT
  classDef default stroke:#111111;
  classDef func fill:#d0ffb8;
  classDef cefunc fill:#a0e0a0;
  classDef sensitive fill:#ffb0b0;
  classDef semi_sensitive fill:#ffb0ff;
  classDef circuit stroke:#000000, fill:#fffff0;
  classDef spacer opacity:0;

  HWW1:::circuit
  subgraph HWW1[<div style="margin:1.1em;font-size:20px"><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><b>SoK<sup>sk</sup></b></div>]
    sk --> Hrivk_legacy[H<sup>rivk_legacy</sup>]:::func ----> rivk_legacy
    DerivePublic --> ak([ak])
    sk([sk]):::sensitive --> Hnk[H<sup>nk</sup>]:::func ----> nk([nk])
    sk --> Hask[H<sup>ask</sup>]:::func --> ask([ask]):::sensitive
    ask --> DerivePublic:::func
  end

  HWW2:::circuit
  subgraph HWW2[<div style="margin:1.6em;font-size:20px"><br><br><br><br><br><br><br><br><br><b>SoK<sup>qsk</sup></b></div>]
    qsk([qsk]):::sensitive ==> Hqk[H<sup>qk</sup>]:::cefunc
    Hqk ==> qk([qk]):::semi_sensitive
  end

  sk -.-> Hqsk[H<sup>qsk</sup>]:::func -.-> qsk
  qk ==> Hrivk_ext[H<sup>rivk_ext</sup>]:::func
  nk([nk]) ==> Hrivk_ext
  ak ==> Hrivk_ext
  Hrivk_ext ==>|use_qsk| rivk_ext{{rivk_ext}}
  rivk_legacy([rivk_legacy]) -->|¬use_qsk| rivk_ext

When $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is used, on the other hand, it is possible for the Recovery Protocol to support spend authorization using a simpler statement that only uses ${𝖧}^{𝗊𝗄}$ and a commitment scheme. For example, for some hiding and collapse-binding commitment ${𝖼}_{𝗅𝗂𝗇𝗄}={𝖫𝗂𝗇𝗄𝖢𝗈𝗆𝗆𝗂𝗍}_r(𝗊𝗄,𝗌𝗂𝗀𝗁𝖺𝗌𝗁)$ the hardware wallet could prove knowledge of $(𝗊𝗌𝗄,r)$ such that ${𝖼}_{𝗅𝗂𝗇𝗄}={𝖫𝗂𝗇𝗄𝖢𝗈𝗆𝗆𝗂𝗍}_r({𝖧}^{𝗊𝗄}(𝗊𝗌𝗄),𝗌𝗂𝗀𝗁𝖺𝗌𝗁)\text{.}$ This statement, labelled as $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$ in the diagram, can be implemented in a much smaller circuit, so it might be feasible to do the proof in quite constrained hardware.

The commitment ${𝖼}_{𝗅𝗂𝗇𝗄}$ would be a public input opened to $(𝗊𝗄,𝗌𝗂𝗀𝗁𝖺𝗌𝗁)$ in the Recovery Statement, ensuring that the hardware wallet has authorized the spend for the correct key. Because $𝖫𝗂𝗇𝗄𝖢𝗈𝗆𝗆𝗂𝗍$ is hiding and the proofs are zero knowledge, no information is leaked about which $𝗊𝗄$ is being used.

#Key storage options and analysis

By host wallet, we mean the device that builds the spend transaction and produces the rest of the Recovery Statement proof. In a multi-signer FROST setup, this would be the Coordinator ¹⁶. The host wallet is given $𝗇𝗄$, $𝖺𝗄$, and (assuming $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is true) $𝗊𝗄$, for use in the Recovery Statement. Then two options are possible for storage of $𝗊𝗌𝗄$:

Option A — The $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$ proof is produced inside the hardware wallet, and $𝗊𝗌𝗄$ is retained there.

Option B — Alternatively, if the hardware wallet is unable to support proving $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$, it could be updated to permit exporting $𝗊𝗌𝗄$ to the host wallet, and the $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$ proof would be produced there.

In either option, $𝖺𝗌𝗄$ would remain on the hardware wallet which would continue to produce RedDSA spend authorization signatures (or perform its part of the FROST multi-signing protocol).

#Threat model

The Recovery Statement is assumed below to require both of:

• an $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$ proof verifying knowledge of $𝗊𝗌𝗄$ such that ${𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)=𝗊𝗄$ for the spent note's $𝗊𝗄$; and
• a RedDSA signature on $𝖺𝗄$, which under FROST is constructed by cooperation of $t$-of-$n$ hardware-wallet signers, each contributing using its share of $𝖺𝗌𝗄$.

Under this assumed structure, with FROST + hardware-wallet deployment, spend authorization is broken only by either:

1. $𝗊𝗌𝗄$ possession + finding discrete logarithms on the Pallas curve. The variants differ only in how $𝗊𝗌𝗄$ is obtained:

   1. the adversary is an authorized FROST signer — they hold a copy of $𝗊𝗌𝗄$ by construction;
   2. $𝗊𝗌𝗄$ is extracted from a hardware wallet, defeating Option A by a physical-device or side-channel attack;
   3. $𝗊𝗌𝗄$ is obtained after export to the host wallet, by compromising the host wallet or intercepting it during export.

2. Breaking a primitive or scheme. RedDSA, FROST, the DKG, or the proving system has a cryptographic weakness or implementation flaw.

#Choosing between Options A and B

Option A is preferred where the target hardware wallet is capable of proving $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$ on-device. Option B is a fallback for cases where it cannot — for instance, due to memory or secure-element constraints, uncertainty about the proof system that will be chosen and what will be tractable on small devices, or the device having been obsoleted before firmware support could be added.

Under Option A, the host wallet holds only the full viewing key ($𝖺𝗄$, $𝗇𝗄$) —which the pre-Quantum-Recoverability protocol already entrusted to it— plus $𝗊𝗄$. The $𝗊𝗌𝗄$ attack surface is then 1.a. or 1.b. only.

Option B additionally places $𝗊𝗌𝗄$ on the host wallet, admitting case 1.c. as well. This has the disadvantage that host-wallet compromise is a substantially larger attack surface than hardware-wallet extraction. However, even with $𝗊𝗌𝗄$ in hand, an adversary would still need to break RedDSA or find discrete logarithms on the Pallas curve to steal funds.

Note: with ZIP 32 hierarchical derivation, $𝗊𝗌𝗄$ need not be backed up separately from the seed phrase. When $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is true, $𝗊𝗌𝗄={𝖧}^{𝗊𝗌𝗄}(𝗌𝗄)$ where $𝗌𝗄$ is the HD-derived spending key, and so $𝗊𝗌𝗄$ can be re-derived from the seed phrase (with or without SLIP 39 Shamir backup ¹⁷). A deployment that does not use ZIP 32 is responsible for the security of its own backup arrangements.

#Usage with other proposals requiring note plaintext format changes

This proposal was originally designed to be deployed alongside ZSAs ^{6 7} and memo bundles ¹³, which also defined a new note plaintext format. Since this proposal now defines lead byte $\mathrm{𝟶}𝚡\mathrm{𝟶𝟹}$, those proposals will need to use a new lead byte value or values.

#Specification Updates

This is written as a set of changes relative to version 2026.7.0 of the protocol specification ¹⁸, and to the contents of ZIPs as of July 2026. The protocol specification changes will be applied in version 2026.8.0 ³.

#Changes to the Protocol Specification

#§ 2 ‘Notation’

In the list of integer constants that will be instantiated in § 5.3 ‘Constants’, add ${\ell }_{𝗊𝗌𝗄}$ and ${\ell }_{𝗊𝗄}$ immediately after ${\ell }_{𝖽𝗄}$.

#§ 3.2.1 ‘Note Plaintexts and Memo Fields’

Replace the paragraph

Define $𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾{𝗌}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝗁𝖾𝗂𝗀𝗁𝗍,𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇)=$ $\{\begin{array}{cc}\{\mathrm{𝟶}𝚡\mathrm{𝟶𝟷}\},& \text{𝗂𝖿 }𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍\\ \{\mathrm{𝟶}𝚡\mathrm{𝟶𝟷},\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\},& \text{𝗂𝖿 }𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍\le 𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽\\ \{\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\},& \text{𝗈𝗍𝗁𝖾𝗋𝗐𝗂𝗌𝖾.}\end{array}$

with

Let $\text{𝑝𝑜𝑜𝑙}⦂\{\text{𝑆𝑎𝑝𝑙𝑖𝑛𝑔𝑃𝑜𝑜𝑙},\text{𝑂𝑟𝑐ℎ𝑎𝑟𝑑𝑃𝑜𝑜𝑙},\text{𝐼𝑟𝑜𝑛𝑤𝑜𝑜𝑑𝑃𝑜𝑜𝑙}\}$ be the chain value pool of the note.

Define ${𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌}^{\text{𝑝𝑜𝑜𝑙}}(𝗁𝖾𝗂𝗀𝗁𝗍,𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇)=$ $\{\begin{array}{cc}\{\mathrm{𝟶}𝚡\mathrm{𝟶𝟷}\},& \text{𝗂𝖿 }𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍\\ \{\mathrm{𝟶}𝚡\mathrm{𝟶𝟷},\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\},& \text{𝗂𝖿 }𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍\le 𝗁𝖾𝗂𝗀𝗁𝗍<𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽\\ \{\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\},& \text{𝗂𝖿 }𝖢𝖺𝗇𝗈𝗉𝗒𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍+𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽\le 𝗁𝖾𝗂𝗀𝗁𝗍\text{ 𝖺𝗇𝖽 }\text{𝑝𝑜𝑜𝑙}\ne \text{𝐼𝑟𝑜𝑛𝑤𝑜𝑜𝑑𝑃𝑜𝑜𝑙}\\ \{\mathrm{𝟶}𝚡\mathrm{𝟶𝟹}\},& \text{𝗈𝗍𝗁𝖾𝗋𝗐𝗂𝗌𝖾.}\end{array}$

In the non-normative note:

Since $𝖮𝗋𝖼𝗁𝖺𝗋𝖽$ was introduced after the end of the $𝖹𝖨𝖯\mathrm{𝟤𝟣𝟤}𝖦𝗋𝖺𝖼𝖾𝖯𝖾𝗋𝗂𝗈𝖽$, note plaintexts for Orchard-pool notes MUST have $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ge \mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$.

replace "$\ge \mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$" with "$=\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}$".

Add the non-normative notes:

• Note plaintexts for Ironwood-pool notes MUST have $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ge \mathrm{𝟶}𝚡\mathrm{𝟶𝟹}$.
• It is important that ${𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌}^{\text{𝑂𝑟𝑐ℎ𝑎𝑟𝑑𝑃𝑜𝑜𝑙}}(\cdot ,\cdot )$ and ${𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌}^{\text{𝐼𝑟𝑜𝑛𝑤𝑜𝑜𝑑𝑃𝑜𝑜𝑙}}(\cdot ,\cdot )$ remain disjoint for any $𝗁𝖾𝗂𝗀𝗁𝗍$ and $𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇$.

Replace the non-normative note:

• It is intentional that the definition of $𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌$ does not currently depend on $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅$ or $𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇$. It might do so in future.

with

• It is intentional that the definition of $𝖺𝗅𝗅𝗈𝗐𝖾𝖽𝖫𝖾𝖺𝖽𝖡𝗒𝗍𝖾𝗌$ does not currently depend on $𝗍𝗑𝖵𝖾𝗋𝗌𝗂𝗈𝗇$. It might do so in future.

#§ 4.1.2 ‘Pseudo Random Functions’

In the list of places where $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$ is used:

Replace

• [NU5 onward] in § 4.2.3 ‘Orchard Key Components’ ¹⁹, with inputs $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟼}]$, $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟽}]$, $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟾}]$, and with first byte $\mathrm{𝟶}𝚡\mathrm{𝟾𝟸}$;
• in the processes of sending (§ 4.7.2 ‘Sending Notes (Sapling)’ ²⁰ and § 4.7.3 ‘Sending Notes (Orchard)’ ²¹) and of receiving (§ 4.20 ‘In-band secret distribution (Sapling and Orchard)’ ²²) notes, for Sapling with inputs $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟺}]$ and $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟻}]$, and for Orchard $[t]||\underline{\text{ρ}}$ with $t\in \{\mathrm{𝟶}𝚡\mathrm{𝟶𝟻},\mathrm{𝟶}𝚡\mathrm{𝟶𝟺},\mathrm{𝟶}𝚡\mathrm{𝟶𝟿}\}$;

with

• [NU5 onward] in § 4.2.3 ‘Orchard Key Components’ ¹⁹, with inputs $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟼}]$, $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟽}]$, $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟾}]$, and with first byte in $\{\mathrm{𝟶}𝚡\mathrm{𝟶}𝙲,\mathrm{𝟶}𝚡\mathrm{𝟶}𝙳,\mathrm{𝟶}𝚡\mathrm{𝟾𝟸}\}$ ($\mathrm{𝟶}𝚡\mathrm{𝟶}𝙲$ and $\mathrm{𝟶}𝚡\mathrm{𝟶}𝙳$ are also specified in [ZIP 2005]);
• in the processes of sending (§ 4.7.2 ‘Sending Notes (Sapling)’ ²⁰ and § 4.7.3 ‘Sending Notes (Orchard)’ ²¹) and of receiving (§ 4.20 ‘In-band secret distribution (Sapling and Orchard)’ ²²) notes, for Sapling with inputs $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟺}]$ and $[\mathrm{𝟶}𝚡\mathrm{𝟶𝟻}]$, and for Orchard with first byte in $\{\mathrm{𝟶}𝚡\mathrm{𝟶𝟻},\mathrm{𝟶}𝚡\mathrm{𝟶𝟺},\mathrm{𝟶}𝚡\mathrm{𝟶𝟿},\mathrm{𝟶}𝚡\mathrm{𝟶}𝙱\}$ ($\mathrm{𝟶}𝚡\mathrm{𝟶}𝙱$ is also specified in [ZIP 2005]);

Add

• in [ZIP 2005], with first byte in $\{\mathrm{𝟶}𝚡\mathrm{𝟶}𝙱,\mathrm{𝟶}𝚡\mathrm{𝟶}𝙲,\mathrm{𝟶}𝚡\mathrm{𝟶}𝙳\}$ ($\mathrm{𝟶}𝚡\mathrm{𝟶}𝙰$ is reserved by this ZIP for use by split notes ²³).

#§ 4.2.3 ‘Orchard Key Components’

Add ${\ell }_{𝗊𝗌𝗄}$ and ${\ell }_{𝗊𝗄}$ to the constants obtained from § 5.3 ‘Constants’ ²⁴.

Replace from "From this spending key" up to and including the line "let $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})$" in the algorithm with:

Under normal circumstances, the Spend authorizing key $𝖺𝗌𝗄⦂{𝔽}_{r_{\mathbb{P}}}^{\ast }$ is derived directly from $𝗌𝗄$. However, this might not be the case for protocols that require distributed generation of shares of $𝖺𝗌𝗄$, such as FROST's Distributed Key Generation ²⁵ (see [ZIP 2005, Usage with Frost] for further discussion). To support this we define an alternative derivation method using an additional "quantum spending key", $𝗊𝗌𝗄$, and "quantum intermediate key", $𝗊𝗄$.

There can also be advantages to not deriving $𝖺𝗌𝗄$ directly from $𝗌𝗄$ for hardware wallets, in order to separate the authority to make proofs for the Recovery Protocol from the spend authorization key that is kept on the device (see [ZIP 2005, Usage with hardware wallets]). The derivation from $𝗊𝗌𝗄$ can also be used in that case.

Let $𝗎𝗌𝖾\_𝗊𝗌𝗄⦂𝔹$ be a flag indicating whether $𝗊𝗌𝗄$ and $𝗊𝗄$ are generated and used in the derivation of $𝗋𝗂𝗏𝗄$. (In cases where it is desired for the generation of key components to match versions of this specification prior to 2026.8.0, $𝗎𝗌𝖾\_𝗊𝗌𝗄$ needs to be set to false.)

Define:

• ${𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟼}]))$
• ${𝖧}^{𝗇𝗄}(𝗌𝗄)=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟽}]))$
• ${𝖧}^{𝗋𝗂𝗏𝗄}(𝗌𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟾}]))$
• ${𝖧}^{𝗊𝗌𝗄}(𝗌𝗄)={𝗍𝗋𝗎𝗇𝖼𝖺𝗍𝖾}_{32}(𝖯𝖱{𝖥}_{𝗌𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶}𝙲]))$
• ${𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)=𝖡𝖫𝖠𝖪𝖤\mathrm{𝟥.}𝖽𝖾𝗋𝗂𝗏𝖾\_𝗄𝖾𝗒(\text{“𝚉𝚌𝚊𝚜𝚑 𝚉𝙸𝙿 𝟸𝟶𝟶𝟻 𝚚𝚔-𝚍𝚎𝚛𝚒𝚟𝚊𝚝𝚒𝚘𝚗 𝚟𝟷”},𝗊𝗌𝗄,32)$ ²⁶
• ${𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}\left(𝖯𝖱{𝖥}_{𝗊𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}\right([\mathrm{𝟶}𝚡\mathrm{𝟶}𝙳]||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗄)||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗄)\left)\right)$.

$𝖺𝗌𝗄⦂{𝔽}_{r_{\mathbb{P}}}^{\ast }$, the Spend validating key $𝖺𝗄⦂\{1..q_{\mathbb{P}}-1\}$, the nullifier deriving key $𝗇𝗄⦂{𝔽}_{q_{\mathbb{P}}}$, the optional quantum spending key $𝗊𝗌𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗌𝗄}/8]}\cup \{\perp \}$ and quantum intermediate key $𝗊𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗄}/8]}\cup \{\perp \}$ the $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ randomness $𝗋𝗂𝗏𝗄⦂{𝔽}_{r_{\mathbb{P}}}$, the diversifier key $𝖽𝗄⦂{𝔹}^{𝕐[{\ell }_{𝖽𝗄}/8]}$, the $𝖪{𝖠}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ private key $𝗂𝗏𝗄⦂\{1..q_{\mathbb{P}}-1\}$, the outgoing viewing key $𝗈𝗏𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗈𝗏𝗄}/8]}$, and corresponding “internal” keys MUST be derived as follows:

$$ let $𝗇𝗄={𝖧}^{𝗇𝗄}(𝗌𝗄)$
$$ if $𝗎𝗌𝖾\_𝗊𝗌𝗄$:
$$ obtain a $𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ public key ${𝖺𝗄}^{\mathbb{P}}⦂{\mathbb{P}}^{\ast }$ by any suitably secure
$$ method that ensures the last bit of ${𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})$ is $0$ (see below).
$$ let $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})$
$$ let $𝗊𝗌𝗄={𝖧}^{𝗊𝗌𝗄}(𝗌𝗄)$
$$ let $𝗊𝗄={𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)$
$$ let $𝗋𝗂𝗏𝗄={𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)$
$$ else:
$$ let mutable $𝖺𝗌𝗄\leftarrow {𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)$
$$ if $𝖺𝗌𝗄=0$, discard this key and repeat with a new $𝗌𝗄$.
$$ let ${𝖺𝗄}_{\mathbb{P}}=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖺𝗌𝗄)$
$$ if the last bit (that is, the $\tilde{y}$ bit) of ${𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝖺𝗄}_{\mathbb{P}})$ is $1$:
$$ set $𝖺𝗌𝗄\leftarrow -𝖺𝗌𝗄$

$$ let $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}_{\mathbb{P}})$
$$ let $𝗊𝗌𝗄=𝗊𝗄=\perp$ (there are no quantum spending/intermediate keys in this case)
$$ let $𝗋𝗂𝗏𝗄={𝖧}^{𝗋𝗂𝗏𝗄}(𝗌𝗄)$

Add before "As explained in § 3.1":

When $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is true, possible methods of generating ${𝖺𝗄}^{\mathbb{P}}$ include direct generation of an Orchard-protocol Spend authorizing key $𝖺𝗌𝗄⦂{𝔽}_{r_{\mathbb{P}}}^{\ast }$ followed by ${𝖺𝗄}^{\mathbb{P}}=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖺𝗌𝗄)$, or FROST distributed key generation ²⁵ in which the corresponding spend-authorization material is $t$-of-$n$ shared among the participants.

Add the following notes:

• If $𝖺𝗌𝗄$, $𝖺𝗄$, $𝗇𝗄$, $𝗋𝗂𝗏𝗄$, and $𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅$ are not generated as specified in this section, then it may not be possible to recover the resulting notes as specified in [ZIP 2005] in the event that attacks using quantum computers become practical. In addition, to recover notes it is necessary to retain, or be able to rederive $𝗌𝗄$, and also to know whether $𝗎𝗌𝖾\_𝗊𝗌𝗄$ was used to derive the $𝗂𝗏𝗄$ and addresses. When FROST is being used, it is also necessary to retain the group verifying key $𝖺𝗄$ and (collectively among the signers) the key material needed to make spend authorization signatures that can be verified using $𝖺𝗄$.

  See [ZIP 2005, Key storage options and analysis] for further discussion of storage requirements for $𝗌𝗄$ and $𝗊𝗌𝗄$.

#§ 4.7.2 ‘Sending Notes (Sapling)’

Add after the definition of $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$:

Define $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾)=\{\begin{array}{cc}{𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(𝗋𝗌𝖾𝖾𝖽),& \text{𝗂𝖿 }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟷}\\ 𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟺}])),& \text{𝗂𝖿 }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\end{array}$

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\_)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟻}]))$.

(${𝖧}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ intentionally takes an argument that is unused.)

Replace the lines deriving $𝗋𝖼𝗆$ and $𝖾𝗌𝗄$ with

Derive $𝗋𝖼𝗆=𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾)$

Derive $𝖾𝗌𝗄={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(\perp )$

#§ 4.7.3 ‘Sending Notes (Orchard)’

Add before "For each Action description":

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ})=$ $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆))$

where $𝗉𝗋𝖾\_𝗋𝖼𝗆=[\mathrm{𝟶}𝚡\mathrm{𝟶}𝙱]||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗀{\star }_{𝖽})||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗉𝗄{\star }_{𝖽})||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{64}(𝗏)||\underline{\text{ρ}}||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(\text{ψ})$.

Define $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ})=\{\begin{array}{cc}𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟻}]||\underline{\text{ρ}})),& \text{𝗂𝖿 }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟸}\\ {𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}),& \text{𝗂𝖿 }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟹}\end{array}$

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟺}]||\underline{\text{ρ}}))$.

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟿}]||\underline{\text{ρ}}))$.

The first-byte domain separator $\mathrm{𝟶}𝚡\mathrm{𝟶}𝙰$ for $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$ is reserved by this ZIP for use by split notes in ZIP 226 ²³.

Insert before the derivation of $𝖾𝗌𝗄$:

Let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, and $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})$.

and use these in the inputs to $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

Replace the lines deriving $𝖾𝗌𝗄$, $𝗋𝖼𝗆$, and $\text{ψ}$ with

Derive $𝖾𝗌𝗄={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})$

Derive $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})$

Derive $𝗋𝖼𝗆=𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ})$

(The order of derivation has to be changed because the inputs to $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼𝗆$ include $\text{ψ}$.)

#§ 4.8.2 ‘Dummy Notes (Sapling)’

Add

Let $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in § 4.7.2 ‘Sending Notes (Sapling)’.

Replace the line deriving $𝗋𝖼𝗆$ with

Derive $𝗋𝖼𝗆=𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾)$

#§ 4.8.3 ‘Dummy Notes (Orchard)’

Insert before "The spend-related fields ...":

Let $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and ${𝖧}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ be as defined in § 4.7.3 ‘Sending Notes (Orchard)’.

Replace the lines deriving $𝗋𝖼𝗆$ and $\text{ψ}$ with

Let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, and $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})$.

Derive $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})$

Derive $𝗋𝖼𝗆=𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ})$

and use $𝗀{\star }_{𝖽}$, $𝗉𝗄{\star }_{𝖽}$, in the inputs to $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

(The order of derivation has to be changed because the inputs to $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼𝗆$ include $\text{ψ}$.)

The choice of $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$, as specified in § 3.2.1, is identical between dummy and non-dummy notes.

#§ 4.20.2 and § 4.20.3 ‘Decryption using an Incoming/Full Viewing Key (Sapling and Orchard)’

For both § 4.20.2 and § 4.20.3, add before the decryption procedure:

Let $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅$ be $𝖲𝖺𝗉𝗅𝗂𝗇𝗀$ for a Sapling-pool note, or $𝖮𝗋𝖼𝗁𝖺𝗋𝖽$ for an Orchard-pool or Ironwood-pool note.

Let $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ and ${𝖧}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ be as defined in § 4.7.2 ‘Sending Notes (Sapling)’.

Let $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, ${𝖧}^{𝖾𝗌𝗄,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, and ${𝖧}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ be as defined in § 4.7.3 ‘Sending Notes (Orchard)’.

For § 4.20.3, replace

$$ if $𝖾𝗌𝗄\ge r_{𝔾}$ or $𝗉{𝗄}_{𝖽}=\perp$, return $\perp$

with

$$ if $𝖾𝗌𝗄\ge r_{𝔾}$ or $𝗉{𝗄}_{𝖽}=\perp$ or (for Sapling) $𝗉{𝗄}_{𝖽}\in ̸{𝕁}^{(r)\ast }$ (see note below), return $\perp$

and in the note containing "However, this is technically redundant with the later check that returns $\perp$ if $𝗉{𝗄}_{𝖽}\in ̸{𝕁}^{(r)\ast }$", delete the word "later".

For both § 4.20.2 and § 4.20.3, replace

$$ for Sapling, let $𝗉𝗋𝖾\_𝗋𝖼𝗆=[4]$ and $𝗉𝗋𝖾\_𝖾𝗌𝗄=[5]$
$$ for Orchard, let $\underline{\text{ρ}}={𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇{𝖿}^{𝗈𝗅𝖽}$ from the same Action description $)$, $𝗉𝗋𝖾\_𝗋𝖼𝗆=[5]||\underline{\text{ρ}}$, and $𝗉𝗋𝖾\_𝖾𝗌𝗄=[4]||\underline{\text{ρ}}$

with

$$ let $\underline{\text{ρ}}={𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇{𝖿}^{𝗈𝗅𝖽}\text{ 𝖿𝗋𝗈𝗆 𝗍𝗁𝖾 𝗌𝖺𝗆𝖾 𝖠𝖼𝗍𝗂𝗈𝗇 𝖽𝖾𝗌𝖼𝗋𝗂𝗉𝗍𝗂𝗈𝗇})$ if $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$, or $\perp$ otherwise

For § 4.20.2, replace

$$ let $𝗋𝖼𝗆=\{\begin{array}{cc}{𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(𝗋𝗌𝖾𝖾𝖽),& \text{𝗂𝖿 }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟷}\\ 𝖳𝗈𝖲𝖼𝖺𝗅𝖺𝗋(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆)),& \text{𝗈𝗍𝗁𝖾𝗋𝗐𝗂𝗌𝖾}\end{array}$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$, return $\perp$
$$ let ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$. if (for Sapling) ${𝗀}_{𝖽}=\perp$, return $\perp$
$$ [Canopy onward] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟷}$:
$$ $𝖾𝗌𝗄=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝖾𝗌𝗄))$
$$ if ${𝗋𝖾𝗉𝗋}_{𝔾}(𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖾𝗌𝗄,{𝗀}_{𝖽}))\ne 𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$, return $\perp$

$$ let $𝗉{𝗄}_{𝖽}=𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝗂𝗏𝗄,{𝗀}_{𝖽})$

with

$$ let ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$. if (for $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖲𝖺𝗉𝗅𝗂𝗇𝗀$) ${𝗀}_{𝖽}=\perp$, return $\perp$
$$ [Canopy onward] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟷}$:
$$ let $𝖾𝗌𝗄={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(\underline{\text{ρ}})$
$$ if ${𝗋𝖾𝗉𝗋}_{𝔾}(𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝖾𝗌𝗄,{𝗀}_{𝖽}))\ne 𝚎𝚙𝚑𝚎𝚖𝚎𝚛𝚊𝚕𝙺𝚎𝚢$, return $\perp$

$$ let $𝗉{𝗄}_{𝖽}=𝖪𝖠.𝖣𝖾𝗋𝗂𝗏𝖾𝖯𝗎𝖻𝗅𝗂𝖼(𝗂𝗏𝗄,{𝗀}_{𝖽})$
$$ if $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$, let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})$
$$ let $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})$ if $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$, or $\perp$ otherwise
$$ let $𝗋𝖼𝗆=\{\begin{array}{cc}𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾),& \text{𝗂𝖿 }𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖲𝖺𝗉𝗅𝗂𝗇𝗀\\ 𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}),& \text{𝗂𝖿 }𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽\end{array}$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$, return $\perp$

For § 4.20.2, also delete "where $\text{ψ}=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([9]||\underline{\text{ρ}}))$" from the line constructing the Orchard note tuple, since $\text{ψ}$ is now derived above.

The order of operations has to be altered because the derivation of $𝗋𝖼𝗆$ can depend on ${𝗀}_{𝖽}$ and $𝗉{𝗄}_{𝖽}$. The definitions of $𝗉𝗋𝖾\_𝗋𝖼𝗆$ and $𝗉𝗋𝖾\_𝖾𝗌𝗄$ are moved or inlined into § 4.7.2 ‘Sending Notes (Sapling)’ and § 4.7.3 ‘Sending Notes (Orchard)’ which define $𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}^{\{𝖲𝖺𝗉𝗅𝗂𝗇𝗀,𝖮𝗋𝖼𝗁𝖺𝗋𝖽\}}$ and ${𝖧}^{𝖾𝗌𝗄,\{𝖲𝖺𝗉𝗅𝗂𝗇𝗀,𝖮𝗋𝖼𝗁𝖺𝗋𝖽\}}$.

For § 4.20.3, replace

$$ [Canopy onward] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟷}$ and $𝖳𝗈𝖲𝖼𝖺𝗅𝖺𝗋(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝖾𝗌𝗄))\ne 𝖾𝗌𝗄$, return $\perp$

with

$$ [Canopy onward] if $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾\ne \mathrm{𝟶}𝚡\mathrm{𝟶𝟷}$ and ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗌𝗄,𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅}(\underline{\text{ρ}})\ne 𝖾𝗌𝗄$, return $\perp$

(This check is why ${𝖧}^{𝖾𝗌𝗄,𝖲𝖺𝗉𝗅𝗂𝗇𝗀}$ takes an argument at all.)

For § 4.20.3, replace

$$ let $𝗋𝖼𝗆=\{\begin{array}{cc}{𝖫𝖤𝖮𝖲\mathrm{𝟤}𝖨𝖯}_{256}(𝗋𝗌𝖾𝖾𝖽),& \text{𝗂𝖿 }𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟷}\\ 𝖳𝗈𝖲𝖼𝖺𝗅𝖺𝗋(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆)),& \text{𝗈𝗍𝗁𝖾𝗋𝗐𝗂𝗌𝖾}\end{array}$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$, return $\perp$
$$ let ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$. if (for Sapling) ${𝗀}_{𝖽}=\perp$ or $𝗉{𝗄}_{𝖽}\in ̸{𝕁}^{(r)\ast }$ (see note below), return $\perp$

with

$$ let ${𝗀}_{𝖽}=𝖣𝗂𝗏𝖾𝗋𝗌𝗂𝖿𝗒𝖧𝖺𝗌𝗁(𝖽)$. if (for Sapling) ${𝗀}_{𝖽}=\perp$, return $\perp$
$$ if $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$, let $𝗀{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽})$, $𝗉𝗄{\star }_{𝖽}={𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽})$
$$ let $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})$ if $𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽$, or $\perp$ otherwise
$$ let $𝗋𝖼𝗆=\{\begin{array}{cc}𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖲𝖺𝗉𝗅𝗂𝗇𝗀}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾),& \text{𝗂𝖿 }𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖲𝖺𝗉𝗅𝗂𝗇𝗀\\ 𝖣𝖾𝗋𝗂𝗏𝖾\_𝗋𝖼{𝗆}_{𝗋𝗌𝖾𝖾𝖽}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾,𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ}),& \text{𝗂𝖿 }𝗉𝗋𝗈𝗍𝗈𝖼𝗈𝗅=𝖮𝗋𝖼𝗁𝖺𝗋𝖽\end{array}$
$$ if $𝗋𝖼𝗆\ge r_{𝔾}$, return $\perp$

and delete "where $\text{ψ}=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([9]||\underline{\text{ρ}}))$".

#§ 5.3 ‘Constants’

Add the definitions, immediately after that of ${\ell }_{𝖽𝗄}$:

${\ell }_{𝗊𝗌𝗄}⦂\mathbb{N}:=256$
${\ell }_{𝗊𝗄}⦂\mathbb{N}:=256$

#Changes to ZIPs

#ZIP 32

Add a $\ast$ to the arrows leading to $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ in the diagram in section ‘Orchard internal key derivation’ ¹², with the following note:

$\ast$ The derivations of $𝖺𝗌𝗄$ and $𝗋𝗂𝗏𝗄$ shown in the diagram are not the only possibility. For further detail see § 4.2.3 ‘Orchard Key Components’ in the protocol specification. However, if $𝖺𝗌𝗄$, $𝖺𝗄$, $𝗇𝗄$, $𝗋𝗂𝗏𝗄$, and $𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅$ are not generated as in the diagram, then it may not be possible to recover the resulting notes as specified in [ZIP 2005] in the event that attacks using quantum computers become practical.

#ZIP 212

Add a note just after the Abstract heading:

This ZIP reflects the changes made to note encryption for the Canopy upgrade. It does not include subsequent changes in [ZIP 2005].

#Rationale

#Cryptographic background

This rationale is written primarily for cryptologists and protocol designers familiar with the Zcash shielded protocols. It is recommended to first read the slides of, and/or watch the following presentations:

• Understanding Zcash Security at Zcon3 ²⁷
• Post-Quantum Zcash at ZconVI ⁸

To understand the modelling of hash function and commitment security against a quantum adversary we also recommend ²⁸ and ²⁹.

#Proposed Recovery Protocol

The details of the protocol in this section are subject to change. This description is meant to facilitate analysis of whether the specification changes to be adopted now are likely to be sufficient to securely support a Recovery Protocol.

The proposed Recovery Protocol works, roughly speaking, by enforcing the derivations given in the [Flow diagram for the Orchard protocol], and we suggest having that diagram open in another window to refer to it.

#Proposed Recovery Statement

Import this definition from § 4.2.3 ‘Orchard Key Components’ ¹⁵:

Define ${𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}\left(𝖯𝖱{𝖥}_{𝗊𝗄}^{𝖾𝗑𝗉𝖺𝗇𝖽}\right([\mathrm{𝟶}𝚡\mathrm{𝟶}𝙳]||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗄)||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗄)\left)\right)$.

Import this definition from ZIP 32 ¹²:

${𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}\left(𝖯𝖱{𝖥}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝖾𝗑𝗉𝖺𝗇𝖽}\right([\mathrm{𝟶}𝚡\mathrm{𝟾𝟹}]||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝖺𝗄)||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(𝗇𝗄)\left)\right)$

Import these definitions from § 4.7.3 ‘Sending Notes (Orchard)’ ³⁰:

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ})=$ $𝖳𝗈𝖲𝖼𝖺𝗅𝖺{𝗋}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆))$

where $𝗉𝗋𝖾\_𝗋𝖼𝗆=[\mathrm{𝟶}𝚡\mathrm{𝟶}𝙱]||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗀{\star }_{𝖽})||{𝖫𝖤𝖡𝖲\mathrm{𝟤}𝖮𝖲𝖯}_{256}(𝗉𝗄{\star }_{𝖽})||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{64}(𝗏)||\underline{\text{ρ}}||{𝖨\mathrm{𝟤}𝖫𝖤𝖮𝖲𝖯}_{256}(\text{ψ})$.

Define ${𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})=𝖳𝗈𝖡𝖺𝗌{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}([\mathrm{𝟶}𝚡\mathrm{𝟶𝟿}]||\underline{\text{ρ}}))$.

Import this definition from § 5.4.7.1 ‘Spend Authorization Signature (Sapling and Orchard)’ ³¹:

Define ${𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}={𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁}^{\mathbb{P}}(\text{“𝚣.𝚌𝚊𝚜𝚑:𝙾𝚛𝚌𝚑𝚊𝚛𝚍”},\text{“𝙶”})$.

A valid instance of a Recovery Statement assures that given a primary input:

$\begin{array}{cc}(𝗋{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}& ⦂\{0..q_{\mathbb{P}}-1\},\\ 𝗋𝗄& ⦂𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖯𝗎𝖻𝗅𝗂𝖼),\\ 𝗇𝖿& ⦂{𝔽}_{q_{\mathbb{P}}},\\ 𝖲𝗂𝗀𝖧𝖺𝗌𝗁& ⦂𝖬𝖾𝗌𝗌𝖺𝗀𝖾𝖧𝖺𝗌𝗁)\end{array}$

the prover knows an auxiliary input:

$\begin{array}{cc}(𝗉𝖺𝗍𝗁& ⦂\{0..q_{\mathbb{P}}-1{\}}^{[𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}]},\\ 𝗉𝗈𝗌& ⦂\{0..2^{𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}-1\},\\ 𝝰& ⦂{𝔽}_{r_{\mathbb{P}}},\\ {𝖺𝗄}^{\mathbb{P}}& ⦂{\mathbb{P}}^{\ast },\\ 𝗇𝗄& ⦂{𝔽}_{q_{\mathbb{P}}},\\ 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍& ⦂{𝔽}_{r_{\mathbb{P}}},\\ 𝗋𝗂𝗏𝗄& ⦂{𝔽}_{r_{\mathbb{P}}},\\ (𝗊𝗄,{\sigma }_{𝗊𝗌𝗄})& ⦂({𝔹}^{𝕐[{\ell }_{𝗊𝗄}/8]}\times 𝖲𝗈{𝖪}^{𝗊𝗌𝗄}((𝗊𝗄),𝖲𝗂𝗀𝖧𝖺𝗌𝗁\left)\right)\cup \{(\perp ,\perp )\},\\ {\sigma }_{𝗌𝗄}& ⦂𝖲𝗈{𝖪}^{𝗌𝗄}(({𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍),𝖲𝗂𝗀𝖧𝖺𝗌𝗁)\cup \{\perp \},\\ 𝗋𝗌𝖾𝖾𝖽& ⦂{𝔹}^{𝕐[32]},\\ {𝗀}_{𝖽}& ⦂{\mathbb{P}}^{\ast },\\ 𝗏& ⦂\{0..2^{{\ell }_{𝗏𝖺𝗅𝗎𝖾}}-1\},\\ \text{ρ}& ⦂{𝔽}_{q_{\mathbb{P}}})\end{array}$

where

$\begin{array}{cc}𝖡𝗂𝗇𝖽𝖪𝖾𝗒{𝗌}^{𝗌𝗄}(𝗌𝗄,{𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍)=(& {𝖺𝗄}^{\mathbb{P}}=[{𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)]{𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}\\ & \wedge 𝗇𝗄={𝖧}^{𝗇𝗄}(𝗌𝗄)\\ & \wedge 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}(𝗌𝗄))\end{array}$

and

$\begin{array}{ccc}𝖲𝗈{𝖪}^{𝗊𝗌𝗄}.𝖲𝗍𝖺𝗍𝖾𝗆𝖾𝗇𝗍& =\{𝗊𝗌𝗄⦂{𝔹}^{𝕐[{\ell }_{𝗊𝗌𝗄}/8]}& |𝗊𝗄={𝖧}^{𝗊𝗄}(𝗊𝗌𝗄)\}\\ 𝖲𝗈{𝖪}^{𝗌𝗄}.𝖲𝗍𝖺𝗍𝖾𝗆𝖾𝗇𝗍& =\{𝗌𝗄⦂{𝔹}^{[{\ell }_{𝗌𝗄}]}& |𝖡𝗂𝗇𝖽𝖪𝖾𝗒{𝗌}^{𝗌𝗄}(𝗌𝗄,{𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍)\}\end{array}$

such that the following conditions hold:

$\begin{array}{c}\{𝗋𝗄=𝖲𝗉𝖾𝗇𝖽𝖠𝗎𝗍𝗁𝖲𝗂{𝗀}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖱𝖺𝗇𝖽𝗈𝗆𝗂𝗓𝖾𝖯𝗎𝖻𝗅𝗂𝖼(\alpha ,{𝖺𝗄}^{\mathbb{P}})\phantom{(}\\ \wedge 𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})\phantom{(}\\ \wedge ((𝗊𝗄,{\sigma }_{𝗊𝗌𝗄})=(\perp ,\perp ))\ne ({\sigma }_{𝗌𝗄}=\perp )\phantom{(}\\ \wedge (𝗊𝗄,{\sigma }_{𝗊𝗌𝗄})\ne (\perp ,\perp )\Rightarrow \left(𝖲𝗈{𝖪}^{𝗊𝗌𝗄}.𝖵𝖺𝗅𝗂𝖽𝖺𝗍𝖾\right((𝗊𝗄),𝖲𝗂𝗀𝖧𝖺𝗌𝗁,{\sigma }_{𝗊𝗌𝗄})\wedge 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄))\phantom{(}\\ \wedge {\sigma }_{𝗌𝗄}\ne \perp \Rightarrow 𝖲𝗈{𝖪}^{𝗌𝗄}.𝖵𝖺𝗅𝗂𝖽𝖺𝗍𝖾(({𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍),𝖲𝗂𝗀𝖧𝖺𝗌𝗁,{\sigma }_{𝗌𝗄})\phantom{(}\\ \wedge 𝗋𝗂𝗏𝗄\in \{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,{𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)\}\phantom{(}\\ \wedge \text{let }𝗂𝗏𝗄=𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄}^{𝗂𝗏𝗄}(𝖺𝗄,𝗇𝗄)\phantom{(}\\ \wedge 𝗂𝗏𝗄\in ̸\{0,\perp \}\phantom{(}\\ \wedge \text{let }𝗉{𝗄}_{𝖽}=[𝗂𝗏𝗄]{𝗀}_{𝖽}\phantom{(}\\ \wedge \text{let }\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ},𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\underline{\text{ρ}})\phantom{(}\\ \wedge \text{let }𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋=({𝗋𝖾𝗉𝗋}_{\mathbb{P}}({𝗀}_{𝖽}),{𝗋𝖾𝗉𝗋}_{\mathbb{P}}(𝗉{𝗄}_{𝖽}),𝗏,\underline{\text{ρ}},\text{ψ})\phantom{(}\\ \wedge \text{let }𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆,𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(\mathrm{𝟶}𝚡\mathrm{𝟶𝟹},𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)\phantom{(}\\ \wedge \text{let }𝖼𝗆=𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)\phantom{(}\\ \wedge 𝖼𝗆\ne \perp \phantom{(}\\ \wedge \text{let }{𝖼𝗆}_x={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(𝖼𝗆)\phantom{(}\\ \wedge \text{let }𝗅𝖾𝖺𝖿=𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧({𝖼𝗆}_x,\text{ρ})\phantom{(}\\ \wedge 𝗉𝖺𝗍𝗁\text{ 𝗂𝗌 𝖺 𝗉𝖺𝗍𝗁 𝗍𝗈 }𝗅𝖾𝖺𝖿\text{ 𝗂𝗇 𝗍𝗁𝖾 𝗋𝖾𝗁𝖺𝗌𝗁𝖾𝖽 𝖼𝗈𝗆𝗆𝗂𝗍𝗆𝖾𝗇𝗍 𝗍𝗋𝖾𝖾}\phantom{(}\\ \wedge 𝗇𝖿=𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾{𝗋}_{𝗇𝗄}(\text{ρ},\text{ψ},𝖼𝗆)\phantom{(}\\ \}\end{array}$

and $𝗇𝖿$ is the revealed nullifier.

(We don't need to check the derivation of ${𝗀}_{𝖽}$ from $𝖽$.)

#Cost

Note that in the "$𝗎𝗌𝖾\_𝗊𝗌𝗄$" case, one BLAKE2b compression is required to compute $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$ (provided ${\ell }_{𝗊𝗄}\le 504$ bits, so that the input $𝗊𝗄||[\mathrm{𝟶}𝚡\mathrm{𝟶}𝙳]||𝖺𝗄||𝗇𝗄$ fits in a single 128-byte BLAKE2b block), and in the "not $𝗎𝗌𝖾\_𝗊𝗌𝗄$" case, three BLAKE2b compressions in total are required to compute ${𝖧}^{𝖺𝗌𝗄}$, ${𝖧}^{𝗇𝗄}$, and ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$. Since these cases are mutually exclusive, it is possible to multiplex the same three compression function instances. So, supporting "$𝗎𝗌𝖾\_𝗊𝗌𝗄$" in addition to "not $𝗎𝗌𝖾\_𝗊𝗌𝗄$" costs very little extra.

All of the operations below need to be implemented with complete additions, even if they are incomplete in the current Orchard[ZSA] statement/circuit.

In $𝖲𝗈{𝖪}^{𝗌𝗄}$ and the main circuit:

• 7 BLAKE2b-512 compressions:
  • 3 multiplexed between ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$ when $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is true (1 compression), and ${𝖧}^{𝖺𝗌𝗄}$ + ${𝖧}^{𝗇𝗄}$ + ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$ when $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is false (3 compressions)
  • 1 to compute ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$
  • 1 to compute ${𝖧}^{\text{ψ}}$
  • 2 to compute ${𝖧}^{𝗋𝖼𝗆}$
• 1 use of $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ ($𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖲𝗁𝗈𝗋𝗍𝖢𝗈𝗆𝗆𝗂𝗍$)
• 1 use of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$ ($𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖢𝗈𝗆𝗆𝗂𝗍$)
• 1 full-width fixed-base Pallas scalar multiplication, $[𝖺𝗌𝗄]{𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$
• 1 full-width variable-base Pallas scalar multiplication, $[𝗂𝗏𝗄]{𝗀}_{𝖽}$
• 1 Merkle tree path check
• 1 additional use of $𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧$ to compute $𝗅𝖾𝖺𝖿$.

In $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$:

• 1 BLAKE3 compression for ${𝖧}^{𝗊𝗄}$ (with the $𝖽𝖾𝗋𝗂𝗏𝖾\_𝗄𝖾𝗒$ context key precomputed as a constant)

plus, potentially, linking commitments between the circuits.

The expensive parts of this are the 7 BLAKE2b compressions.

#Security analysis

Let us consider the security of the Orchard protocol against a discrete-logarithm-breaking adversary — which by definition includes quantum adversaries. Similar attacks apply to the Sapling protocol.

Suppose that the proof system has been replaced by one that is post-quantum knowledge-sound.

#Repairing the note commitment Merkle tree

$𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧$ is instantiated using $𝖲𝗂𝗇𝗌𝗂𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁$ ³². Its collision resistance depends on the Discrete Logarithm Relation Problem on the Pallas curve ³³, and so it is not post-quantum collision-resistant or collapsing. However, because the note commitment tree is public, it is possible to re-hash all of its leaves to construct a new Merkle tree using a collapsing hash function. Suppose this has been done.

The post-quantum security of Merkle trees —considered as position-binding vector commitments which is the property required by Zcash ²⁷— is proven under reasonable assumptions in ³⁴, ³⁵, and ³⁶.

Note: when we rehash the commitment tree, we could include both $\text{ρ}$ and ${𝖼𝗆}_x$ for each note (i.e. what is currently the leaf layer becomes $𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧(\text{ρ},{𝖼𝗆}_x)$ where $𝖬𝖾𝗋𝗄𝗅𝖾𝖢𝖱𝖧$ is collapsing). This change might not be necessary; it just removes potential complications due to duplicate commitments for the same note.

#Attacks against binding of note commitments

We still face the problem that $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$ is not binding against a discrete-logarithm-breaking adversary: given the discrete logarithm relations between bases, we can easily write a linear equation in the scalar field with multiple solutions of the inputs for a given commitment.

This allows an adversary to find two distinct notes corresponding to openings of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$ on the same commitment. They create one note as an output and spend the other note — which may have a greater value, or a value in a different ZSA asset, breaking the Balance property.

#Repairing note commitments

We prefer to fix this without changing $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$ itself. Instead we change how $𝗋𝖼𝗆$ is computed to be a hash of $𝗋𝗌𝖾𝖾𝖽$ and $𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋=(𝗀{\star }_{𝖽},𝗉𝗄{\star }_{𝖽},𝗏,\underline{\text{ρ}},\text{ψ})$, as detailed in the [Specification] section. Specifically, when $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾=\mathrm{𝟶}𝚡\mathrm{𝟶𝟹}$ we have:

$𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)=𝖳𝗈𝖲𝖼𝖺𝗅𝖺𝗋(𝖯𝖱{𝖥}_{𝗋𝗌𝖾𝖾𝖽}^{𝖾𝗑𝗉𝖺𝗇𝖽}(𝗉𝗋𝖾\_𝗋𝖼𝗆))$

$\text{where }𝗉𝗋𝖾\_𝗋𝖼𝗆=[\mathrm{𝟶}𝚡\mathrm{𝟶}𝙱]||𝖾𝗇𝖼𝗈𝖽𝖾(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$

#Informal security argument for binding of note commitments

For the formal versions of these arguments and their adaptation to the post-quantum setting, see the key-binding and Spendability theorems below, and the Adaptation to the quantum setting section.

We can view the output of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}$ for $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾=(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ as the point addition of a randomization term $[{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ$, and some other function of $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾$.

Without loss of generality, we can write that function as $[𝖿(𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾)]ℛ$, by expanding each of the Sinemilla bases ${𝒞}_j=𝒬(D)\text{ 𝗈𝗋 }𝒮(j)$ used by $𝖧𝖺𝗌𝗁𝖳𝗈𝖲𝗂𝗇𝗌𝗂𝗆𝗂𝗅𝗅𝖺𝖯𝗈𝗂𝗇𝗍$ as ${𝒞}_j=[c_j]ℛ$ for some $c_j$. That is, the note commitment for $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾$ is $[{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+𝖿(𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾)]ℛ\text{.}$

We will model ${𝖧}^{𝗋𝖼𝗆}$ as a random oracle independent of $𝖿$ with uniform output on ${𝔽}_{r_{\mathbb{P}}}$. This is reasonable because ${𝖧}^{𝗋𝖼𝗆}$ cannot depend on any of the $c_j$, and in any case it is instantiated using BLAKE2b, a conventional hash function not related to the Pallas curve.

The fact that $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$ has $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ}}(\text{ρ})$ as an input does not affect the analysis provided that ${𝖧}^{𝗋𝖼𝗆}$ and ${𝖧}^{\text{ψ}}$ can be treated as independent. In practice both are defined in terms of $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$, but with strict domain separation, and so the assumption of independence is reasonable as long as BLAKE2b-512 can be modelled as a random oracle. Note that since the input to ${𝖧}^{𝗋𝖼𝗆}$ needs more than one BLAKE2b input block, we require that a HAIFA sponge can be modelled as a random oracle which is justified by ³⁷. It is possible that there could be better-than-generic quantum attacks against BLAKE2b-512, but none have been published to our knowledge. In practice, we consider it reasonable to assume that BLAKE2b-512 has the properties needed for ${𝖧}^{𝗋𝖼𝗆}$ to be collapsing. Taking the 512-bit BLAKE2b output modulo $r_{\mathbb{P}}\approx 2^{254}$ cannot introduce a problem.

For each ${𝖧}^{𝗋𝖼𝗆}$ oracle query the adversary chooses $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾=(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ and obtains a "random" $𝗋𝖼𝗆={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$.

We have ${𝖼𝗆}_x={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}([{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+𝖿(𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾)]ℛ)$.

Over all Pallas curve points $P$, the number of outputs of ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(P)$ is $({𝔽}_{r_{\mathbb{P}}}+1)/2\approx 2^{253}$ — one for each possible $x$-coordinate of Pallas curve points, plus one for the zero point ${𝒪}_{\mathbb{P}}$ which is mapped to $0$.

Only one point maps to $0$, as opposed to two points mapping to every other possible output of ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}$, but that has negligible effect.

There are two values of $𝖼𝗆$ that match ${𝖼𝗆}_x$ in their $x$-coordinate. Because the output of $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}$ for $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾$ is of the form $𝖼𝗆=[𝖿(𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾)+𝗋𝖼𝗆]ℛ$, for any given note we have exactly two values of $𝗋𝖼𝗆$ that will pass the commitment check.

Suppose there are $N$ legitimate notes in the tree. The adversary is trying to find a note that will pass the commitment check without actually being a note in the tree. As argued above, the distribution of $𝗋𝖼𝗆$ is indistinguishable from uniform-random on ${𝔽}_{r_{\mathbb{P}}}$. The success probability for each attempt in a classical search is therefore $2N/r_{\mathbb{P}}$ where $r_{\mathbb{P}}$ is the order of the Pallas curve, and that is negligible because $N\le 2^{32}\ll r_{\mathbb{P}}$.

We're not finished yet because we also have to prove that the nullifier is computed deterministically for a given note.

All of the inputs to $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ are things we committed to in the protocol so far except $𝗇𝗄$. By the same argument used pre-quantumly, there is only one $𝗂𝗏𝗄$ for a given $({𝗀}_{𝖽},𝗉{𝗄}_{𝖽})$. So in order to just use the existing protocol for this part, we would need to prove that there is only one $𝗇𝗄$ (that is feasible to find) such that $𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄}^{𝗂𝗏𝗄}(𝖺𝗄,𝗇𝗄)=𝗂𝗏𝗄$. Unfortunately that's not true; $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ is instantiated by $𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖲𝗁𝗈𝗋𝗍𝖢𝗈𝗆𝗆𝗂𝗍$ which is not post-quantum binding.

There are two cases depending on which witness branch the adversary uses (they can choose to attack either, or both simultaneously):

• Case $𝗌𝗄\ne \perp$: The spender must prove knowledge of $𝗌𝗄$, and that $𝖺𝗄$, $𝗇𝗄$, and $𝗋𝗂𝗏𝗄$ are derived correctly from $𝗌𝗄$. This works because the derivations use post-quantum hashes (and $𝖺𝗌𝗄\mapsto 𝖺𝗄$ is deterministic).
  In particular, $𝗂𝗏𝗄$ is an essentially random function of $𝗌𝗄$, and so we expect that an adversary has no better attack than to search for values of $𝗌𝗄$ to find one that reproduces a given $𝗂𝗏𝗄$. Since $𝗂𝗏𝗄$ must be an $x$-coordinate of a Pallas curve point (see the note at the end of § 4.2.3 Orchard Key Components), it can take on $(r_{\mathbb{P}}-1)/2$ values. So if there are $T$ targets the success probability for each attempt in a classical search is $2T/(r_{\mathbb{P}}-1)$, which is negligible provided that $T\ll r_{\mathbb{P}}$.

• Case $𝗊𝗄\ne \perp$: This case is almost the same except that $𝗂𝗏𝗄$ is now an essentially random function of $(𝗇𝗄,𝖺𝗄,𝗊𝗄)$. The success probability in terms of $T$ is also the same as for the $𝗌𝗄\ne \perp$ case.

The above security argument means that provided we also check the uses of ${𝖧}^{𝗋𝖼𝗆}$ and ${𝖧}^{\text{ψ}}$ in the post-quantum Recovery Statement, Orchard-protocol note commitments can be considered binding on the note tuple $(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$.

Note that the argument associated with Theorem 5.4.4 in the protocol specification ("$𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁𝖳𝗈𝖯𝗈𝗂𝗇𝗍(\dots )=\perp$ yields a nontrivial discrete logarithm relation." and "Since by assumption it is hard to find a nontrivial discrete logarithm relation, we can argue that it is safe to use incomplete additions when computing Sinsemilla inside a circuit.") is not applicable when it is necessary to defend against a discrete-logarithm-breaking or quantum adversary. Therefore, the post-quantum Recovery Statement will need to use complete curve additions to implement Sinsemilla.

#Security argument for key binding

The security of the Orchard shielded protocol against several attacks depends on cryptographic keys being bound to a recoverable note's $𝗂𝗏𝗄$. Different Orchard-protocol properties need different components of the key witness pinned:

• Nullifier-binding (used by the Balance argument and by the Spendability argument below — the latter via the $𝗇𝖿$-pinning lemma): $𝗇𝗄$ uniquely determined by $𝗂𝗏𝗄$.
• Spend Authorization: $𝖺𝗄$ (up to $y$-sign of ${𝖺𝗄}^{\mathbb{P}}$) and $𝗊𝗄$ uniquely determined by $𝗂𝗏𝗄$. This includes uniquely determining the tag of $𝗊𝗄\_𝗈𝗋\_𝗌𝗄$, i.e. which of the $𝖰𝖪$ and $𝖲𝖪$ branches produced the $𝗂𝗏𝗄$.

The determination of $𝗊𝗄$ must fix the branch itself, not merely the value of $𝗊𝗄$ within the $𝖰𝖪$ branch. Suppose an address generated with $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$ —whose owner authorizes recovery by proving knowledge of $𝗊𝗌𝗄$ via $𝖲𝗈{𝖪}^{𝗊𝗌𝗄}$— shared its $𝗂𝗏𝗄$ with an $𝗌𝗄$-branch witness. An adversary holding a suitable $𝗌𝗄$ could then recover the note through the $𝗌𝗄$-branch of the Recovery Statement, authorizing the spend with $𝖲𝗈{𝖪}^{𝗌𝗄}$ and never demonstrating knowledge of $𝗊𝗌𝗄$. Against a discrete-logarithm-breaking adversary —for which the accompanying RedDSA signature over $𝖺𝗄$ gives no protection— this breaks Spend Authorization for such addresses. Ruling out these cross-branch collisions (both $𝗊𝗄$-values pinned, $\perp$ included) is therefore a requirement of the argument, not incidental strength.

The formal key-binding condition stated below covers all of these uniformly: a key-binding break is a pair of distinct witnesses sharing the same $𝗂𝗏𝗄$, where each witness carries the full key tuple — $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ plus whichever of $𝗊𝗄$ or $𝗌𝗄$ is in use. If key binding fails, the Balance, Spendability, and Spend Authorization arguments each lose their corresponding pinning step.

Relative to the situation with note commitments where it was reasonable to only obtain quantum recoverability for newly output Ironwood-pool notes, there is a complication. Addresses may be used over the long term and it may not be desirable to switch to new addresses, or to avoid funds being sent to old ones. Fortunately, the Orchard protocol specified each of $𝖺𝗄$, $𝗇𝗄$, and $𝗋𝗂𝗏𝗄$ to be derived from $𝗌𝗄$ via $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$, which is assumed collapsing. ($𝗋𝗂𝗏𝗄$ is derived differently for an "internal IVK", but that is also via $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$.)

Classically, the binding of $𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝗂𝗏𝗄}$ —instantiated via Sinsemilla— fails against a discrete-logarithm-breaking adversary, similarly to $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$. We use essentially the same fix as for $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍$, with the $𝗋𝗂𝗏𝗄$-derivation hashes playing the role of ${𝖧}^{𝗋𝖼𝗆}$. The Recovery Statement checks the derivation of $𝗋𝗂𝗏𝗄$:

The witness carries the branch as a tagged union $𝗊𝗄\_𝗈𝗋\_𝗌𝗄⦂𝖰𝖪\left({𝔹}^{𝕐[{\ell }_{𝗊𝗄}/8]}\right)|𝖲𝖪({𝔹}^{[{\ell }_{𝗌𝗄}]})$ —following the formalization's sum type— so exactly one branch is present per witness, by construction. This is equivalent to case-splitting by $𝗎𝗌𝖾\_𝗊𝗌𝗄$.

• In the $𝖰𝖪$ branch, $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)$.
• In the $𝖲𝖪$ branch, $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}(𝗌𝗄)$, with $𝖺𝗄$ and $𝗇𝗄$ also derived from $𝗌𝗄$ via ${𝖧}^{𝖺𝗌𝗄}$ and ${𝖧}^{𝗇𝗄}$.

In either case, $𝗋𝗂𝗏𝗄$ is then either $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$ directly (external IVK) or ${𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)$ (internal IVK). All of these hashes are modelled as independent random oracles for the key-binding argument.

As in the Recovery Statement, we have:

$\begin{array}{cc}𝖡𝗂𝗇𝖽𝖪𝖾𝗒{𝗌}^{𝗌𝗄}(𝗌𝗄,{𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍)=(& {𝖺𝗄}^{\mathbb{P}}=[{𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)]{𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}\\ & \wedge 𝗇𝗄={𝖧}^{𝗇𝗄}(𝗌𝗄)\\ & \wedge 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}(𝗌𝗄))\end{array}$

Let the key-binding condition on a witness $w=(𝗂𝗏𝗄,{𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,𝗋𝗂𝗏𝗄,𝗊𝗄\_𝗈𝗋\_𝗌𝗄)$ be:

$\begin{array}{c}\text{match }𝗊𝗄\_𝗈𝗋\_𝗌𝗄\text{ with }\{\begin{array}{cc}𝖰𝖪(𝗊𝗄)& \Rightarrow 𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍={𝖧}_{𝗊𝗄}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}(𝖺𝗄,𝗇𝗄)\\ 𝖲𝖪(𝗌𝗄)& \Rightarrow 𝖡𝗂𝗇𝖽𝖪𝖾𝗒{𝗌}^{𝗌𝗄}(𝗌𝗄,{𝖺𝗄}^{\mathbb{P}},𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍)\phantom{(}\end{array}\\ \wedge 𝗋𝗂𝗏𝗄\in \{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,{𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)\}\\ \wedge 𝗂𝗏𝗄=𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝗂𝗏𝗄}^{𝗂𝗏𝗄}(𝖺𝗄,𝗇𝗄)\\ \wedge 𝗂𝗏𝗄\in ̸\{0,\perp \}\end{array}$

where $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})$.

The predicate intentionally does not constrain the $y$-sign of ${𝖺𝗄}^{\mathbb{P}}$. This is consistent with the Orchard protocol's design choice to use $𝖺𝗄$ as a single ${𝔽}_{q_{\mathbb{P}}}$ element (the $x$-coordinate ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}({𝖺𝗄}^{\mathbb{P}})$), which avoids point-decompression in places that consume $𝖺𝗄$, in exchange for a factor-of-2 reduction in concrete binding security. Accordingly, the break event below identifies witnesses up to the $y$-sign of ${𝖺𝗄}^{\mathbb{P}}$.

The flags $𝗎𝗌𝖾\_𝗊𝗌𝗄$ and $𝗂𝗌\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅\_𝗋𝗂𝗏𝗄$ that appear in the protocol diagram do not appear in this witness — nor in the formal Recovery Statement above. Their roles are absorbed into the witness's structural form:

• $𝗎𝗌𝖾\_𝗊𝗌𝗄$ is encoded in the tag of $𝗊𝗄\_𝗈𝗋\_𝗌𝗄$: the witness carries exactly one of the two branches by construction (enforced by the tagged form, not by a $\perp$-exclusion constraint), and the branch-specific constraint applies to whichever is present.
• $𝗂𝗌\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅\_𝗋𝗂𝗏𝗄$ is encoded in $𝗋𝗂𝗏𝗄\in \{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,{𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)\}$: both $𝗋𝗂𝗏𝗄$ derivations are admitted simultaneously.

This formulation is strictly stronger than a flag-conditioned one: a key-binding break can have $w_1$ and $w_2$ in different branches across either flag (e.g., $w_1$ in the $𝖰𝖪$ branch and $w_2$ in the $𝖲𝖪$ branch, or $w_1$ with external $𝗋𝗂𝗏𝗄$ and $w_2$ with internal $𝗋𝗂𝗏𝗄$), provided both produce the same $𝗂𝗏𝗄$. A flag-based formulation would forbid only same-branch breaks. For the $𝗎𝗌𝖾\_𝗊𝗌𝗄$ flag this extra strength is required by Spend Authorization —forbidding the $𝗊𝗄$-versus-$𝗌𝗄$ cross-branch collision described above— and not merely incidental; for $𝗂𝗌\_𝗂𝗇𝗍𝖾𝗋𝗇𝖺𝗅\_𝗋𝗂𝗏𝗄$ it is additional robustness.

A key-binding break is a pair of witnesses $(w_1,w_2)$ with shared $𝗂𝗏𝗄$ satisfying the key-binding condition, whose $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄,𝗊𝗄\_𝗈𝗋\_𝗌𝗄)$ projections differ — i.e., $w_1$ and $w_2$ differ in some component other than the $y$-sign of ${𝖺𝗄}^{\mathbb{P}}$.

The random oracles used in the key-binding condition are ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$, ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$, ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$, ${𝖧}^{𝖺𝗌𝗄}$, and ${𝖧}^{𝗇𝗄}$.

Let ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$ be the probability, over $𝒜$'s randomness and at most $q_{𝗄𝖻}$ queries in total to these random oracles, that $𝒜$ outputs a key-binding break. Here $q_{𝗄𝖻}$ counts the derivation inputs of $𝒜$'s output witnesses among its queries — a convention that is without loss of generality, by the accounting normalization in the proof.

Theorem (key-binding, classical ROM). Let $𝒜$ be a classical adversary making at most $q_{𝗄𝖻}$ total queries to the random oracles used in the key-binding condition. Then ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})\le \frac{q_{𝗄𝖻}(q_{𝗄𝖻}-1)}{r_{\mathbb{P}}}$.

Proof sketch.

Algebraic setup. By § 5.4.1.10 “Sinsemilla commitments”,

$${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}(M^{\prime }+[𝗋𝗂𝗏𝗄]𝒮)\text{,}$$

where $𝒮$ is the rivk-randomization base $𝒮:={𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁}^{\mathbb{P}}(\text{“𝚣.𝚌𝚊𝚜𝚑:𝙾𝚛𝚌𝚑𝚊𝚛𝚍-𝙲𝚘𝚖𝚖𝚒𝚝𝙸𝚟𝚔-𝚛”},\text{“”})\text{,}$ and

$${𝖨\mathrm{𝟤}𝖫𝖤𝖡𝖲𝖯}_{{\ell }_{𝖻𝖺𝗌𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}(𝖺𝗄)\Vert {𝖨\mathrm{𝟤}𝖫𝖤𝖡𝖲𝖯}_{{\ell }_{𝖻𝖺𝗌𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}}(𝗇𝗄))\text{.}$$

By expanding the Sinsemilla bases used inside $𝖲𝗂𝗇𝗌𝖾𝗆𝗂𝗅𝗅𝖺𝖧𝖺𝗌𝗁𝖳𝗈𝖯𝗈𝗂𝗇𝗍$ as scalar multiples of $𝒮$, without loss of generality we have $M^{\prime }=[h(𝖺𝗄,𝗇𝗄)]𝒮$ for a Pedersen-like deterministic scalar hash $h$, so

$${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}([h(𝖺𝗄,𝗇𝗄)+𝗋𝗂𝗏𝗄]𝒮)\text{.}$$

Domain separation in the protocol's BLAKE2b instantiations ensures $h$ does not query ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$, ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$, ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$, ${𝖧}^{𝖺𝗌𝗄}$, or ${𝖧}^{𝗇𝗄}$: $h$ depends only on fixed Sinsemilla bases and on $(𝖺𝗄,𝗇𝗄)$.

By the same $y^2=Y(x)$ argument used in the Spendability proof (using § 5.4.9.7 for the ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}$-style $x$-coordinate convention), a key-binding break implies $h(𝖺𝗄,𝗇𝗄)+𝗋𝗂𝗏𝗄\equiv \pm (h({𝖺𝗄}^{\prime },{𝗇𝗄}^{\prime })+{𝗋𝗂𝗏𝗄}^{\prime })(\mathrm{mod}{r}_{\mathbb{P}})\text{.}$ Define $𝖦(w):=h(𝖺𝗄,𝗇𝗄)+𝗋𝗂𝗏𝗄(\mathrm{mod}{r}_{\mathbb{P}})$ for a witness $w$, and let $G_i:=𝖦(w_i)$ for $i\in \{1,2\}$. The break condition is $G_1\equiv \pm G_2(\mathrm{mod}{r}_{\mathbb{P}})$.

Final-random-oracle structure. For each witness $w_i$ satisfying the key-binding condition, ${𝗋𝗂𝗏𝗄}_i$ is the output of a final random oracle $O_i\in \{{𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍},{𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒},{𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}\}$ at a final input $x_i$, determined by the witness's branch and IVK choice:

• qk-branch, external IVK: $O_i={𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$, $x_i=({𝗊𝗄}_i,{𝖺𝗄}_i,{𝗇𝗄}_i)$.
• sk-branch, external IVK: $O_i={𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$, $x_i={𝗌𝗄}_i$.
• qk-branch, internal IVK: $O_i={𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$, $x_i=({𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}_i,{𝖺𝗄}_i,{𝗇𝗄}_i)$ where ${𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}_i={𝖧}_{𝗊{𝗄}_{𝗂}}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}({𝖺𝗄}_i,{𝗇𝗄}_i)$.
• sk-branch, internal IVK: $O_i={𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$, $x_i=({𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}_i,{𝖺𝗄}_i,{𝗇𝗄}_i)$ where ${𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}_i={𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}({𝗌𝗄}_i)$.

In each case $G_i=h({𝖺𝗄}_i,{𝗇𝗄}_i)+O_i(x_i)(\mathrm{mod}{r}_{\mathbb{P}})$, with the deterministic shift $h$ independent of $O_i$'s responses (by non-querying).

The shifted combined oracle. Treat the three rivk-derivation oracles (${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$, ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$, ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$) as a single combined oracle ${𝖧}^{\ast }$ on the disjoint union of their input domains. Each instance contributes outputs uniform on ${𝔽}_{r_{\mathbb{P}}}$, independently of the others, by domain separation. ${𝖧}^{𝖺𝗌𝗄}$ and ${𝖧}^{𝗇𝗄}$ are not part of ${𝖧}^{\ast }$: they enter only through the shifts below, and their output types differ.

For a combined input $x$, define the shift $s(x):=h(𝖺𝗄,𝗇𝗄)$, with $(𝖺𝗄,𝗇𝗄)$ read off the input: directly for ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$ and ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}$ inputs, and via $𝖺𝗄={𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}([{𝖧}^{𝖺𝗌𝗄}(𝗌𝗄)]{𝒢}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽})$, $𝗇𝗄={𝖧}^{𝗇𝗄}(𝗌𝗄)$ for an ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$ input $𝗌𝗄$. So $s$ is a function of the input and of the ${𝖧}^{𝖺𝗌𝗄}$/${𝖧}^{𝗇𝗄}$ oracles only; since $h$ is non-querying, $s$ never depends on the rivk-derivation responses. Define the shifted combined oracle ${𝖧}^s(x):=s(x)+{𝖧}^{\ast }(x)(\mathrm{mod}{r}_{\mathbb{P}})\text{.}$ For every witness satisfying the key-binding condition the derivation constraints give $G_i={𝖧}^s(x_i)$, so the break condition is a ±-collision of ${𝖧}^s$ at the pair $(x_1,x_2)$.

Distinct final inputs. The final inputs $x_1,x_2$ of a break need not be distinct, but the case $x_1=x_2$ is fully deterministic. If the witnesses decode differently —one external, one internal— their final inputs lie in disjoint summands of the combined domain, so $x_1=x_2$ is impossible outright. If both witnesses are externally decoded, equal final inputs force the witnesses to coincide on all fields constrained by the key-binding condition, contradicting distinctness. (Equal ${𝖧}^{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}$ inputs determine $(𝗊𝗄,𝖺𝗄,𝗇𝗄)$ and thence $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍=𝗋𝗂𝗏𝗄$; equal ${𝖧}^{𝗋𝗂𝗏𝗄\_𝗅𝖾𝗀𝖺𝖼𝗒}$ inputs determine $𝗌𝗄$ and thence everything, via ${𝖧}^{𝖺𝗌𝗄}$ and ${𝖧}^{𝗇𝗄}$.) So both witnesses are internally decoded, sharing $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍,𝗋𝗂𝗏𝗄)$ and differing only in their branch data. Then ${𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}_1={𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}_2$ is an equality of ${𝖧}^{\ast }$ outputs at the two upstream (rivk_ext-derivation) inputs, which the differing branch data make distinct. The shifts at those inputs agree: both equal $h(𝖺𝗄,𝗇𝗄)$, using the derivation constraints on the $𝗌𝗄$ side. So this is again a ±-collision of ${𝖧}^s$, at distinct inputs. In every case: a key-binding break yields a ±-collision of ${𝖧}^s$ at two distinct inputs among the adversary's queries, under the convention that $q_{𝗄𝖻}$ counts the derivation inputs of the adversary's output witnesses among its queries. This convention is without loss of generality: replace $𝒜$ by the adversary that runs $𝒜$, queries the (at most 4) derivation inputs of its output witnesses —each witness's final input and its rivk_ext-derivation input— and returns the output unchanged. This "reasonable adversary" normalization³⁸ leaves the output distribution —and therefore the break probability— unchanged, puts the collision inputs among the queries by construction, and adds at most 4 to $q_{𝗄𝖻}$.

Note that the external/internal decode is by value ($𝗋𝗂𝗏𝗄\stackrel{?}{=}𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$), not by how the witness was derived: at a fixpoint ${𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)=𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$ an internally-derived witness decodes as external. Both readings give the same $𝗋𝗂𝗏𝗄$, and the accounting partitions pairs by the decode.

Sequential collision bound. The adversary chooses each query adaptively, so we reveal the oracle responses in query order rather than fixing a pair in advance. Before the $j$-th query $x_j$ to ${𝖧}^{\ast }$, condition on the transcript so far: the ${𝖧}^{𝖺𝗌𝗄}$/${𝖧}^{𝗇𝗄}$ responses (which fix the shifts $s(\cdot )$) and the $j-1$ recorded ${𝖧}^{\ast }$ responses. Under every such conditioning the fresh response ${𝖧}^{\ast }(x_j)$ is uniform on ${𝔽}_{r_{\mathbb{P}}}$, and for each recorded input $x_i$ and each sign there is exactly one value of ${𝖧}^{\ast }(x_j)$ with ${𝖧}^s(x_j)\equiv \pm {𝖧}^s(x_i)(\mathrm{mod}{r}_{\mathbb{P}})$; so the fresh response completes a shifted ±-collision with probability at most $2(j-1)/r_{\mathbb{P}}$. Because the conditioning is on the transcript itself, this holds however $x_j$ was chosen from the transcript. Summing over the queries, ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})\le {\sum }_{j=1}^{q_{𝗄𝖻}}\frac{2(j-1)}{r_{\mathbb{P}}}=\frac{q_{𝗄𝖻}(q_{𝗄𝖻}-1)}{r_{\mathbb{P}}}\text{.}$ (Queries to ${𝖧}^{𝖺𝗌𝗄}$ or ${𝖧}^{𝗇𝗄}$ are not ${𝖧}^{\ast }$ inputs and cannot complete a collision, so counting them in $q_{𝗄𝖻}$ is conservative.)

#Security argument for Spendability

DeriveNullifier is based on a Pedersen hash. In the current Orchard protocol, the property that it is infeasible to find two distinct Orchard-protocol notes with the same nullifier depends on the collision resistance of that hash, which would not hold against a discrete-logarithm-breaking adversary.

Does this mean it is possible to break Spendability for the given Recovery Statement? As it turns out, no, but the argument is somewhat involved.

Since each function in the Recovery Statement is deterministic, the free variables that the adversary can control are the sources of the derivation digraph within that statement and either $𝖲𝗈{𝖪}^{𝗌𝗄}$ or $𝖲𝗈{𝖪}^{𝗊𝗄}$. That is, the adversary can control all of $(\text{ρ},{𝗀}_{𝖽},𝗋𝗌𝖾𝖾𝖽,𝗌𝗄,𝗇𝗄,𝖺𝗄,𝗊𝗄,𝗊𝗌𝗄,𝗋𝗂𝗏𝗄)$ subject to exactly one of $𝗌𝗄$ and $𝗊𝗄$ being present, per the $𝗊𝗄\_𝗈𝗋\_𝗌𝗄$ tagged union. The choice between external and internal IVK is encoded in $𝗋𝗂𝗏𝗄$'s value (either $𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍$ or ${𝖧}_{𝗋𝗂𝗏𝗄\_𝖾𝗑𝗍}^{𝗋𝗂𝗏𝗄\_𝗂𝗇𝗍}(𝖺𝗄,𝗇𝗄)$).

We analyze $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ as a function of these controllable inputs. Recall that $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ is defined in § 4.16 ‘Computing ρ values and Nullifiers’ as:

$${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\mathbb{P}}\left(\right[(𝖯𝖱{𝖥}_{𝗇𝗄}^{𝗇𝖿}(\text{ρ})+\text{ψ})mod{q}_{\mathbb{P}}]𝒦+𝖼𝗆)$$

Also recall from [Repairing note commitments] that we have

$$+𝖿(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ\text{.}$$

Let $K_{ℛ}$ denote the discrete logarithm of $𝒦$ with respect to $ℛ$. This is well-defined and nonzero: $ℛ$ generates the prime-order Pallas group, so any non-identity Pallas point has a unique nonzero discrete logarithm with respect to it; and $𝒦$ is non-identity by construction.

Recall that $\text{ψ}$ is determined by $𝗋𝗌𝖾𝖾𝖽$ via $\text{ψ}={𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{\text{ψ}}(\text{ρ})$. The nullifier corresponding to $(𝗇𝗄,\text{ρ},𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ is then

$$\left[\right((𝖯𝖱{𝖥}_{𝗇𝗄}^{𝗇𝖿}(\text{ρ})+\text{ψ})mod{q}_{\mathbb{P}})\cdot K_{ℛ}+{𝖧}_{𝗋𝗌𝖾𝖾𝖽}^{𝗋𝖼𝗆}(𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)+𝖿(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)]ℛ)\text{.}$$

We model ${𝖧}^{𝗋𝖼𝗆}$ as a random oracle with output uniform on ${𝔽}_{r_{\mathbb{P}}}$. The functions $𝖿$, ${𝖧}^{\text{ψ}}$, and $𝖯𝖱{𝖥}^{𝗇𝖿}$ are deterministic functions of $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾=(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ that do not query ${𝖧}^{𝗋𝖼𝗆}$: $𝖿(𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾)$ is the Sinsemilla-base lift; ${𝖧}^{\text{ψ}}$ and $𝖯𝖱{𝖥}^{𝗇𝖿}$ are conventional hash functions.

The non-querying constraint rules out trivializing instantiations such as $𝖿(\text{•})=-{𝖧}^{𝗋𝖼𝗆}(\text{•})$. In the concrete protocol, it reflects that $𝖿$ depends only on fixed Sinsemilla bases; and that the hashes ${𝖧}^{\text{ψ}}$, $𝖯𝖱{𝖥}^{𝗇𝖿}$, and ${𝖧}^{𝗋𝖼𝗆}$ use distinct domain separators, so can be considered unrelated to each other.

A key-binding break is as defined above in the Security argument for key binding.

Let ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$ be the probability, over $𝒜$'s randomness and at most $q_{𝗄𝖻}$ queries to the random oracles used in the key-binding argument, that $𝒜$ outputs a key-binding break (with $q_{𝗄𝖻}$ counting the derivation inputs of the output witnesses among the queries, as in the accounting normalization). ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$ is bounded separately by that argument; the bound below is unconditional, but is only useful to the extent that ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$ is small.

We give a reduction-based argument that any classical adversary $𝒜$ in the Random Oracle Model attempting to find two valid Recovery Statement witnesses with distinct note tuples that have colliding nullifiers, succeeds with probability at most $\frac{q_{𝗋𝖼𝗆}(q_{𝗋𝖼𝗆}-1)}{r_{\mathbb{P}}}+{\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$, where $q_{𝗋𝖼𝗆}$ is the number of queries $𝒜$ makes to ${𝖧}^{𝗋𝖼𝗆}$, and $q_{𝗄𝖻}$ is as defined above. The bound depends only on $q_{𝗋𝖼𝗆}$ and on ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$, not on running time.

The components $𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋$ are fields of $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾$ by definition; and $\text{ρ}$, ${𝗀}_{𝖽}$, $𝗉{𝗄}_{𝖽}$, and $\text{ψ}$ are fields of $𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋$, hence of $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾$.

$𝗂𝗏𝗄$-pinning lemma. For any valid Recovery Statement witness $w$ with $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾=(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$, the value $𝗂𝗏𝗄={\log }_{{𝗀}_{𝖽}}(𝗉{𝗄}_{𝖽})$ is well-defined, since ${𝗀}_{𝖽}\ne {𝒪}_{\mathbb{P}}$ on the prime-order Pallas curve and $𝗂𝗏𝗄\in [0,q_{\mathbb{P}})\subseteq [0,r_{\mathbb{P}})$; $𝗂𝗏𝗄$ is therefore uniquely determined by $𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾$.

$𝗇𝖿$-pinning lemma. Suppose $𝒜$'s output $(w_1,w_2)$ does not contain a key-binding break. Then for each $i\in \{1,2\}$, ${𝗇𝖿}_i$ is uniquely determined by ${𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_i$: by the conditioning, $({𝖺𝗄}_i,{𝗇𝗄}_i,{𝗋𝗂𝗏𝗄}_i)$ is the only opening of ${𝗂𝗏𝗄}_i$ appearing in $𝒜$'s output, so ${𝗇𝗄}_i$ is a function of ${𝗂𝗏𝗄}_i$, which is in turn a function of ${𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_i$ by the $𝗂𝗏𝗄$-pinning lemma; ${\text{ρ}}_i$ is a field of ${𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_i$; and the remaining $𝖣𝖾𝗋𝗂𝗏𝖾𝖭𝗎𝗅𝗅𝗂𝖿𝗂𝖾𝗋$ inputs ${\text{ψ}}_i$ and ${𝖼𝗆}_i$ are determined by ${𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_i$ through the Recovery Statement's deterministic derivations.

The argument here covers nullifier-binding — it argues that $𝗇𝖿$ binds the note tuple $(𝗋𝗌𝖾𝖾𝖽,𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋)$ under ${𝖧}^{𝗋𝖼𝗆}$ modelled as a random oracle and the key-binding theorem.

Theorem (distinct-notetuple Spendability, classical ROM). Let $𝒜$ be a classical adversary with oracle access to ${𝖧}^{𝗋𝖼𝗆}$ having output uniform on ${𝔽}_{r_{\mathbb{P}}}$, making at most $q_{𝗋𝖼𝗆}$ oracle queries. The Spendability-collision game has $𝒜$ output two Recovery Statement witnesses $w_1,w_2$ satisfying:

Validity of witnesses

both witnesses satisfy the Proposed Recovery Statement.

Distinct note tuples

the ${𝖧}^{𝗋𝖼𝗆}$-input tuples ${𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_i:=({𝗋𝗌𝖾𝖾𝖽}_i,{𝗇𝗈𝗍𝖾𝗋𝖾𝗉𝗋}_i)$ satisfy ${𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_1\ne {𝗇𝗈𝗍𝖾𝗍𝗎𝗉𝗅𝖾}_2$.

Colliding nullifiers : ${𝗇𝖿}_1={𝗇𝖿}_2$.

Then $𝒜$ wins this game with probability at most

$$+{\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})=\frac{q_{𝗋𝖼𝗆}(q_{𝗋𝖼𝗆}-1)}{r_{\mathbb{P}}}+{\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})\text{,}$$

taken over the random oracle's responses and any internal randomness of $𝒜$.

This bound is essentially tight against classical generic adversaries. Maurer ³⁹ (Section 2, p. 5) establishes a matching upper bound of $\left(\genfrac{}{}{0px}{}{k}{2}\right)/N$ on the success probability of any classical algorithm in finding a collision against a random oracle with an $N$-element output space using $k$ queries. Maurer's bound applies to the equality event $F_i=F_j$; our win condition allows $F_i=\pm F_j$ (two winning configurations per pair instead of one). Applying Maurer with $N=r_{\mathbb{P}}$ (the ${𝖧}^{𝗋𝖼𝗆}$ output space) gives $\left(\genfrac{}{}{0px}{}{q_{𝗋𝖼𝗆}}{2}\right)/r_{\mathbb{P}}$ for the equality event; doubling for the sign relaxation gives our $\frac{q_{𝗋𝖼𝗆}(q_{𝗋𝖼𝗆}-1)}{r_{\mathbb{P}}}$ bound. Classical parallel collision search ⁴⁰ (top of p. 8) achieves the equality-event regime up to a constant factor; the same adversaries achieve a constant fraction of the doubled bound for the $\pm$-equivalence event.

Proof sketch. $𝒜$ makes at most $q_{𝗋𝖼𝗆}$ queries to ${𝖧}^{𝗋𝖼𝗆}$ before outputting $(w_1,w_2)$ satisfying Validity of witnesses, Distinct note tuples, and Colliding nullifiers. The probability that $(w_1,w_2)$ contains a key-binding break is at most ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})$; condition on the complement.

Algebraic setup. Under this conditioning, define

\mathsf{f}(\mathsf{notetuple}) + \big((\mathsf{PRF^{nf}_{nk}}(\text{ρ}) + \text{ψ}) \bmod q_{\mathbb{P}}\big) \cdot K_{\kern-.08em\mathcal{R}} \pmod{r_{\mathbb{P}}}$$, where $\mathsf{rseed}, \text{ρ}, \text{ψ}$ are fields of $\mathsf{notetuple}$ and $\mathsf{nk}$ is determined by $\mathsf{notetuple}$ via the key-binding leg of the [$\mathsf{nf}$-pinning lemma](#lemma-nf-pinning), and let $F_i := \mathsf{F}(\mathsf{notetuple}_i)$ for $i \in \{1, 2\}$. $\mathsf{Extract}_{\mathbb{P}}$ (§ 5.4.9.7 'Coordinate Extractor for Pallas' [^protocol-updated-concreteextractorpallas]) is the $x$-coordinate of its argument for non-identity points, with the identity mapping to $0$. Since Pallas has the form $y^2 = Y(x)$ and no Pallas point has $x$-coordinate $0$, the collision $\mathsf{nf}_1 = \mathsf{nf}_2$ holds iff $F_1 \equiv \pm F_2 \pmod{r_{\mathbb{P}}}$. *Independence claim per pair.* By [**Distinct note tuples**](#thm-spendability-distinct), $\mathsf{notetuple}_1 \neq \mathsf{notetuple}_2$, so the $\mathsf{H^{rcm}}$ outputs at $\mathsf{notetuple}_1, \mathsf{notetuple}_2$ are independent uniform on $\mathbb{F}_{r_{\mathbb{P}}}$. The deterministic shifts ($\mathsf{f}$ and the $\mathsf{PRF^{nf}}$ contribution scaled by $K_{\kern-.08em\mathcal{R}}$) do not query $\mathsf{H^{rcm}}$, so they are independent of its responses. Hence $F_1$ and $F_2$ are independent uniform on $\mathbb{F}_{r_{\mathbb{P}}}$. *Bounding the win probability.* The win condition $F_1 \equiv \pm F_2$ is a linear constraint on a pair of independent uniform variables, satisfied with probability at most $2/r_{\mathbb{P}}$ (one per sign). Union-bounding over the at most ${q_{\mathsf{rcm}} \choose 2}$ pairs of distinct $\mathsf{H^{rcm}}$ queries: $$\Pr[\text{win} \mid \neg\,\text{break}] \leq \frac{q_{\mathsf{rcm}}(q_{\mathsf{rcm}}-1)}{r_{\mathbb{P}}}\textsf{.} ParseError: Can't use function '$' in math mode at position 165: …r_{\mathbb{P}}}$̲$, where $\math…

Decomposing on whether a key-binding break occurs and applying $\mathrm{Pr}[\text{win}]\le \mathrm{Pr}[\text{win}|\neg \text{break}]+\mathrm{Pr}[\text{break}]$: $\mathrm{Pr}[\text{win}]\le \frac{q_{𝗋𝖼𝗆}(q_{𝗋𝖼𝗆}-1)}{r_{\mathbb{P}}}+{\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})\text{.}$ This completes the classical-ROM proof.

The key-binding theorem bounds ${\epsilon }_{𝗄𝖻}(𝒜,q_{𝗄𝖻})\le \frac{q_{𝗄𝖻}(q_{𝗄𝖻}-1)}{r_{\mathbb{P}}}$. Substituting, an adversary $𝒜$ that makes at most $q_{𝗋𝖼𝗆}$ queries to ${𝖧}^{𝗋𝖼𝗆}$ and at most $q_{𝗄𝖻}$ queries to the key-binding random oracles wins the Spendability-collision game with probability at most $\frac{q_{𝗋𝖼𝗆}(q_{𝗋𝖼𝗆}-1)}{r_{\mathbb{P}}}+\frac{q_{𝗄𝖻}(q_{𝗄𝖻}-1)}{r_{\mathbb{P}}}$.

For the post-quantum lift of this bound and of the key-binding bound above, see the next section.

#Adaptation to the quantum setting

The classical-ROM proofs above (for key binding and Spendability) rely on ${𝖧}^{𝗋𝖼𝗆}$ and the various $𝗋𝗂𝗏𝗄$-derivation hashes being collision-resistant. The natural quantum analog is called the collapsing property, introduced by Unruh ^{28 29}. It says that even a quantum adversary holding a superposition over several preimages of a fixed output cannot tell —by any subsequent measurement— which preimage it now has. This is the right property for our reductions. Each proof above splits cases based on which oracle query produced the colliding output; that case analysis works the same classically and quantumly only if the underlying hash "collapses" the adversary's superposition to a single classical preimage.

Subsequent work has analyzed whether standard hash-function constructions inherit collapsing from their compression function. Unruh ²⁹ proved this for Merkle–Damgård (with a padding restriction); Czajkowski et al. ⁴¹ for the sponge construction (the absorb-then-squeeze paradigm used by SHA-3 / Keccak), with ³⁷ strengthening the sponge result via the related notion of quantum indifferentiability. Fehr ⁴² gave a unified algebraic framework that recovers these results and proves the collapsing property of HAIFA, a Merkle–Damgård variant with a per-iteration salt and counter. Gunsing and Mennink ³⁵ extended this kind of analysis to tree-hash constructions, relevant for the Recovery Protocol's note-commitment tree.

BLAKE2b uses HAIFA, so by Fehr's theorem modelling ${𝖧}^{𝗋𝖼𝗆}$ as collapsing reduces to modelling BLAKE2b's compression function as collapsing. The "iv-preimage resistance" side condition Fehr's theorem requires for arbitrary-length inputs is automatically satisfied if the compression function is modelled as a random oracle — which is also the modelling assumption underlying the classical-ROM analyses above.

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.

${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\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 ${𝖧}^{𝗋𝖼𝗆}$ 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 ${𝖼𝗆}_x$ has exactly two valid $𝖼𝗆$ values, hence exactly two valid $𝗋𝖼𝗆$ values, as stated in the Spendability proof above).

This factor-of-2 absorption relies on the fibres $\{P,-P\}$ of ${𝖤𝗑𝗍𝗋𝖺𝖼𝗍}_{\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:

• ${\epsilon }_{𝖲𝗉𝖾𝗇𝖽𝖺𝖻𝗂𝗅𝗂𝗍𝗒}^{𝖰𝖱𝖮𝖬}\le O\left(q_{𝗋𝖼𝗆}^3/r_{\mathbb{P}}\right)+{\epsilon }_{𝗄𝖻}^{𝖰𝖱𝖮𝖬}$.
• ${\epsilon }_{𝗄𝖻}^{𝖰𝖱𝖮𝖬}\le O\left(q_{𝗄𝖻}^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_{𝗋𝖼𝗆},q_{𝗄𝖻}\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 $𝗂𝗏𝗄$ or $𝗌{𝗄}_{𝖾𝗇𝖼}$ 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 $𝖡𝗂𝗇𝖽𝖪𝖾𝗒𝗌$ constraint pins the key witness via $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$ (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 $(𝖺𝗄,𝗇𝗄,𝗋𝗂𝗏𝗄)$ from a spending key $𝗌𝗄$ in the way specified for the $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝖿𝖺𝗅𝗌𝖾$ case in § 4.2.3 ‘Orchard Key Components’ ¹⁵.

FROST distributed key generation requires the $𝗎𝗌𝖾\_𝗊𝗌𝗄=𝗍𝗋𝗎𝖾$ 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 $𝗉𝗋𝖾\_𝗋𝖼𝗆$. It would have been possible to use a separate pq-binding commitment, but ${𝖧}^{𝗋𝖼𝗆}$ 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. ZIP 226: Transfer and Burn of Zcash Shielded Assets — Split Notes ↩ ↩²

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

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

26. 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. ↩

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. 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. ↩

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

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

44. 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. ↩

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

46. 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. ↩

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

48. 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 ↩ ↩²

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

50. ZIP 2003: Disallow version 4 transactions ↩

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