V Ironwood Guide: The Zcash Orchard protocol and its Ironwood pool 8 Value commitments and the binding signature 10 Note encryption

9 The Action statement and its proof

This section states the relation that is proved for every Action. It fixes the bundle flags that enter the relation as public inputs, states the Action statement over the objects constructed in §2 to §8, pairs each condition with the requirement it serves and with the check outside the proof that completes it, and states the proof system together with the two assumptions on the Action proof that “Security” (§12) uses.

9.1 Bundle flags

Each bundle carries one flags byte, present exactly when the bundle has at least one Action: $\mathsf{flagsOrchard}$ for the Orchard-pool bundle of a version $5$ or version $6$ transaction, and $\mathsf{flagsIronwood}$ for the Ironwood-pool bundle of a version $6$ transaction (ZIP 229, “Transaction Format”). Bits are numbered from the least significant, bit $0$ . In both bytes bit $0$ is $\mathsf{enableSpends}$ and bit $1$ is $\mathsf{enableOutputs}$ . The consensus rules of ZIP 229, “Consensus Rules”, fix the remaining bits:

1.

in $\mathsf{flagsIronwood}$ , bit $2$ is $\mathsf{enableCrossAddress}$ , and bits $3$ to $7$ are reserved and must be $0$ ;
2.

in $\mathsf{flagsOrchard}$ , bits $2$ to $7$ are reserved and must be $0$ , in version $5$ and version $6$ transactions alike.

The format table of ZIP 229, “Transaction Format”, lists $\mathsf{enableCrossAddress}$ at bit $2$ of $\mathsf{flagsOrchard}$ ; this contradicts the consensus rules of the same ZIP, which reserve that bit, and the volume follows the consensus rules. The two texts differ in the role of the bit, not in its value in a valid transaction: ZIP 258, “Consensus rules from NU6.3 activation”, requires every Orchard-pool Action to be created with $\mathsf{enableCrossAddress}=0$ .

Definition 9.1 (Flag values and expanded receiver).

Let a bundle have flags byte $f=\sum_{i=0}^{7}f_{i}\,2^{i}$ with $f_{i}\in\{0,1\}$ . Its flag values, elements of $\{0,1\}$ , are

	$\displaystyle\mathsf{enableSpends}:=f_{0},\qquad\mathsf{enableOutputs}:=f_{1},$
	$\displaystyle\mathsf{enableCrossAddress}:=\begin{cases}f_{2}&\text{for an % Ironwood-pool bundle},\\ 0&\text{for an Orchard-pool bundle},\end{cases}$

and $\mathsf{disableCrossAddress}:=1-\mathsf{enableCrossAddress}$ . For an Orchard-pool bundle bit $2$ is reserved and $0$ , so every Orchard-pool Action has $\mathsf{enableCrossAddress}=0$ by encoding. The expanded receiver of a payment address $(d,\mathsf{pk_{d}})$ is the pair $(\mathsf{g_{d}},\mathsf{pk_{d}})$ with $\mathsf{g_{d}}=\mathsf{DiversifyHash}(d)$ , the diversified base of “Diversified addresses” (§3.3); the expanded receiver of a note is that of its address. The flags have the following meaning (protocol specification, §“Action Descriptions”):

•

the value $\mathsf{enableSpends}=1$ enables non-zero-valued spends in the bundle’s Actions;
•

the value $\mathsf{enableOutputs}=1$ enables non-zero-valued outputs in the bundle’s Actions;
•

the value $\mathsf{enableCrossAddress}=1$ enables the expanded receiver of an Action’s created note to differ from that of the note the same Action consumes.

The Action statement takes $\mathsf{disableCrossAddress}$ as its eighth primary input (same section). No normative text fixes the position of this input in the encoded instance, and none is asserted here.

ZIP 229 calls $\mathsf{enableCrossAddress}=1$ the normal case for Ironwood-pool Actions (Rationale, “enableCrossAddress polarity”); the value is not required. No consensus rule requires bit $2$ of $\mathsf{flagsIronwood}$ to be $1$ . A bundle in which that bit is $0$ is admitted, and each of its Actions is then restricted, by condition A10 of Definition 9.2, to create its note at the expanded receiver of the note it consumes.

The flags are properties of the bundle. Encoded once in its flags byte, they are the same for every Action of the bundle (protocol specification, §“Action Descriptions”, note on the encoding of these components once per pool). The verifier reads them from the bundle and supplies $\mathsf{enableSpends}$ , $\mathsf{enableOutputs}$ and $\mathsf{disableCrossAddress}$ as public inputs of each Action; they are not computed inside the proof. They enter the relation only through conditions A8, A9 and A10 of Definition 9.2.

9.2 The Action statement

The Action statement is a relation in the sense of the Crypto Guide’s Definition “Language, relation, witness” (§“Languages, relations, and witnesses”), with the primary input as instance and the auxiliary input as witness, each a tuple of the typed objects below, encoded as bit strings by the encodings of §2.1. Every condition is an equation over objects constructed in §2 to §8.

Definition 9.2 (Orchard Action statement).

In this definition $\mathcal{E}$ abbreviates the Pallas group $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ , with identity $\mathcal{O}$ , and $\mathcal{E}^{*}:=\mathcal{E}\setminus\{\mathcal{O}\}$ . For $P=(x,y)\in\mathcal{E}^{*}$ let $x(P):=x$ and $y(P):=y$ , and let $x(\mathcal{O}):=y(\mathcal{O}):=0$ , so that $\mathsf{Extract}_{\mathbb{P}}(P)=x(P)$ for every $P\in\mathcal{E}$ (protocol specification, §“Coordinate Extractor for Pallas”). An integer that multiplies a point acts as its residue modulo $p_{\mathsf{Vesta}}$ (§2.1).

The relation $\mathcal{R}_{\mathsf{Action}}$ is the set of pairs $(\mathsf{pub},\mathsf{aux})$ of a primary input

\mathsf{pub}=\bigl{(}\mathit{rt},\,\mathsf{cv}^{\mathsf{net}},\,\mathsf{nf}^{% \mathsf{old}},\,\mathsf{rk},\,\mathsf{cmx},\,\mathsf{enableSpends},\,\mathsf{% enableOutputs},\,\mathsf{disableCrossAddress}\bigr{)}

and an auxiliary input

	$\displaystyle\mathsf{aux}=\bigl{(}$	$\displaystyle\mathsf{path},\,\mathsf{pos},\,\mathsf{g_{d}}^{\mathsf{old}},\,% \mathsf{pk_{d}}^{\mathsf{old}},\,v^{\mathsf{old}},\,\rho^{\mathsf{old}},\,\psi% ^{\mathsf{old}},\,\mathsf{rcm}^{\mathsf{old}},\,\mathsf{cm}^{\mathsf{old}},\,% \alpha,\,\mathsf{ak}^{\mathbb{P}},\,\mathsf{nk},\,\mathsf{r_{ivk}},$
		$\displaystyle\mathsf{g_{d}}^{\mathsf{new}},\,\mathsf{pk_{d}}^{\mathsf{new}},\,% v^{\mathsf{new}},\,\psi^{\mathsf{new}},\,\mathsf{rcm}^{\mathsf{new}},\,\mathsf% {rcv},\,\mathsf{c}\bigr{)}$

that have the following types and satisfy conditions A1 to A10 below.

•

Primary input: $\mathit{rt},\mathsf{nf}^{\mathsf{old}},\mathsf{cmx}\in\{0,\dots,p_{\mathsf{% Pallas}}-1\}$ , read as elements of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ ; $\mathsf{cv}^{\mathsf{net}},\mathsf{rk}\in\mathcal{E}$ ; and $\mathsf{enableSpends},\mathsf{enableOutputs},\mathsf{disableCrossAddress}\in\{% 0,1\}$ .
•

Auxiliary input: $\mathsf{path}=(s_{0},\dots,s_{31})$ with every $s_{t}\in\{0,\dots,p_{\mathsf{Pallas}}-1\}$ ; $\mathsf{pos}\in\{0,\dots,2^{32}-1\}$ ; $\mathsf{g_{d}}^{\mathsf{old}},\mathsf{pk_{d}}^{\mathsf{old}},\mathsf{g_{d}}^{% \mathsf{new}},\mathsf{pk_{d}}^{\mathsf{new}},\mathsf{ak}^{\mathbb{P}}\in% \mathcal{E}^{*}$ ; $v^{\mathsf{old}},v^{\mathsf{new}}\in\{0,\dots,2^{64}-1\}$ ; $\rho^{\mathsf{old}},\psi^{\mathsf{old}},\psi^{\mathsf{new}},\mathsf{nk}\in% \mathbb{F}_{p_{\mathsf{Pallas}}}$ ; $\mathsf{cm}^{\mathsf{old}}\in\mathcal{E}$ ; $\mathsf{rcm}^{\mathsf{old}},\mathsf{rcm}^{\mathsf{new}},\mathsf{r_{ivk}},% \mathsf{rcv},\alpha\in\{0,\dots,2^{255}-1\}$ ; and $\mathsf{c}=(c_{0},\dots,c_{63})\in\{0,1\}^{64}$ .

Let $\rho^{\mathsf{new}}:=\mathsf{nf}^{\mathsf{old}}\in\mathbb{F}_{p_{\mathsf{% Pallas}}}$ , let $\delta:=\mathsf{disableCrossAddress}$ , and let

	$\displaystyle M^{\mathsf{old}}$	$\displaystyle:=(\mathsf{g_{d}}^{\mathsf{old}})^{\star}\,\\|\,(\mathsf{pk_{d}}^{% \mathsf{old}})^{\star}\,\\|\,\mathrm{LE}_{64}(v^{\mathsf{old}})\,\\|\,\mathrm{LE% }_{255}(\rho^{\mathsf{old}})\,\\|\,\mathrm{LE}_{255}(\psi^{\mathsf{old}}),$
	$\displaystyle M^{\mathsf{new}}$	$\displaystyle:=(\mathsf{g_{d}}^{\mathsf{new}})^{\star}\,\\|\,(\mathsf{pk_{d}}^{% \mathsf{new}})^{\star}\,\\|\,\mathrm{LE}_{64}(v^{\mathsf{new}})\,\\|\,\mathrm{LE% }_{255}(\rho^{\mathsf{new}})\,\\|\,\mathrm{LE}_{255}(\psi^{\mathsf{new}}),$

the $1086$ -bit messages of Definition 4.4, with the diversified bases witnessed. The conditions, all equations in $\mathbb{F}_{p_{\mathsf{Pallas}}}$ or in $\mathcal{E}$ , are:

A1.

Old note commitment integrity: $\mathsf{NoteCommit}_{\mathsf{rcm}^{\mathsf{old}}}(M^{\mathsf{old}})\in\{% \mathsf{cm}^{\mathsf{old}},\bot\}$ .
A2.

New note commitment integrity: $\mathsf{Extract}_{\mathbb{P}}^{\bot}\bigl{(}\mathsf{NoteCommit}_{\mathsf{rcm}^% {\mathsf{new}}}(M^{\mathsf{new}})\bigr{)}\in\{\mathsf{cmx},\bot\}$ .
A3.

Merkle path validity: $v^{\mathsf{old}}\cdot(\mathit{root}-\mathit{rt})=0$ or some evaluation of $\mathsf{SinsemillaHash}$ in the fold, the root included, returns $\bot$ . Here $\mathit{root}:=a_{32}$ is the result of the fold (2) of Proposition 5.9 with $a_{0}:=\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\mathsf{old}})$ , siblings $s_{0},\dots,s_{31}$ and the bits of $\mathsf{pos}$ as direction bits, in which the evaluation of $\mathsf{MerkleCRH}$ at level $t$ encodes its left argument $x$ as $\mathrm{LE}_{255}(\tilde{x})$ , where $\tilde{x}:=x+c_{2t}\,p_{\mathsf{Pallas}}$ if this integer is below $2^{255}$ and $\tilde{x}:=x$ otherwise, and its right argument likewise with $c_{2t+1}$ .

A4.

Value commitment integrity:

\mathsf{cv}^{\mathsf{net}}=\mathsf{ValueCommit}^{\mathsf{Orchard}}_{\mathsf{% rcv}}(v^{\mathsf{old}}-v^{\mathsf{new}})=[v^{\mathsf{old}}-v^{\mathsf{new}}]\,% V^{\mathsf{Orchard}}+[\mathsf{rcv}]\,R^{\mathsf{Orchard}}.

A5.

Nullifier integrity: $\mathsf{nf}^{\mathsf{old}}=\mathsf{DeriveNullifier}_{\mathsf{nk}}(\rho^{% \mathsf{old}},\psi^{\mathsf{old}},\mathsf{cm}^{\mathsf{old}})$ , that is,

\mathsf{nf}^{\mathsf{old}}=\mathsf{Extract}_{\mathbb{P}}\bigl{(}[(\mathsf{PRF}% ^{\mathsf{nfOrchard}}_{\mathsf{nk}}(\rho^{\mathsf{old}})+\psi^{\mathsf{old}})% \bmod p_{\mathsf{Pallas}}]\,K^{\mathsf{Orchard}}+\mathsf{cm}^{\mathsf{old}}% \bigr{)}.

A6.

Spend authority: $\mathsf{rk}=\mathsf{ak}^{\mathbb{P}}+[\alpha]\,G^{\mathsf{SpendAuth}}$ .
A7.

Diversified address integrity: with $\mathsf{ivk}:=\mathsf{Commit}^{\mathsf{ivk}}_{\mathsf{r_{ivk}}}\bigl{(}\mathsf% {Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}}),\mathsf{nk}\bigr{)}$ , either $\mathsf{ivk}=\bot$ or $\mathsf{pk_{d}}^{\mathsf{old}}=[\mathsf{ivk}]\,\mathsf{g_{d}}^{\mathsf{old}}$ .
A8.

Enable spend flag: $v^{\mathsf{old}}\cdot(1-\mathsf{enableSpends})=0$ .
A9.

Enable output flag: $v^{\mathsf{new}}\cdot(1-\mathsf{enableOutputs})=0$ .

A10.

Cross-address restriction: the four equations

	$\displaystyle\delta\cdot\bigl{(}x(\mathsf{g_{d}}^{\mathsf{old}})-x(\mathsf{g_{% d}}^{\mathsf{new}})\bigr{)}$	$\displaystyle=0,$	$\displaystyle\delta\cdot\bigl{(}y(\mathsf{g_{d}}^{\mathsf{old}})-y(\mathsf{g_{% d}}^{\mathsf{new}})\bigr{)}$	$\displaystyle=0,$
	$\displaystyle\delta\cdot\bigl{(}x(\mathsf{pk_{d}}^{\mathsf{old}})-x(\mathsf{pk% _{d}}^{\mathsf{new}})\bigr{)}$	$\displaystyle=0,$	$\displaystyle\delta\cdot\bigl{(}y(\mathsf{pk_{d}}^{\mathsf{old}})-y(\mathsf{pk% _{d}}^{\mathsf{new}})\bigr{)}$	$\displaystyle=0.$

(Protocol specification, §“Action Statement (Orchard)”, for the typed inputs and conditions A1 to A9; §“Action Descriptions” for the eighth primary input and the meaning of $\mathsf{enableCrossAddress}$ that A10 formalises.)

The anchor $\mathit{rt}$ is the bundle’s anchor (“Anchors”, §5.2). The rule $\mathsf{rk}\neq\mathcal{O}$ of “Randomised validating keys” (§7.2) is checked outside the statement. The typing is part of the relation: the spend validating key $\mathsf{ak}^{\mathbb{P}}$ , both diversified bases and both transmission keys are non-identity points (protocol specification, §“Action Statement (Orchard)”, note on types). The trapdoors $\mathsf{rcm}^{\mathsf{old}}$ , $\mathsf{rcm}^{\mathsf{new}}$ , $\mathsf{r_{ivk}}$ and $\mathsf{rcv}$ and the randomiser $\alpha$ act only as scalars on points of order $p_{\mathsf{Vesta}}$ , and the statement does not require them to be below $p_{\mathsf{Vesta}}$ (same note). The created note’s element $\rho$ is not an auxiliary input; condition A2 fixes it. The relation is an NP-relation in the sense of the cited definition: its instances and witnesses have fixed length, and membership is decided by evaluating the typing and the ten conditions.

Points of the primary input enter the proof by their coordinates. The specification’s encoding note fixes the first seven primary inputs as the nine elements

\mathit{rt},\ x(\mathsf{cv}^{\mathsf{net}}),\ y(\mathsf{cv}^{\mathsf{net}}),\ % \mathsf{nf}^{\mathsf{old}},\ x(\mathsf{rk}),\ y(\mathsf{rk}),\ \mathsf{cmx},\ % \mathsf{enableSpends},\ \mathsf{enableOutputs}

of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , in this order (protocol specification, §“Action Statement (Orchard)”, note on the encoding of primary inputs); the convention $x(\mathcal{O})=y(\mathcal{O})=0$ encodes $\mathsf{cv}^{\mathsf{net}}=\mathcal{O}$ . The eighth input, $\mathsf{disableCrossAddress}$ , is one further element of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ (§“Action Descriptions”); no normative text fixes its position, and the volume asserts none.

Conditions and the checks that complete them. Each condition is paired below with the requirement of “Requirements on a shielded payment” (§1.4) that it serves and, where one exists, with the check outside the proof that completes it; Table 5 collects the pairing and Figure 3 draws it.

Conditions A1 and A2 bind the consumed and the created note to the commitments $\mathsf{cm}^{\mathsf{old}}$ and $\mathsf{cmx}$ under $\mathsf{NoteCommit}$ , the Sinsemilla commitment with domain z.cash:Orchard-NoteCommit (Definition 4.4), whose binding is Proposition 4.5; they serve R1. Condition A2 fixes the created note’s $\rho$ to the nullifier that the same Action publishes for the note it consumes, the chaining rule of “Nullifier chaining” (§6.3). Its consequences for the uniqueness of $\rho$ and for the Faerie Gold attack are proved in “Double-spend resistance” (Corollary 12.7).

Condition A3 serves R2. Since $0\leq v^{\mathsf{old}}<2^{64}<p_{\mathsf{Pallas}}$ (§2.1), the value $v^{\mathsf{old}}$ is zero in $\mathbb{F}_{p_{\mathsf{Pallas}}}$ only if it is the integer $0$ , and a field has no zero divisors. Hence, outside its $\bot$ case and with canonical encodings ( $\mathsf{c}=0$ ), A3 holds if and only if $v^{\mathsf{old}}=0$ or $\mathit{root}=\mathit{rt}$ , the specification’s form: either $v^{\mathsf{old}}=0$ , or $(\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\mathsf{old}}),\mathsf{pos},% \mathsf{path})$ is a valid path to $\mathit{rt}$ in the sense of Proposition 5.9, with the layer-tagged hash of “The Merkle hash and the tree” (§5.1) and the paths of depth $32$ of “Authentication paths” (§5.3). A consumed note of value zero is therefore exempt from membership. The exemption lets an Action whose consumed side is a dummy note (“Actions, bundles, and dummy notes”, §4.4) create a real note without consuming a committed one. For $v^{\mathsf{old}}\neq 0$ the condition is membership of $\mathsf{Extract}_{\mathbb{P}}(\mathsf{cm}^{\mathsf{old}})$ under $\mathit{rt}$ , up to the two relaxations below; Proposition 5.9 gives its soundness together with the anchor rule of “Anchors”, the check outside the proof that completes A3.

The two relaxations are the circuit’s: it does not check that the encoding of each layer’s input is canonical, and its path check may pass when a hash on the path, the root included, is $0$ , which occurs only when $\mathsf{SinsemillaHash}$ returns $\bot$ (protocol specification, §“Merkle Path Validity”, notes on Orchard; §“Action Statement (Orchard)”, notes on the Merkle path validity check). Remark “ $\bot$ -weakened conditions” below treats the $\bot$ case. The bits $\mathsf{c}$ , absent from the specification’s auxiliary input, record the encodings that the circuit witnesses. Since $p_{\mathsf{Pallas}}$ is odd and has bit length $255$ (§2.1), $2p_{\mathsf{Pallas}}>2^{255}$ , so the integers below $2^{255}$ congruent to an argument $x\in\{0,\dots,p_{\mathsf{Pallas}}-1\}$ are $x$ and, when it is below $2^{255}$ , $x+p_{\mathsf{Pallas}}$ : the bits range over every encoding the circuit admits, and $\mathsf{c}=0$ gives the canonical ones. Non-canonical encodings leave the extraction in the proof of Proposition 5.9(i) valid. At the least $t^{*}\geq 1$ at which the fold agrees with the genuine chain of that proof, the running values at level $t^{*}-1$ differ as elements of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , so no representative of the one equals a representative of the other, and the two $520$ -bit messages hashed there remain distinct with a common prefix. Parts (ii) and (iii) of the proposition therefore hold for the fold of A3.

Condition A4 serves R4. It is Definition 8.2: the integer $v^{\mathsf{old}}-v^{\mathsf{new}}\in\{-2^{64}+1,\dots,2^{64}-1\}$ , written as $\mathit{sign}\cdot\mathit{magnitude}$ with $\mathit{magnitude}\in\{0,\dots,2^{64}-1\}$ and $\mathit{sign}\in\{-1,+1\}$ , acts as a scalar modulo $p_{\mathsf{Vesta}}$ . The specification requires the scalar multiplication to be correct on this whole signed range, which differs from the range of the balancing value (protocol specification, §“Action Statement (Orchard)”, note on the signed range). The binding signature of “The binding signature” (§8.3) is the check outside the proof that completes value conservation.

Condition A5 serves R3. It is Definition 6.3; the multiplier of $K^{\mathsf{Orchard}}$ is the integer in $\{0,\dots,p_{\mathsf{Pallas}}-1\}$ obtained by reducing the sum modulo $p_{\mathsf{Pallas}}$ . The nullifier-set rule of “Nullifier sets” (§6.2) is the check outside the proof that completes it.

Conditions A6 and A7 serve R5. Condition A6 is the re-randomisation of “Randomised validating keys” (§7.2), with $G^{\mathsf{SpendAuth}}=\mathsf{GroupHash}(\texttt{z.cash:Orchard},\texttt{G})$ . Condition A7 recomputes the incoming viewing key as the $\mathsf{Commit}^{\mathsf{ivk}}$ instance of “Viewing keys” (§3.2), under the domain z.cash:Orchard-CommitIvk, from the field element $\mathsf{Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}})$ , not from the point; it ties the witnessed key components $\mathsf{ak}^{\mathbb{P}}$ , $\mathsf{nk}$ and $\mathsf{r_{ivk}}$ to the expanded receiver $(\mathsf{g_{d}}^{\mathsf{old}},\mathsf{pk_{d}}^{\mathsf{old}})$ of the consumed note. Outside its $\bot$ case it forces $\mathsf{ivk}\neq 0$ , since $\mathsf{pk_{d}}^{\mathsf{old}}\neq\mathcal{O}$ , and the receiver determines $\mathsf{ivk}$ , an integer below $p_{\mathsf{Pallas}}<p_{\mathsf{Vesta}}$ , since $\mathsf{g_{d}}^{\mathsf{old}}$ is a non-identity point of a group of prime order $p_{\mathsf{Vesta}}$ . The tie is the binding of $\mathsf{ivk}$ to $(\mathsf{ak},\mathsf{nk})$ (Proposition “Binding of $\mathsf{ivk}$ to $(\mathsf{ak},\mathsf{nk})$ ”, §3.2): under Assumptions 2.22 and 2.8, an efficient algorithm outputs two witnesses that satisfy A7 outside its $\bot$ case for one receiver, with distinct triples $(\mathsf{Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}}),\mathsf{nk},\mathsf{r% _{ivk}}\bmod p_{\mathsf{Vesta}})$ , only with negligible probability. The tie fixes the point $\mathsf{ak}^{\mathbb{P}}$ only up to sign (Lemma 2.4); Lemma 12.5 and Theorem 12.9 use it. The spend-authorisation signature under $\mathsf{rk}$ , verified outside the proof (§7.2), completes both conditions.

Conditions A8 and A9 have the product form of A3. The values are below $2^{64}<p_{\mathsf{Pallas}}$ and the flags are bits, so A8 holds if and only if $v^{\mathsf{old}}=0$ or $\mathsf{enableSpends}=1$ , and A9 if and only if $v^{\mathsf{new}}=0$ or $\mathsf{enableOutputs}=1$ , the specification’s forms. They tie the hidden values to the public flags of “Bundle flags” (§9.1).

Condition A10 also has the product form of A3: each of its equations is a public field element times a difference of witnessed values. The four points lie in $\mathcal{E}^{*}$ , where the affine coordinates determine the point. For $\delta=1$ , A10 therefore holds if and only if $(\mathsf{g_{d}}^{\mathsf{new}},\mathsf{pk_{d}}^{\mathsf{new}})=(\mathsf{g_{d}}% ^{\mathsf{old}},\mathsf{pk_{d}}^{\mathsf{old}})$ , equality of the expanded receivers as points and not only of their $x$ -coordinates; for $\delta=0$ it is vacuous. Condition A10 formalises the meaning of $\mathsf{enableCrossAddress}$ stated in the protocol specification, §“Action Descriptions”. Every Orchard-pool Action has $\delta=1$ ; an Ironwood-pool Action has $\delta=1-\mathsf{enableCrossAddress}$ , normally $0$ (ZIP 229, Rationale, “enableCrossAddress polarity”). Conditions A8 to A10 serve no requirement of their own.

Remark 9.3 (Meaning of A10).

Condition A10 constrains each Action separately: when $\mathsf{disableCrossAddress}=1$ , the note an Action creates is at the expanded receiver of the note that same Action consumes. The consumed note may be a dummy of value $0$ , which A3 exempts from membership. Hence a bundle with $\mathsf{disableCrossAddress}=1$ can still create a note at any expanded receiver $(\mathsf{g_{d}},\mathsf{pk_{d}})$ for which the transaction creator produces a dummy-spend Action in the same bundle. Such an Action has a witness: let its consumed note be a dummy of value $0$ at $(\mathsf{g_{d}},\mathsf{pk_{d}})$ and its created note, of any value $v$ , be at the same receiver, and let $(\mathsf{ak}^{\mathbb{P}},\mathsf{nk},\mathsf{r_{ivk}})$ be the key components of that receiver. Condition A3 holds because $v^{\mathsf{old}}=0$ , A8 for either value of $\mathsf{enableSpends}$ , A10 with $\delta=1$ because the two receivers agree, and A9 with $\mathsf{enableOutputs}=1$ when $v\neq 0$ . Conditions A1, A2, A4 and A5 hold when $\mathsf{cm}^{\mathsf{old}}$ , $\mathsf{cmx}$ , $\mathsf{cv}^{\mathsf{net}}$ and $\mathsf{nf}^{\mathsf{old}}$ are computed from the witness by their definitions, and A6 and A7 hold for the key components of the receiver, whose address satisfies $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{g_{d}}$ (§3.3). The Action also carries a valid spend-authorisation signature under its $\mathsf{rk}$ . By Theorem 12.9, in “Authorisation of spends”, for an honestly generated address with $\mathsf{use\_qsk}=\mathsf{false}$ this requires that address’s spend authorising key $\mathsf{ask}$ , except with negligible probability. Consensus enforces no more than this per-Action restriction (ZIP 326, “Rationale for key-generation restrictions”).

Remark 9.4 (Effect on the Orchard pool).

For the Orchard pool, whose flag encoding forces $\mathsf{disableCrossAddress}=1$ , the pool-level effect is the one that ZIP 229, Abstract, states: outputs to the Orchard pool go to an address for which the transaction creator can authorise spends, which discourages economic activity between users within that pool. By the dummy-spend construction of the preceding remark, consensus does not prevent transfers between users within the Orchard pool (ZIP 326, “Rationale for key-generation restrictions”; ZIP 258, “Consensus rules from NU6.3 activation”, for the rule on Orchard-pool Actions).

Remark 9.5 (Status).

The expanded receiver $(\mathsf{g_{d}},\mathsf{pk_{d}})$ , the meaning of $\mathsf{enableCrossAddress}$ that A10 formalises, and the eight-input primary input with $\mathsf{disableCrossAddress}=1-\mathsf{enableCrossAddress}$ are specified in the protocol specification, §“Action Descriptions”; the flag encoding in ZIP 229; the Orchard-pool rule and the selection of the verifying key by upgrade in ZIP 258. The specification’s §“Action Statement (Orchard)” and the proof-validity rule of §“Action Descriptions” list the first seven primary inputs and conditions A1 to A9 only; Definition 9.2 follows §“Action Descriptions” for the rest. The specification names the conditions; the numbering A1 to A10 is this volume’s. ZIP 2006, to which the specification refers for the restriction, is a reserved number without content and is not cited for content.

Remark 9.6 (Sign of $\mathsf{ak}^{\mathbb{P}}$ ).

The statement does not constrain the sign of the witnessed point $\mathsf{ak}^{\mathbb{P}}$ . Condition A7 reads only $\mathsf{Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}})$ , which is the same for $\mathsf{ak}^{\mathbb{P}}$ and $-\mathsf{ak}^{\mathbb{P}}$ (Lemma 2.4), so the even- $y$ normalisation of key generation (“The spending key and the spend-side secrets”, §3.1) is not enforced by the proof (protocol specification, §“Action Statement (Orchard)”, note on the sign of the spend validating key). Theorem 12.9, in “Authorisation of spends”, treats both signs.

Remark 9.7 ( $\bot$ -weakened conditions).

Conditions A1, A2, A3 and A7 are the specification’s $\bot$ -weakened forms: each holds when the Sinsemilla instance it evaluates, $\mathsf{NoteCommit}$ , the hash of $\mathsf{MerkleCRH}$ or $\mathsf{Commit}^{\mathsf{ivk}}$ , returns $\bot$ on the witnessed input, for A3 on some input of the fold, because the circuit evaluates Sinsemilla with incomplete addition and cannot exclude its exceptional cases (protocol specification, §“Action Statement (Orchard)”, note on $\bot$ outputs and note on the Merkle path validity check; §“Merkle Path Validity”, notes on Orchard). The relation is therefore the disjunction, not the plain conjunction. The weakening costs a negligible term. A witness that satisfies A1 or A2 only through $\bot$ contains a $1086$ -bit message, $M^{\mathsf{old}}$ or $M^{\mathsf{new}}$ , on which $\mathsf{SinsemillaHashToPoint}(\texttt{z.cash:Orchard-NoteCommit-M},\cdot)$ returns $\bot$ ; one that satisfies A3 only through $\bot$ contains a $520$ -bit message on which $\mathsf{SinsemillaHash}(\texttt{z.cash:Orchard-MerkleCRH},\cdot)$ returns $\bot$ ; one that satisfies A7 only through $\bot$ contains the $510$ -bit message $\mathrm{LE}_{255}(\mathsf{Extract}_{\mathbb{P}}(\mathsf{ak}^{\mathbb{P}}))\,\|% \,\mathrm{LE}_{255}(\mathsf{nk})$ with the same property for the domain z.cash:Orchard-CommitIvk-M (§2.4). An efficient algorithm that runs an adversary together with the extractor of Assumption 9.11 and outputs such a message succeeds with negligible probability by Proposition 2.24(iii), which turns the message into a non-trivial discrete-logarithm relation among the $\mathsf{GroupHash}$ generators, under Assumptions 2.22 and 2.8. For the witnesses extracted from accepted proofs, A1, A2, A3 and A7 therefore hold in their unweakened forms, without the $\bot$ case, except with negligible probability.

Remark 9.8 (What the statement does not check).

(i)

No condition involves $\mathsf{ask}$ . The point $\mathsf{ak}^{\mathbb{P}}=[\mathsf{ask}]\,G^{\mathsf{SpendAuth}}$ is computed at key generation, outside the statement, and $\mathsf{ask}$ is not a witness. Conditions A6 and A7 relate $\mathsf{rk}$ and the address to the witnessed $\mathsf{ak}^{\mathbb{P}}$ , and the spend-authorisation signature under $\mathsf{rk}$ supplies knowledge of the signing key; Theorem 12.9 combines the two.
(ii)

The trapdoors $\mathsf{rcm}^{\mathsf{old}}$ and $\mathsf{rcm}^{\mathsf{new}}$ and the elements $\psi^{\mathsf{old}}$ and $\psi^{\mathsf{new}}$ are free witnesses: no condition checks that $\mathsf{rcm}$ and $\psi$ were derived from $\mathsf{rseed}$ as in “The note seed” (§4.3). The sender computes that derivation; the recipient checks it, in “Trial decryption and note acceptance” (§10.4), and consensus checks it only for coinbase outputs (“Chain state and pool rules”, §11.4). Hence, in the deployed protocol, the hashed $\mathsf{rcm}$ adds no binding: against an adversary able to compute discrete logarithms among the bases of $\mathsf{NoteCommit}$ , $\mathsf{NoteCommit}$ is not binding, and such an adversary can open one commitment to two distinct notes (ZIP 2005, Rationale, “Attacks against binding of note commitments”). The volume claims nothing further in that setting.
(iii)

The statement reads none of the Action’s note-encryption fields, which “Note encryption” (§10) constructs; the specification records that the absence of a check on the ephemeral key is intentional (§“Action Statement (Orchard)”, note).

Remark 9.9 (Key source).

The statement takes the key components $(\mathsf{ak}^{\mathbb{P}},\mathsf{nk},\mathsf{r_{ivk}})$ as witnesses and checks them only through A5, A6 and A7. It therefore applies equally to key components whose $\mathsf{ak}^{\mathbb{P}}$ and $\mathsf{r_{ivk}}$ come from the alternative source of ZIP 2005 (“Changes to the Protocol Specification”, §4.2.3 “Orchard Key Components”) cited in “The spending key and the spend-side secrets” (§3.1). The key-derived results of the volume, namely Proposition 3.18, Assumption 3.13, Propositions 3.17, 6.10 and 10.6, and the hypotheses on honest key generation of Theorems 12.9 and 12.12, remain restricted to keys with $\mathsf{use\_qsk}=\mathsf{false}$ .

Table 5 is the requirement map of the volume. For each requirement of “Requirements on a shielded payment” (§1.4) it lists the soundness content, with the conditions, the checks outside the proof and the results that discharge it, and the hiding content, with the results that discharge it.

Requirement	Soundness	Hiding
R1, hidden representation of value	A1 and A2 bind the consumed and the created note to their commitments (Proposition 4.5)	commitment hiding (Propositions 4.5 and 4.8); value-commitment hiding (§8.1); indistinguishability of real and dummy Actions (Theorem 12.12)
R2, membership without identification	A3 with the anchor rule of “Anchors” (Proposition 5.9)	zero knowledge of the proof (Assumption 9.14) with a locally computed authentication path (Lemma 5.15), composed in Theorem 12.12
R3, no second consumption	A5 with the nullifier-set rule (Theorem 12.6)	nullifier unlinkability (Proposition 6.10)
R4, conservation	A4 with the binding signature (Theorem 12.4)	value-commitment hiding (Theorem 12.12)
R5, spend authority	A6 and A7 with the spend-authorisation signature (Theorem 12.9) and bundle binding (Proposition 11.10)	none: R5 has a soundness part only
Flags	A8 to A10 serve no requirement of their own: they tie the hidden values and receivers to the public flags of §9.1	—

Table 5: The requirement map: for each requirement of §1.4, the conditions of Definition 9.2, the checks outside the proof and the results that discharge its soundness part, and the results that discharge its hiding part. It is the only requirement map of the volume.

Refer to caption — Figure 3: The Action statement of Definition 9.2. The auxiliary input is on the left, coloured by group as in the legend; the primary input is on the right; conditions A1 to A10 are in the centre, ordered by the side of the Action they constrain rather than by number. Each condition has an edge to every variable it reads; the edge from $\mathsf{nf}^{\mathsf{old}}$ to A2 carries $\rho^{\mathsf{new}}:=\mathsf{nf}^{\mathsf{old}}$ . Each condition is tagged with the requirement of §1.4 that it serves, or with “flags” for A8 to A10, and, where one exists, with the check outside the proof that completes it: the anchor rule for A3, the nullifier-set rule for A5, the binding signature for A4, and the spend-authorisation signature for A6 and A7.

9.3 The Action circuit and the Halo 2 proof

The Action statement of Definition 9.2 is a relation and prescribes no computation. The post-NU6.3 Action circuit is one fixed PLONKish circuit (Halo 2 Guide, §“PLONKish arithmetisation”) whose constraints are designed to encode the typing and conditions A1 to A10; that every satisfying assignment yields a witness of $\mathcal{R}_{\mathsf{Action}}$ is part of Assumption 9.11 below. The same circuit serves every Action. Its instance is the encoding of the eight primary inputs of Definition 9.2, bound to the proof as in the Halo 2 Guide, §“Instance columns and binding the public statement”; this instance is the only Orchard-specific part of the proof system constructed in this volume. Proofs are Halo 2 proofs (Halo 2 Guide, §“The Halo 2 proof system” and §“The complete Halo 2 protocol”; protocol specification, §“Zero-Knowledge Proving System”; ZIP 229, Abstract): a PLONKish polynomial interactive oracle proof compiled with the inner-product polynomial commitment and made non-interactive by the Fiat–Shamir transform, with no trusted setup.

The circuit’s native field is $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , the base field of the Pallas group, so the Pallas point operations of A1 to A10 are arithmetic in the native field. The proof’s polynomial commitments lie in the Vesta group $\mathbb{G}_{\mathsf{Vesta}}$ , the group of points of the curve $y^{2}=x^{3}+5$ over $\mathbb{F}_{p_{\mathsf{Vesta}}}$ , which has prime order $p_{\mathsf{Pallas}}$ (§2.1; Math Guide, §“Base fields, scalar fields, and the Pasta cycle”); the committed polynomials therefore have coefficients in $\mathbb{F}_{p_{\mathsf{Pallas}}}$ . The Pallas group carries the protocol’s keys, commitments, signatures and note encryption; the Vesta group carries only the proof’s commitments.

The circuit has $2^{11}$ rows and a constraint-degree bound of $9$ across its gates and its permutation and lookup identities (Halo 2 Guide, §“From statement to circuit: arithmetisation in practice”). Both are cited constants; in this volume they enter only the Schwartz–Zippel term of the first supporting analysis below.

Every Action of either pool, whatever it consumes or creates, dummy sides included, is an instance of the same relation and circuit. The proofs of a bundle’s Actions are aggregated into one proof, encoded once per bundle, which the verifier checks against the primary inputs of all the bundle’s Actions and the verifying key; each Action carries its own spend-authorisation signature (protocol specification, §“Action Transfers and their Descriptions” and §“Action Descriptions”, note on proof aggregation; ZIP 229, “Transaction Format”). The verification procedure is stated in “Verification of a transaction” (§11.6).

Both pools use the post-NU6.3 circuit and its proving and verifying keys; the pools are distinguished by their note commitment trees, nullifier sets, value pool balances and component position in the transaction, not by circuits (ZIP 229, Abstract, and Rationale, “Reuse of the Orchard protocol with minimal changes”). Consensus selects the Action verifying key by network upgrade (protocol specification, §“Action Descriptions”, consensus rules). The key in force for every Action, in either pool and in version $5$ and version $6$ transactions alike, is the post-NU6.3 verifying key, named by upgrade and not by pool (ZIP 258, “Consensus rules from NU6.3 activation”).

Assumption 9.10 (Discrete logarithms on Vesta).

For every classical probabilistic polynomial-time algorithm, given a generator $G$ of $\mathbb{G}_{\mathsf{Vesta}}$ and $[s]G$ for $s$ uniform in $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , the probability of outputting $s$ is negligible (Crypto Guide, §“Standing assumptions”, Remark “Standing assumptions for the sequel”, item 1, for the Vesta curve). Concretely, the best known classical attack costs about $2^{126}$ group operations (Crypto Guide, §“Instantiation on elliptic curves; the Pasta curves”, Proposition “The Pasta curves against the criteria”); the level is cited, not recomputed. The volume uses this assumption only in the extraction analysis of the inner-product commitment that supports Assumption 9.11 (the second supporting analysis below).

Assumption 9.11 (Knowledge soundness of the Action proof).

Let the hash of the Fiat–Shamir transform of the proof system be modelled as a random oracle. For every efficient adversary $\mathcal{A}$ that outputs primary inputs $\mathsf{pub}_{1},\dots,\mathsf{pub}_{n}$ and an aggregate proof $\pi$ , there is an efficient extractor $\mathcal{E}$ , with access to $\mathcal{A}$ and to its random-oracle queries, that outputs auxiliary inputs $\mathsf{aux}_{1},\dots,\mathsf{aux}_{n}$ such that the probability of the event

	$\pi$ is accepted for $(\mathsf{pub}_{1},\dots,\mathsf{pub}_{n})$ under the post-NU6.3 verifying key
	$\displaystyle\text{and }(\mathsf{pub}_{i},\mathsf{aux}_{i})\notin\mathcal{R}_{% \mathsf{Action}}\text{ for some }i$

is negligible. This is the knowledge-soundness clause of the Crypto Guide’s Definition “SNARK” (§“SNARKs: succinct non-interactive arguments of knowledge”) for the relation $\mathcal{R}_{\mathsf{Action}}$ of Definition 9.2. It includes that every satisfying assignment of the post-NU6.3 circuit yields a witness of $\mathcal{R}_{\mathsf{Action}}$ , for which the specification requires canonical decompositions of the scalar of A5 and of the scalar $\mathsf{ivk}$ in $[\mathsf{ivk}]\,\mathsf{g_{d}}^{\mathsf{old}}$ (protocol specification, §“Action Statement (Orchard)”, note on canonical scalar decompositions).

Assumption 9.11 is an assumption, not a proved result. Its status is designed but unspecified: bounds exist for the analysed protocol, and no theorem carries them to the deployed Fiat–Shamir-compiled protocol (Halo 2 Guide, §“The algebraic group model”). The volume assumes the property, proves no bound and asserts no loss factor. The two supporting analyses that follow are cited, not re-proved, and not combined into a bound.

Remark 9.12 (Supporting analysis (i): a Schwartz–Zippel term).

A non-zero gap polynomial $D$ over $\mathbb{F}_{p_{\mathsf{Pallas}}}$ , fixed by the prover’s commitments before the challenge is drawn, vanishes at a uniform challenge with probability at most $\deg D/p_{\mathsf{Pallas}}$ (Halo 2 Guide, §“Why checking one random point is a proof”). At the Orchard parameters, $2^{11}$ rows and constraint-degree bound $9$ , the constraint expression has degree below $9\cdot 2^{11}$ , and so does the committed quotient, of $8$ chunks of degree below $2^{11}$ , times the vanishing polynomial of degree $2^{11}$ (Halo 2 Guide, §“The complete Halo 2 protocol”, Phase 4). Hence $\deg D<9\cdot 2^{11}=18432$ , and the term is below $18432/p_{\mathsf{Pallas}}<2^{-239}$ . The term bounds one check at one challenge and is not a security level of the proof: the complete protocol has further randomised checks, and under the Fiat–Shamir transform an adversary may retry challenges, one hash query per retry (Halo 2 Guide, §“Removing the verifier: the Fiat–Shamir transform”).

Remark 9.13 (Supporting analysis (ii): extraction for the inner-product commitment).

The inner-product polynomial commitment, whose commitments lie in $\mathbb{G}_{\mathsf{Vesta}}$ , has an interactive opening protocol that is knowledge-sound under the discrete-logarithm assumption in that group, Assumption 9.10, with an expected-polynomial-time tree extractor (Halo 2 Guide, §“The inner-product polynomial commitment”, Theorem “Knowledge soundness of the opening protocol”). The Fiat–Shamir-compiled argument inherits the interactive extraction bound only up to a loss in the adversary’s random-oracle query count (§“From the interactive extractor to the non-interactive argument”), and the tighter analyses in the algebraic group model are proved for the analysed protocol, not for the deployed transcript (§“The algebraic group model”). No loss factor is asserted.

Assumption 9.14 (Zero knowledge of the Action proof).

Let the hash of the Fiat–Shamir transform be modelled as a programmable random oracle. There is an efficient simulator that, given only the primary inputs $\mathsf{pub}_{1},\dots,\mathsf{pub}_{n}$ of a bundle and programming the random oracle, outputs an aggregate proof whose distribution is statistically indistinguishable from that of an honestly generated proof for any $\mathsf{aux}_{1},\dots,\mathsf{aux}_{n}$ with $(\mathsf{pub}_{i},\mathsf{aux}_{i})\in\mathcal{R}_{\mathsf{Action}}$ for every $i$ : every distinguisher that makes polynomially many random-oracle queries, whatever its running time, has negligible advantage. This is zero knowledge of statistical grade in the non-interactive, random-oracle form of the Crypto Guide’s Definition “Zero knowledge” (§“The simulation paradigm and zero knowledge”).

Assumption 9.14 is an assumption, not a proved result. The Halo 2 Guide, §“Zero knowledge: hiding the witness in Halo 2”, records honest-verifier zero knowledge of the interactive protocol and zero knowledge of its Fiat–Shamir compilation in the programmable random-oracle model, subject to its composition and Fiat–Shamir hypotheses, without reproving it. Assumptions 9.11 and 9.14 are the two assumptions on the Action proof that “Security” (§12) composes with the propositions of the preceding sections.