VI Wallet Guide: The Zcash wallet layer: keys, transactions, and light-client synchronisation 11 Transaction construction 13 The transaction lifecycle

12 Partially created transactions (PCZT)

This section states the protocol by which the construction, proving and authorisation of one transaction are divided among several parties (ZIP 374). It defines the partially created transaction, its versions and the kinds of its fields; the roles that act on it and the modification state they maintain; its fields, its canonical empty bundles and its encoding; the version- $2$ rules for deferred anchors and the Ironwood bundle; construction and IO finalisation; signing, with the theorem that a Signer’s signatures authorise exactly what it checked; proving; combining and redaction, with the order independence of proving and signing and the data a PCZT discloses; and spend finalisation and extraction.

12.1 The PCZT and its requirements

Definition 12.1 (Partially created transaction).

A partially created transaction (PCZT) of one transaction is a value of the typed record of §12.3 for one PCZT version, exchanged among the parties to the creation of that transaction. It carries the data each role needs for its step (adding inputs and outputs, proving, signing, extracting) and accumulates proofs and signatures until the transaction is complete; since it carries all data a signer needs, a signer can be offline. A PCZT consists of a Global record and one bundle per protocol: transparent, Sapling, Orchard and, from version $2$ , Ironwood. Every bundle is present in every PCZT, empty bundles included, because metadata of a protocol may have to be held before it is known whether that protocol has inputs or outputs (ZIP 374, “Abstract”, “Specification” and “Structure”).

The PCZT protocol is specified (Definition 1.1) in ZIP 374, Revision $0$ , whose status is that of Table 1; no consensus rule depends on it. It covers transactions of versions $5$ and $6$ only: it supports neither Sprout nor version $4$ or earlier, since version $4$ predates the ZIP 244 digest and several of the role separations of this section, the independence of proving from signing in particular, fail for it (ZIP 374, “Specification”). The protocol serves signing devices that hold spending keys but can neither compute proofs nor hold a whole transaction; proof delegation, the prover needing note data and the full viewing key but no spending key; transactions with several signers (threshold signing, the transparent multisignature wallets of ZIP 48) or several contributors of inputs, whose parallel contributions are merged; and, for version $6$ , pre-authorisation, in which the signatures precede the choice of anchors, the witnesses and the proofs (ZIP 374, “Motivation”).

ZIP 374, “Requirements”, states six requirements, recorded here as the ZIP’s and not proved as such:

(R1)

every intermediate state of the creation of a version- $5$ or version- $6$ transaction is representable, and adding inputs and outputs, finalising the input and output set, attaching lookup data, proving, signing, merging parallel contributions and extracting are each performable by distinct entities, in an order constrained only by data dependencies;
(R2)

no spending key material is required, the keys of dummy spends excepted, which authorise nothing of value and are removable before any Signer sees the PCZT;
(R3)

a Signer determines from the PCZT alone what it authorises (amounts, recipients, and the correspondence between the fields it signs and the values shown to its user), and data a Signer does not need is removable;
(R4)

merging two PCZTs of the same transaction is deterministic and fails on any conflict;
(R5)

for version $6$ , signatures can be produced while anchors, witnesses and proofs are absent, and supplying them later leaves the signatures valid;
(R6)

the encoding is compact and strictly versioned, so that no data is read under another version’s rules.

Requirement (R3) is made a theorem in §12.7, (R5) a proposition in §12.5 and (R4) a construction in §12.9.

Definition 12.2 (PCZT versions).

Version $1$ represents transactions of version $5$ (ZIP 225); version $2$ represents transactions of versions $5$ and $6$ (ZIP 229). The PCZT version does not fix the transaction version: a version- $2$ PCZT carries a transaction of version $5$ or $6$ , subject to the per-field rules, and a version- $1$ PCZT only one of version $5$ . Relative to version $1$ , version $2$ adds the Ironwood bundle; a note version in $\{\mathsf{V2},\mathsf{V3}\}$ per Orchard-protocol bundle; anchors that may be absent; and an encoding that writes a bundle equal to its slot’s canonical empty bundle as absent (ZIP 374, “Versioning”). The fields are made exact in §12.3 and the encoding in §12.4.

No field can be added within a version: the encoding is positional, and a parser cannot skip a field it does not know. A PCZT has no non-proprietary key–value maps, so every field of a version is known in advance and a Signer’s view of a PCZT is complete; the proprietary maps are the only extension point within a version, and MUST be used for internal processes only. The format evolves by new versions, which the four-byte version of the header distinguishes. Implementations SHOULD parse every specified version and SHOULD emit the oldest version able to represent a PCZT’s state when interoperating with entities that may lack the newest; conversion between versions is lossless exactly when the target version represents the state (ZIP 374, “Extensibility” and “Proprietary Use fields”). The states that version $1$ cannot represent are listed in §12.4.

Definition 12.3 (Field kinds of a PCZT).

Every field of a PCZT is of one of three kinds (ZIP 374, “Structure”):

(i)

effecting data, required fields that are part of the final transaction and are always present, committed to by the signature digest (Ironwood Guide, §“Transaction digests and signatures”);
(ii)

authorising data, initially absent and filled as roles act: proofs, signatures, binding signing keys and, in a transaction of version $6$ , the anchors;
(iii)

context data, which enables roles to act and never enters the final transaction: note openings, keys, witnesses, derivation records and address strings.

In a transaction of version $5$ the anchors are effecting data (ZIP 374, “Anchors and pre-authorization”).

The signature digest commits to every non-transparent effecting field as soon as any input is signed, so no shielded analogue of the transparent hash types that leave inputs or outputs open exists. The transparent and the shielded modifiable flags of §12.2 are therefore kept apart, so that a purely transparent PCZT behaves as a partially signed Bitcoin transaction of BIP 174 and BIP 370 does (ZIP 374, “Separate Shielded Modifiable Flag from Transparent Modifiable Flags”).

12.2 Roles and the modification state

Definition 12.4 (Roles).

A role is a partial map from PCZTs to PCZTs, undefined where the role fails; a role that draws randomness is a family of such maps indexed by its random coins, and the Combiner maps a finite set of PCZTs to one. The roles, with the parties that may execute them (ZIP 374, “Specification” and “Roles”), are:

(1)

Creator (a single entity): chooses the transaction version and consensus branch identifier, and sets the Global fields and the empty bundles;
(2)

Constructor: adds transparent inputs and outputs, Sapling spends and outputs, and Orchard-protocol Actions;
(3)

IO Finalizer (anyone): declares the input and output set final, computes the binding signing keys and signs dummy spends;
(4)

Updater (anyone): adds data later roles need, such as derivation records, full viewing keys, witnesses and, for version $6$ , anchors;
(5)

Redactor (anyone): removes data later roles do not need;
(6)

Prover (a holder of the note data): adds proofs;
(7)

Signer (a holder of a spending key): adds signatures;
(8)

Combiner (anyone): merges PCZTs;
(9)

Spend Finalizer (anyone): assembles transparent unlocking scripts;
(10)

Transaction Extractor (anyone): checks completeness and produces the transaction.

The lifecycle runs the Creator, the Constructors, the IO Finalizer and the Updaters, then the Provers and the Signers, the Combiners and the Redactors, and last the Spend Finalizer and the Transaction Extractor. A Verifier is not a role: it is an inspection of a PCZT’s internal consistency, for example the relations of §12.7, performed on behalf of an entity, such as a hardware signer, that trusts it and cannot perform the checks itself (ZIP 374, “Verifier”).

Definition 12.5 (Modification state).

The Global field $\mathsf{tx\_modifiable}\in\{0,1\}^{8}$ , bits numbered from the least significant, has the following bits (ZIP 374, “Global” and “Combiner”):

(i)

bit $0$ , transparent inputs modifiable, and bit $1$ , transparent outputs modifiable: each set by the Creator, checked, and possibly cleared, by a Constructor before it adds an input or output of its kind, cleared by the IO Finalizer when shielded spends or outputs exist, and merged by AND;
(ii)

bit $2$ , a signature with hash type $\mathsf{SIGHASH\_SINGLE}$ is present: cleared by the Creator, set by a Signer that adds such a signature, read by a Constructor, which then preserves the pairing of each such input with its output, and merged by OR;
(iii)

bits $3$ to $6$ : zero, which ZIP 374 requires in version $1$ and the Combiner requires of every PCZT it merges;
(iv)

bit $7$ , shielded modifiable: set by the Creator, checked, and possibly cleared, by a Constructor before it adds a shielded spend or output, cleared by the IO Finalizer when shielded spends or outputs exist and by every Signer, and merged by AND.

The Creator’s value is therefore $1000\,0011$ in binary.

Signing freezes the effects. After adding a shielded signature a Signer clears bits $0$ , $1$ and $7$ : every shielded signature, spend-authorisation and binding alike, is on the one signature digest, which commits to all effecting data (Ironwood Guide, §“Transaction digests and signatures”, Proposition “Bundle binding”), and no shielded hash type leaves an input or output open. After adding a transparent signature it clears bit $0$ unless the hash type has $\mathsf{ANYONECANPAY}$ , clears bit $1$ unless its base type is $\mathsf{NONE}$ , sets bit $2$ if its base type is $\mathsf{SINGLE}$ , with or without $\mathsf{ANYONECANPAY}$ , and clears bit $7$ (ZIP 374, “Global” and “Signer”).

A wallet executing a plan (Definition 11.2) acts as Creator, Constructor, IO Finalizer and Updater. It builds the bundles by Construction 11.18 and then, as Updater, attaches to each non-dummy Orchard-pool, Ironwood-pool and Sapling spend the derivation record of §12.3, with the seed fingerprint of Construction 2.2 and the path $(32^{\prime},\mathit{coin\_type}^{\prime},\mathit{account}^{\prime})$ of Definition 2.7; to each transparent input the BIP 44 path $(44^{\prime},\mathit{coin\_type}^{\prime},\mathit{account}^{\prime},\mathit{% scope},\mathit{index})$ , the last two components non-hardened; and to each output that pays a payment of the plan (Definition 11.1) that payment’s address string as $\mathsf{user\_address}$ , which a Signer checks (§12.7) (ZIP 374, “Updater” and “Zip32Derivation”; ZIP 32; BIP 44).

Refer to caption — Figure 5: The roles of a PCZT (Definition 12.4), with the fields each writes, the secrets it needs and the bits of $\mathsf{tx\_modifiable}$ it clears (Definition 12.5). Red marks the one role that needs the spend authorising key $\mathsf{ask}$ , amber the role that needs the value-commitment trapdoors and the dummy keys, blue the role that needs the note data and $\mathsf{fvk}$ but no $\mathsf{ask}$ , and grey the roles that need no secret. The Prover and the Signer run in either order or in parallel on copies joined by the Combiner; what each recipient learns is stated in §12.9.

12.3 Fields

Definition 12.6 (PCZT fields).

Types. The types $\mathsf{u8}$ , $\mathsf{u32}$ and $\mathsf{u64}$ are the unsigned integers of that width, $\mathsf{i128}$ the signed integers of $128$ bits and $\mathsf{bool}=\{\mathsf{false},\mathsf{true}\}$ ; $\mathbb{B}^{n}$ is the set of byte strings of length $n$ , $T^{n}$ the sequences of $n$ elements of $T$ , and $T_{1}\times T_{2}$ the pairs; $\mathsf{Opt}(T)$ is $T$ together with an absent value $\bot$ ; $\mathsf{List}(T)$ is the finite sequences over $T$ , $\mathsf{Map}(K,V)$ the finite maps from $K$ to $V$ , and $\mathsf{Str}$ the UTF-8 strings; $\mathsf{Enum}\{A_{0},A_{1},\dots\}$ is a set of tags, $A_{i}$ with index $i$ . A derivation record is a value of $D:=\mathbb{B}^{32}\times\mathsf{List}(\mathsf{u32})$ , a seed fingerprint (Construction 2.2) and a derivation path, an index with bit $31$ set being hardened. Let $P:=\mathsf{Map}(\mathsf{Str},\mathsf{List}(\mathsf{u8}))$ , the type of a proprietary map. Each record below lists its fields in order, the order of the encoding (§12.4); a field marked (v1) or (v2) is present only in that version (ZIP 374, “Structure” and the sections of each record).

Global.: $\mathsf{tx\_version}\in\mathsf{u32}$ , which is $5$ in version $1$ and $5$ or $6$ in version $2$ ; $\mathsf{version\_group\_id}\in\mathsf{u32}$ , consistent with it (ZIP 225, ZIP 229); $\mathsf{consensus\_branch\_id}\in\mathsf{u32}$ , which for $\mathsf{tx\_version}=6$ names an upgrade at which version $6$ is supported, NU6.3 or later, that of NU7 being 0x77190AD9 (ZIP 259, “NU7 network constants”); $\mathsf{fallback\_lock\_time}\in\mathsf{Opt}(\mathsf{u32})$ , absence meaning $0$ ; $\mathsf{expiry\_height}\in\mathsf{u32}$ (ZIP 203); $\mathsf{coin\_type}\in\mathsf{u32}$ , the SLIP 44 coin type, which is not part of the transaction and against which roles check network-specific data; $\mathsf{tx\_modifiable}\in\mathsf{u8}$ (Definition 12.5); $\mathsf{proprietary}\in P$ .
Transparent bundle.: $\mathsf{inputs}\in\mathsf{List}(\mathrm{TI})$ and $\mathsf{outputs}\in\mathsf{List}(\mathrm{TO})$ . An input $\mathrm{TI}$ : $\mathsf{prevout\_txid}\in\mathbb{B}^{32}$ ; $\mathsf{prevout\_index}\in\mathsf{u32}$ ; $\mathsf{sequence}\in\mathsf{Opt}(\mathsf{u32})$ , absence meaning $2^{32}-1$ ; $\mathsf{required\_time\_lock\_time}\in\mathsf{Opt}(\mathsf{u32})$ , at least $500{,}000{,}000$ ; $\mathsf{required\_height\_lock\_time}\in\mathsf{Opt}(\mathsf{u32})$ , in $\{1,\dots,499{,}999{,}999\}$ ; $\mathsf{script\_sig}\in\mathsf{Opt}(\mathsf{List}(\mathsf{u8}))$ ; $\mathsf{value}\in\mathsf{u64}$ ; $\mathsf{script\_pubkey}\in\mathsf{List}(\mathsf{u8})$ ; $\mathsf{redeem\_script}\in\mathsf{Opt}(\mathsf{List}(\mathsf{u8}))$ ; $\mathsf{partial\_signatures}\in\mathsf{Map}(\mathbb{B}^{33},\mathsf{List}(% \mathsf{u8}))$ ; $\mathsf{sighash\_type}\in\mathsf{u8}$ ; $\mathsf{bip32\_derivation}\in\mathsf{Map}(\mathbb{B}^{33},D)$ ; four preimage maps, for RIPEMD160, SHA256, HASH160 and HASH256, of types $\mathsf{Map}(\mathbb{B}^{20},\mathsf{List}(\mathsf{u8}))$ , $\mathsf{Map}(\mathbb{B}^{32},\mathsf{List}(\mathsf{u8}))$ , $\mathsf{Map}(\mathbb{B}^{20},\mathsf{List}(\mathsf{u8}))$ and $\mathsf{Map}(\mathbb{B}^{32},\mathsf{List}(\mathsf{u8}))$ in that order; $\mathsf{proprietary}\in P$ . An output $\mathrm{TO}$ : $\mathsf{value}\in\mathsf{u64}$ ; $\mathsf{script\_pubkey}\in\mathsf{List}(\mathsf{u8})$ ; $\mathsf{redeem\_script}\in\mathsf{Opt}(\mathsf{List}(\mathsf{u8}))$ ; $\mathsf{bip32\_derivation}\in\mathsf{Map}(\mathbb{B}^{33},D)$ ; $\mathsf{user\_address}\in\mathsf{Opt}(\mathsf{Str})$ ; $\mathsf{proprietary}\in P$ .
Sapling bundle.: $\mathsf{spends}\in\mathsf{List}(\mathrm{SS})$ ; $\mathsf{outputs}\in\mathsf{List}(\mathrm{SO})$ ; $\mathsf{value\_sum}\in\mathsf{i128}$ , the net value of the spends minus the outputs; $\mathsf{anchor}\in\mathbb{B}^{32}$ (v1) or $\mathsf{Opt}(\mathbb{B}^{32})$ (v2); $\mathsf{bsk}\in\mathsf{Opt}(\mathbb{B}^{32})$ . A spend $\mathrm{SS}$ : effecting $\mathsf{cv},\mathsf{nf},\mathsf{rk}\in\mathbb{B}^{32}$ ; $\mathsf{zkproof}\in\mathsf{Opt}(\mathbb{B}^{192})$ ; $\mathsf{spend\_auth\_sig}\in\mathsf{Opt}(\mathbb{B}^{64})$ ; $\mathsf{recipient}\in\mathsf{Opt}(\mathbb{B}^{43})$ ; $\mathsf{value}\in\mathsf{Opt}(\mathsf{u64})$ ; $\mathsf{rcm}\in\mathsf{Opt}(\mathbb{B}^{32})$ and $\mathsf{rseed}\in\mathsf{Opt}(\mathbb{B}^{32})$ , at most one set, by whether the note predates ZIP 212; $\mathsf{rcv}\in\mathsf{Opt}(\mathbb{B}^{32})$ ; the proof generation key $(\mathsf{ak},\mathsf{nsk})\in\mathsf{Opt}(\mathbb{B}^{32}\times\mathbb{B}^{32})$ ; $\mathsf{witness}\in\mathsf{Opt}(\mathsf{u32}\times(\mathbb{B}^{32})^{32})$ ; $\alpha\in\mathsf{Opt}(\mathbb{B}^{32})$ ; a derivation record in $\mathsf{Opt}(D)$ ; $\mathsf{dummy\_ask}\in\mathsf{Opt}(\mathbb{B}^{32})$ ; $\mathsf{proprietary}\in P$ . An output $\mathrm{SO}$ : effecting $\mathsf{cv},\mathsf{cmu},\mathsf{epk}\in\mathbb{B}^{32}$ and the ciphertexts $C_{\mathsf{enc}},C_{\mathsf{out}}\in\mathsf{List}(\mathsf{u8})$ , whose lengths depend on the transaction version; $\mathsf{zkproof}\in\mathsf{Opt}(\mathbb{B}^{192})$ ; $\mathsf{recipient}\in\mathsf{Opt}(\mathbb{B}^{43})$ ; $\mathsf{value}\in\mathsf{Opt}(\mathsf{u64})$ ; $\mathsf{rseed},\mathsf{rcv},\mathsf{ock}\in\mathsf{Opt}(\mathbb{B}^{32})$ ; a derivation record in $\mathsf{Opt}(D)$ ; $\mathsf{user\_address}\in\mathsf{Opt}(\mathsf{Str})$ ; $\mathsf{proprietary}\in P$ . The Sapling constructions are those of the protocol specification and are cited, not restated.
Orchard bundle.: $\mathsf{actions}\in\mathsf{List}(\mathrm{OA})$ ; $\mathsf{flags}\in\mathsf{u8}$ , with bit $0$ $\mathsf{enableSpends}$ , bit $1$ $\mathsf{enableOutputs}$ , bit $2$ $\mathsf{enableCrossAddress}$ (v2; zero in version $1$ and in the Orchard bundle of every transaction mined under NU6.3 or later, the rule of Construction 11.5), and bits $3$ to $7$ zero; $\mathsf{value\_sum}\in\mathsf{u64}\times\mathsf{bool}$ ; $\mathsf{anchor}\in\mathbb{B}^{32}$ (v1) or $\mathsf{Opt}(\mathbb{B}^{32})$ (v2); $\mathsf{note\_version}\in\mathsf{Enum}\{\mathsf{V2},\mathsf{V3}\}$ (v2), where $\mathsf{V2}$ is the note plaintext of ZIP 212, lead byte 0x02, and $\mathsf{V3}$ that of ZIP 2005, lead byte 0x03, which MUST be $\mathsf{V2}$ in the Orchard bundle and is implicitly $\mathsf{V2}$ in version $1$ ; $\mathsf{zkproof}\in\mathsf{Opt}(\mathsf{List}(\mathsf{u8}))$ , one proof for the bundle; $\mathsf{bsk}\in\mathsf{Opt}(\mathbb{B}^{32})$ . An Action $\mathrm{OA}$ : $\mathsf{cv}^{\mathsf{net}}\in\mathbb{B}^{32}$ ; a spend $\mathrm{OS}$ ; an output $\mathrm{OO}$ ; $\mathsf{rcv}\in\mathsf{Opt}(\mathbb{B}^{32})$ , one per Action, since an Action has one net value commitment (Ironwood Guide, §“Value commitments”). A spend $\mathrm{OS}$ : effecting $\mathsf{nf},\mathsf{rk}\in\mathbb{B}^{32}$ ; $\mathsf{spend\_auth\_sig}\in\mathsf{Opt}(\mathbb{B}^{64})$ ; $\mathsf{recipient}\in\mathsf{Opt}(\mathbb{B}^{43})$ , a raw Orchard address; $\mathsf{value}\in\mathsf{Opt}(\mathsf{u64})$ ; $\rho,\mathsf{rseed}\in\mathsf{Opt}(\mathbb{B}^{32})$ ; $\mathsf{fvk}\in\mathsf{Opt}(\mathbb{B}^{96})$ , the encoding of $(\mathsf{ak},\mathsf{nk},\mathsf{r_{ivk}})$ ; $\mathsf{witness}\in\mathsf{Opt}(\mathsf{u32}\times(\mathbb{B}^{32})^{32})$ , a position and a $32$ -level authentication path; $\alpha\in\mathsf{Opt}(\mathbb{B}^{32})$ ; a derivation record in $\mathsf{Opt}(D)$ ; $\mathsf{dummy\_sk}\in\mathsf{Opt}(\mathbb{B}^{32})$ ; $\mathsf{proprietary}\in P$ . In a transaction of version $6$ the witness may be absent until proving (§12.5). An output $\mathrm{OO}$ : effecting $\mathsf{cmx},\mathsf{epk}\in\mathbb{B}^{32}$ and $C_{\mathsf{enc}},C_{\mathsf{out}}\in\mathsf{List}(\mathsf{u8})$ ; $\mathsf{recipient}\in\mathsf{Opt}(\mathbb{B}^{43})$ ; $\mathsf{value}\in\mathsf{Opt}(\mathsf{u64})$ ; $\mathsf{rseed},\mathsf{ock}\in\mathsf{Opt}(\mathbb{B}^{32})$ ; a derivation record in $\mathsf{Opt}(D)$ ; $\mathsf{user\_address}\in\mathsf{Opt}(\mathsf{Str})$ ; $\mathsf{proprietary}\in P$ .
Ironwood bundle: (v2). The fields of the Orchard bundle, with $\mathsf{note\_version}=\mathsf{V3}$ and its anchor a root of the Ironwood note commitment tree (§12.5).

Which role sets, requires or clears each field is as ZIP 374 states per field; this section restates it where it defines a role.

Every transparent input’s $\mathsf{value}$ and $\mathsf{script\_pubkey}$ are required, not optional, because the signature digest commits to the value and script of every coin a transaction spends (ZIP 244, as amended by ZIP 229; Ironwood Guide, §“Transaction digests and signatures”), and the binding signatures are on that digest (ZIP 374, “TransparentInput”).

Remark 12.7 (The sign of an Orchard-protocol value sum).

The pair $\mathsf{value\_sum}=(m,b)$ denotes the net value of the bundle’s spends minus its outputs, but ZIP 374 does not state the meaning of $b$ : a gap in the specification. The reference implementation of ZIP 374 reads $b=\mathsf{true}$ as the net value $-m$ and $b=\mathsf{false}$ as $+m$ , and the canonical empty bundle has $(0,\mathsf{false})$ . This volume adopts that reading, and writes $v^{\mathsf{balance}}$ for the integer that a bundle’s $\mathsf{value\_sum}$ denotes; for Sapling it is the $\mathsf{i128}$ value itself.

A Signer MUST parse the $\mathsf{user\_address}$ of each output that carries one and confirm that it contains the output’s recipient, directly or as a receiver of a unified address (ZIP 374, “TransparentOutput”, “SaplingOutput” and “OrchardOutput”; Definition 3.7 and Construction 3.10). The anchors, witnesses and commitments that these fields carry are those of the Ironwood Guide, §“The note commitment tree”, with its subsections “Anchors” and “Authentication paths”; they are cited, not rebuilt.

Definition 12.8 (Canonical empty bundles).

The canonical empty bundle of each slot is (ZIP 374, “v2 Encoding”):

(i)

transparent: empty input and output lists;
(ii)

Sapling: empty spend and output lists, $\mathsf{value\_sum}=0$ , $\mathsf{anchor}=\bot$ , $\mathsf{bsk}=\bot$ ;
(iii)

Orchard: no Actions, $\mathsf{flags}=0000\,0011$ in binary (spends and outputs enabled), $\mathsf{value\_sum}=(0,\mathsf{false})$ , $\mathsf{anchor}=\bot$ , $\mathsf{note\_version}=\mathsf{V2}$ , $\mathsf{zkproof}=\mathsf{bsk}=\bot$ ;
(iv)

Ironwood: no Actions, $\mathsf{flags}=0000\,0111$ in binary (spends, outputs and cross-address transfers enabled), $\mathsf{value\_sum}=(0,\mathsf{false})$ , $\mathsf{anchor}=\bot$ , $\mathsf{note\_version}=\mathsf{V3}$ , $\mathsf{zkproof}=\mathsf{bsk}=\bot$ .

A bundle that differs from it in any field, its flags, note version or anchor included, is not canonical empty.

12.4 Encoding

Construction 12.9 (PCZT encoding).

The encoding of a PCZT of version $n$ is

\texttt{50 43 5a 54}\,\|\,\mathsf{I2LEOSP}_{32}(n)\,\|\,\mathit{body}_{n},

the first four bytes being the ASCII string PCZT. A string that does not begin with this $8$ -byte header is not a PCZT encoding, and a parser that meets an unknown version MUST NOT parse the remainder (ZIP 374, “Encoding”). The body is built from the following encodings of the types of Definition 12.6 (ZIP 374, “Data type encodings”):

(i)

$\mathsf{u8}$ : one raw byte;
(ii)

$\mathsf{u32}$ and $\mathsf{u64}$ : $\mathsf{varint}(x)$ , the digits of $x$ in base $128$ , least significant first, one per byte, with bit $7$ set on every byte but the last. Encoders MUST emit the shortest form. A $k$ -bit integer takes at most $\lceil k/7\rceil$ bytes, $5$ for $\mathsf{u32}$ and $10$ for $\mathsf{u64}$ , and in an encoding of that length the last byte contributes only the high $k\bmod 7$ bits, so the fifth byte of a $\mathsf{u32}$ is at most 0x0f; decoders MUST reject encodings that exceed either bound and MAY accept non-minimal encodings within them;
(iii)

$\mathsf{i128}$ : $\mathsf{varint}(\mathsf{zigzag}(x))$ , with $\mathsf{zigzag}(x)=2x$ for $x\geq 0$ and $2|x|-1$ for $x<0$ ;
(iv)

$\mathsf{bool}$ : the byte 0x00 for $\mathsf{false}$ or 0x01 for $\mathsf{true}$ , other bytes rejected;
(v)

$\mathbb{B}^{n}$ , $T^{n}$ and pairs: the concatenation of the elements, with no length prefix, so that a witness path is $1024$ raw bytes;
(vi)

$\mathsf{Opt}(T)$ : the byte 0x00 for $\bot$ , and 0x01 followed by the value otherwise, other tag bytes rejected;
(vii)

$\mathsf{List}(T)$ and $\mathsf{Str}$ : the varint of the number of elements, of bytes for a string, followed by the elements; invalid UTF-8 is rejected;
(viii)

$\mathsf{Map}(K,V)$ : the varint of the number of entries, followed by each key and its value. Encoders MUST emit the entries in strictly ascending lexicographic byte order of the unencoded keys, without duplicates; decoders MAY accept other orders and duplicates;
(ix)

$\mathsf{Enum}$ : the varint of the tag’s index;
(x)

a record: the concatenation of its fields in the order of Definition 12.6, without tags or padding, a field absent from version $n$ being omitted entirely.

Encoders MUST NOT emit data after the last field; decoders MAY ignore or reject it. Layout (ZIP 374, “v1 Encoding” and “v2 Encoding”): $\mathit{body}_{1}$ is the Global record followed by the transparent, Sapling and Orchard bundles, each Action encoded as $\mathsf{cv}^{\mathsf{net}}$ , spend, output, $\mathsf{rcv}$ . The body $\mathit{body}_{2}$ is the Global record followed by the four bundles, transparent, Sapling, Orchard and Ironwood, each as a value of $\mathsf{Opt}$ ; a bundle equal to its slot’s canonical empty bundle (Definition 12.8) MUST be encoded as absent and any other as present, and a parser MUST restore the canonical empty bundle from absence. Encoding in version $1$ MUST fail when $\mathsf{tx\_version}\neq 5$ , when the Ironwood bundle is not canonical empty, when the Orchard note version is not $\mathsf{V2}$ , or when an anchor required before signing a transaction of version $5$ is absent: these are the states version $1$ cannot represent.

Lemma 12.10 (Canonicity of the encoding).

For every version $n$ and every PCZT $P$ representable in version $n$ , exactly one byte string is an output for $P$ permitted to an encoder that obeys the MUST rules of Construction 12.9, and distinct PCZTs have distinct encodings. Canonicity is a property of encoder output: since decoders may accept non-minimal varints, unordered or repeated map entries and trailing data, several strings may decode to one PCZT.

Proof.

By induction on the type structure. Uniqueness. The permitted encoding of each primitive is a function of its value: the shortest base- $128$ representation is unique, its last byte non-zero unless the value is $0$ ; the map $\mathsf{zigzag}$ is a bijection from the integers onto the naturals; the tags of options, booleans and enumerations are fixed; the counts of lists and strings are determined by the value. A finite map admits exactly one strictly ascending order of its entries without duplicates, since lexicographic order on byte strings is total. A record concatenates uniquely encoded fields in a fixed order. In version $2$ the presence of each bundle is determined by equality with Definition 12.8, and no trailing data is permitted. Injectivity. Each encoding is self-delimiting given its type, being of fixed length or a count followed by self-delimiting elements, so a decoder that reads the fields in order recovers every value; an absent version- $2$ bundle is restored as the canonical empty bundle, the only bundle encoded as absent. The header fixes $n$ , so encodings of distinct versions differ as well. □

The canonical-empty rule is exact equality so that two copies of one PCZT encode identically whatever software produced them, and re-encoding cannot move a bundle between its present and absent forms (ZIP 374, “Omitting empty bundles in PCZT v2”).

Example 12.11 (A minimal version-2 PCZT).

The Creator’s PCZT (§12.6) for a transaction of version $6$ , with version group identifier 0xD884B698 (ZIP 229), consensus branch identifier 0x77190AD9 (NU7, ZIP 259), expiry height $10{,}000{,}000$ , coin type $133$ (Mainnet), no fallback lock time, no proprietary entries and every bundle canonical empty, encodes in version $2$ as the $32$ bytes of Table 6. With coin type $1$ the coin type takes the one byte 01, the total is $31$ bytes, and every later field moves one byte earlier: the position of a field depends on the values before it, which is why no field can be added within a version.

Offset	Bytes	Field
$0$	50 43 5a 54	header, PCZT
$4$	02 00 00 00	version $2$
$8$	06	$\mathsf{tx\_version}=6$
$9$	98 ed 92 c4 0d	$\mathsf{version\_group\_id}$
$14$	d9 95 e4 b8 07	$\mathsf{consensus\_branch\_id}$
$19$	00	$\mathsf{fallback\_lock\_time}=\bot$
$20$	80 ad e2 04	$\mathsf{expiry\_height}$
$24$	85 01	$\mathsf{coin\_type}=133$
$26$	83	$\mathsf{tx\_modifiable}$ , bits $0$ , $1$ , $7$
$27$	00	empty proprietary map
$28$ to $31$	00 00 00 00	four absent bundles

Table 6: The minimal version-

2

PCZT of Example 12.11: offset, bytes and field, in the encoding of Construction 12.9.

12.5 PCZT v2: deferred anchors and the Ironwood bundle

In version $2$ the Ironwood bundle carries the Ironwood-pool component of a transaction of version $6$ , with the structure, field meaning and role interactions of the Orchard bundle, the Ironwood pool being a second value pool of the Orchard protocol (ZIP 229; Ironwood Guide, §“The Orchard protocol and its two pools”). It differs in three respects: its $\mathsf{enableCrossAddress}$ bit is meaningful and normally $1$ ; its anchor is a root of the Ironwood note commitment tree, distinct from the Orchard tree; and its note version MUST be $\mathsf{V3}$ . Every role MUST reject a PCZT with $\mathsf{tx\_version}=5$ whose Ironwood bundle is not canonical empty (Definition 12.8) (ZIP 374, “IronwoodBundle (PCZT v2)”).

Definition 12.12 (Anchors and witnesses in version 2).

The following rules hold (ZIP 374, “Anchors and pre-authorization”).

(i)

For $\mathsf{tx\_version}=5$ , every shielded bundle’s anchor is set when the bundle’s first spend is added and never changes, since the version- $5$ digest commits to it.
(ii)

For $\mathsf{tx\_version}=6$ , which requires version $2$ , an anchor MAY be absent until proving; an Updater MAY set an absent anchor, or replace a set one, at any time before the Prover runs for that bundle; setting or replacing an anchor MUST clear every proof already in that bundle, the Sapling spends’ proofs or the Orchard-protocol bundle’s proof, since a proof takes the anchor as a primary input; and the witness of a Sapling or Orchard-protocol spend MAY be absent until proving, and is set by an Updater once known.
(iii)

Whenever a bundle has both an anchor and witnesses, the Updater that sets either MUST check that every witness of a spend of non-zero value roots to the anchor, and the Prover MUST check the same before proving.

Deferral is governed by the transaction version, not by the PCZT version: a transaction of version $5$ in a version- $2$ PCZT fixes its anchors as in version $1$ . Absence is an absent option, not an all-zero string, because zero is an element of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ and so a syntactically valid anchor (ZIP 374, “Optional anchors in PCZT v2”).

Proposition 12.13 (Deferred anchors).

Let $P$ be a PCZT of a transaction of version $6$ .

(i)

If every spend of $P$ is signed, replacing the anchor $\mathit{rt}$ of a bundle and its proof $\pi$ by any anchor $\mathit{rt}^{\prime}$ and a proof $\pi^{\prime}$ valid for it leaves every signature valid and the transaction identifier unchanged: re-anchoring needs only re-proving.
(ii)

A spend of an Orchard-protocol note whose creating transaction is not yet mined can be fully signed before that note is in the tree, and its signatures remain valid once an anchor, a witness and a proof are supplied: every field that the signature digest commits to is computable from the note data, and the anchor is not among them.

Neither holds for a transaction of version $5$ , and (ii) fails for a Sapling spend in version $6$ .

Proof.

(i) The version- $6$ digest and transaction identifier omit the anchors, which are authorising data (ZIP 229, “Anchor commitment (version 6)”), and by Ironwood Guide, §“Transaction digests and signatures”, Proposition “Bundle binding”, replacing $(\mathit{rt},\pi)$ by $(\mathit{rt}^{\prime},\pi^{\prime})$ changes neither the transaction identifier nor any signed message, so every signature remains valid.

(ii) The effecting fields of an Orchard-protocol spend are $\mathsf{nf}$ , $\mathsf{rk}$ and its Action’s $\mathsf{cv}^{\mathsf{net}}$ . The nullifier is $\mathsf{DeriveNullifier}_{\mathsf{nk}}(\rho,\psi,\mathsf{cm})$ (Ironwood Guide, §“The nullifier”), a function of the key and of note data, with $\rho$ fixed by the creating Action and $\psi$ and $\mathsf{cm}$ derived from $\mathsf{rseed}$ , $\rho$ , the address and the value; it does not depend on the note’s position. The key $\mathsf{rk}$ and the commitment $\mathsf{cv}^{\mathsf{net}}$ depend on keys, values and fresh randomness only.

For version $5$ the digest commits to the anchors (ZIP 244, “Signature Digest”), so replacing an anchor invalidates every signature, which refutes (i); and an anchor fixed before the note is in the tree is the root of a tree state that does not contain the note, for which no authentication path of the note exists except with negligible probability (Ironwood Guide, §“Anchors”, Proposition “Membership soundness”), so a spend of non-zero value signed then admits no valid proof, so no signature made before the note is in the tree survives completion, which refutes (ii). A Sapling nullifier depends on the note’s position in the tree (protocol specification, §“Computing $\rho$ values and Nullifiers”), which is unknown until the note is mined, and is effecting data; for Sapling only (i) holds. □

ZIP 374 calls the two workflows re-anchoring and the spending of unmined notes; Proposition 11.4 (c) is the latter for the steps of a plan.

12.6 Construction and IO finalisation

The transaction of a PCZT is of version $5$ , with version group identifier 0x26A7270A (protocol specification, §“Transaction Consensus Rules”), or of version $6$ , with 0xD884B698 (ZIP 229), whose consensus branch identifier names NU6.3 or a later upgrade; version $4$ is not representable, and is invalid from NU7 on (ZIP 2003, deployed by ZIP 259). An Ironwood component requires version $6$ , the mixed case being rejected by the rule of §12.5. The consensus branch identifier fixes the rules in force, and a role that does not recognise it cannot check the PCZT against them (ZIP 374, “Global”).

Creator. The Creator chooses $\mathsf{tx\_version}$ , $\mathsf{version\_group\_id}$ and $\mathsf{consensus\_branch\_id}$ , sets the other Global fields with $\mathsf{tx\_modifiable}=1000\,0011$ in binary, and sets every bundle to its canonical empty bundle (Definition 12.8); for $\mathsf{tx\_version}=5$ it sets the Sapling and Orchard anchors, and for $\mathsf{tx\_version}=6$ it MAY leave them to an Updater (Definition 12.12) (ZIP 374, “Creator”).

Constructor. Before adding anything the Constructor MUST check the bit of $\mathsf{tx\_modifiable}$ for the kind added (Definition 12.5), and it updates the bundle’s $\mathsf{value\_sum}$ . Per Orchard-protocol Action, in the notation of the Ironwood Guide, it sets $\mathsf{cv}^{\mathsf{net}}:=\mathsf{ValueCommit}^{\mathsf{Orchard}}_{\mathsf{% rcv}}(v^{\mathsf{old}}-v^{\mathsf{new}})$ for a fresh $\mathsf{rcv}$ (§“Value commitments”); the nullifier $\mathsf{nf}^{\mathsf{old}}$ of the consumed note (§“The nullifier”); a uniform $\alpha$ and $\mathsf{rk}:=\mathsf{ak}^{\mathbb{P}}+[\alpha]\,G^{\mathsf{SpendAuth}}$ (§“Randomised validating keys”); and the created note with $\rho^{\mathsf{new}}:=\mathsf{nf}^{\mathsf{old}}$ , its $\mathsf{cmx}$ (§“Note commitments”), $\mathsf{epk}$ and $C_{\mathsf{enc}}$ (§“Encryption to the recipient”) and $C_{\mathsf{out}}$ (§“The outgoing ciphertext”); together with the context fields of the spend and the output. Dummy and fabricated Actions and their order are those of Construction 11.18, only fully dummy Actions carrying $\mathsf{dummy\_sk}$ . Spends and outputs MUST agree with the bundle flags. When the bundle’s anchor is set, each spend added carries a witness rooting to it, or, for a note of value zero, whose path the Action statement does not check, any placeholder; for $\mathsf{tx\_version}=6$ a spend MAY be added without a witness, even of a note not yet in the tree; for $\mathsf{tx\_version}=5$ every non-dummy spend is of a note in the tree, with a witness to the anchor. A transparent input with a lock-time requirement is added only if its lock type is compatible with those of the other inputs and, when inputs are already signed, it leaves the lock time unchanged (§12.10) (ZIP 374, “Constructor” and “OrchardBundle”).

Construction 12.14 (IO finalisation).

Once the input and output set is final, the IO Finalizer performs the following steps, failing where stated (ZIP 374, “IO Finalizer”).

(1)

If shielded spends or outputs exist, it clears bits $0$ , $1$ and $7$ of $\mathsf{tx\_modifiable}$ .
(2)

For each Orchard-protocol bundle with Actions $1,\dots,n$ , it requires every $\mathsf{rcv}_{i}$ , sets $\mathsf{bsk}:=\sum_{i}\mathsf{rcv}_{i}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$ , computes

$\mathsf{bvk}:=\textstyle\sum_{i}\mathsf{cv}^{\mathsf{net}}_{i}-[v^{\mathsf{% balance}}]\,V^{\mathsf{Orchard}},$

with $v^{\mathsf{balance}}$ the integer that the bundle’s $\mathsf{value\_sum}$ denotes (§12.3), and fails unless $[\mathsf{bsk}]\,R^{\mathsf{Orchard}}=\mathsf{bvk}$ (Ironwood Guide, §“The binding signature”). The Orchard and the Ironwood bundles are finalised separately, each by this computation on its own Actions.
(3)

For the Sapling bundle, it sets $\mathsf{bsk}$ to the sum of the spends’ $\mathsf{rcv}$ minus the sum of the outputs’ $\mathsf{rcv}$ , checked in the same way against the Sapling binding validating key (protocol specification, §“Balance and Binding Signature (Sapling)”).
(4)

It computes the signature digest over the effecting data (Ironwood Guide, §“Transaction digests and signatures”), signs each dummy spend under the spend authorising key derived from its $\mathsf{dummy\_sk}$ or given by its $\mathsf{dummy\_ask}$ , randomised by the spend’s $\alpha$ , and clears that key.
(5)

For each bundle with $\mathsf{enableCrossAddress}=0$ , it MUST verify that each Action’s output recipient equals its spend recipient, and fail otherwise.

The condition of step (5) is condition A10 of the Action statement (Ironwood Guide, §“The Action statement”), so no valid proof exists for an Action that violates it; the step reports the violation at the role responsible for it.

Lemma 12.15 (Value-sum consistency).

Let an Orchard-protocol bundle have Actions with $\mathsf{cv}^{\mathsf{net}}_{i}=\mathsf{ValueCommit}^{\mathsf{Orchard}}_{% \mathsf{rcv}_{i}}(v^{\mathsf{net}}_{i})$ , and let $v^{\mathsf{balance}}$ be the integer that its $\mathsf{value\_sum}$ denotes. Step (2) of Construction 12.14 passes if and only if $\sum_{i}v^{\mathsf{net}}_{i}\equiv v^{\mathsf{balance}}\pmod{p_{\mathsf{Vesta}}}$ , and $\mathsf{bsk}$ is then a binding signing key whose validating key is $\mathsf{bvk}$ . The check reads no value $v^{\mathsf{net}}_{i}$ , which may therefore have been redacted.

Proof.

With $\mathsf{bsk}=\sum_{i}\mathsf{rcv}_{i}$ ,

\mathsf{bvk}-[\mathsf{bsk}]\,R^{\mathsf{Orchard}}=\Bigl{[}\textstyle\sum_{i}v^% {\mathsf{net}}_{i}-v^{\mathsf{balance}}\Bigr{]}\,V^{\mathsf{Orchard}},

which is $\mathcal{O}$ if and only if the coefficient vanishes modulo $p_{\mathsf{Vesta}}$ , since $V^{\mathsf{Orchard}}$ is a non-identity point of the group of prime order $p_{\mathsf{Vesta}}$ . This is Ironwood Guide, §“The binding signature”, Proposition “Balance and key knowledge”, part (i). No independence of $V^{\mathsf{Orchard}}$ and $R^{\mathsf{Orchard}}$ is used. The check computes $\mathsf{bvk}$ from the commitments and $\mathsf{value\_sum}$ alone. □

The binding signing key cannot wait for the Transaction Extractor, since every $\mathsf{rcv}$ would then travel to it and open every value commitment to every intermediate party; nor can Constructors maintain it incrementally, since serial Constructors would have to update it and parallel ones, whose results a Combiner merges, must not. One role run once the set is final removes both problems, and the same role signs dummy spends so that no Signer parses spending-key material (ZIP 374, “Adding an IO Finalizer role”).

12.7 Signing

Digests. The Signer derives the effecting data from the PCZT and computes the shielded signature digest $\mathsf{SigHash}$ itself (ZIP 244 for version $5$ , as amended by ZIP 229 for version $6$ ; Ironwood Guide, §“Transaction digests and signatures”), neither proofs nor signatures entering it; for each transparent input it signs, it computes that input’s digest under the input’s $\mathsf{sighash\_type}$ (ZIP 244, “S.2: transparent_sig_digest”) and signs it by the scheme of the Crypto Guide, §“The transparent layer’s schemes: ECDSA and BIP-340 over secp256k1”. A Signer that cannot sign under an input’s hash type MUST NOT sign that input (ZIP 374, “TransparentInput”).

Orchard-protocol spends. For an Action it signs, with $\alpha$ present, the Signer sets $\mathsf{rsk}:=\mathsf{ask}+\alpha$ , fails unless $\mathsf{rk}=[\mathsf{rsk}]\,G^{\mathsf{SpendAuth}}$ , and sets $\mathsf{spend\_auth\_sig}$ to the RedPallas signature on $\mathsf{SigHash}$ under $\mathsf{rsk}$ (Ironwood Guide, §“Randomised validating keys”); Ironwood-pool Actions are signed in the same way in their own bundle. A signature produced elsewhere, for example by a hardware device, is attached if and only if it is valid under the Action’s $\mathsf{rk}$ on $\mathsf{SigHash}$ . The Signer then updates $\mathsf{tx\_modifiable}$ (Definition 12.5) (ZIP 374, “Signer” and “OrchardSpend”).

Definition 12.16 (Signer relations).

For an Orchard-protocol Action whose explicit data are present, with $v^{\mathsf{old}}$ and $v^{\mathsf{new}}$ the values of its spend and its output, the Signer relations are, in the notation of the Ironwood Guide:

(a)

$\mathsf{cv}^{\mathsf{net}}=\mathsf{ValueCommit}^{\mathsf{Orchard}}_{\mathsf{% rcv}}(v^{\mathsf{old}}-v^{\mathsf{new}})$ (§“Value commitments”);
(b)

the consumed note rebuilt from ( $\mathsf{recipient}$ , $v^{\mathsf{old}}$ , $\rho$ , $\mathsf{rseed}$ ) has nullifier $\mathsf{nf}$ under the $\mathsf{nk}$ of $\mathsf{fvk}$ (§“The nullifier”), and $\mathsf{fvk}$ owns the recipient: $\mathsf{pk_{d}}=[\mathsf{ivk}]\,\mathsf{g_{d}}$ for the $\mathsf{ivk}$ that $\mathsf{fvk}$ determines (§“Diversified addresses”);
(c)

$\mathsf{rk}=\mathsf{ak}^{\mathbb{P}}+[\alpha]\,G^{\mathsf{SpendAuth}}$ for the $\mathsf{ak}$ of $\mathsf{fvk}$ (§“Randomised validating keys”);
(d)

$\mathsf{cmx}$ is the commitment of the created note rebuilt from ( $\mathsf{recipient}$ , $v^{\mathsf{new}}$ , $\mathsf{rseed}$ ) with $\rho^{\mathsf{new}}=\mathsf{nf}$ (§“Note commitments”);
(e)

for an output that is not fabricated, $\mathsf{esk}$ derived from $\mathsf{rseed}$ and $\rho^{\mathsf{new}}$ gives $\mathsf{epk}$ and a $C_{\mathsf{enc}}$ that decrypts to a plaintext with the explicit recipient, value and $\mathsf{rseed}$ (§“Encryption to the recipient”), and, when $\mathsf{ock}$ is present, $C_{\mathsf{out}}$ decrypts under it to $(\mathsf{pk_{d}},\mathsf{esk})$ (§“The outgoing ciphertext”).

A fabricated zero-valued output at a spent note’s receiver carries a random $C_{\mathsf{enc}}$ (Construction 11.18) and is exempt from (e): a Signer MUST NOT reject it on that ground alone, and SHOULD classify it as a tolerable dummy, checking (d) if it wishes (ZIP 374, “Signer”, “Verifier” and “Fabricated same-address outputs (NU6.3)”).

Obligations before signing (ZIP 374, “Signer”). A Signer MUST reject a PCZT that carries any $\mathsf{dummy\_sk}$ or $\mathsf{dummy\_ask}$ : the IO Finalizer signs dummy spends and clears these keys, so their presence asks the Signer to parse spending-key material. It MUST, for each output with a $\mathsf{user\_address}$ , parse it and confirm that it contains the output’s recipient (§12.3). It SHOULD verify that the explicit values and note data it shows its user are consistent with the effecting data it signs, through the relations of Definition 12.16; a field absent because it was redacted is not an inconsistency, and only a present field that contradicts the effecting data is. The relations need the value and note commitments, BLAKE2b and the functions built on it, nullifier derivation, key agreement, the key derivation and the AEAD of note encryption, the signature digest and RedPallas signing (RedJubjub for Sapling), and no proof system.

Theorem 12.17 (Signer safety).

Let a Signer hold the $\mathsf{ask}$ of an Orchard-protocol key generated with $\mathsf{use\_qsk}=\mathsf{false}$ , and suppose that for every PCZT $P$ it signs it computes $m_{P}:=\mathsf{SigHash}(T_{P})$ from the effecting data $T_{P}$ of $P$ , performs the obligations above, verifies relations (a) to (e) of Definition 12.16, with all their fields present, for every Action whose spend it signs, displays the values, recipients and address strings so checked, and signs under keys $\mathsf{ask}+\alpha$ no message other than such digests $m_{P}$ . Under the assumptions of Ironwood Guide, §“Authorisation of spends”, Theorem “Spend authority”, and Assumption “Collision resistance of BLAKE2b” (§“Transaction digests and signatures”), except with negligible probability:

(i)

every accepted Action that consumes a note of the key carries a signature on some $m_{P}$ ;
(ii)

every accepted transaction that carries an Action with a randomised validating key $\mathsf{rk}$ under which the Signer signed has the effecting data $T_{Q}$ of some PCZT $Q$ that the Signer signed with an Action of key $\mathsf{rk}$ ; in it the Actions whose spends the Signer signed consume and create the notes, with the values and recipients, that the Signer displayed for $Q$ , and every other effecting field, balancing values and transparent data included, equals that of $Q$ .

The theorem concerns content, not inclusion.

Proof.

(i) The Signer is the signing oracle of the Ironwood Guide, §“Authorisation of spends”, Definition “Spend-authority experiment”, queried with $(\alpha,m_{P})$ for $\alpha$ taken from the PCZT and so possibly chosen by an adversary, which that experiment admits; the full viewing key that the PCZT discloses is given to the adversary there. Theorem “Spend authority” bounds by a negligible function the probability of an accepted Action that consumes a note of the key without a queried digest.

(ii) Let $T^{\prime}$ be accepted and carry an Action with key $\mathsf{rk}$ and a signature $\sigma^{\prime}$ valid under $\mathsf{rk}$ on $\mathsf{SigHash}(T^{\prime})$ . The reduction of the proof of Theorem “Spend authority”, which simulates the key holder from $\mathsf{ak}^{\mathbb{P}}$ and answers queries with adversarial randomisers, turns a triple $(\mathsf{rk},\mathsf{SigHash}(T^{\prime}),\sigma^{\prime})$ that is not a triple of an answer of the Signer into a forgery in Ironwood Guide, §“RedPallas unforgeability”, Proposition “Unforgeability under re-randomisation”; hence, except with negligible probability, $\mathsf{SigHash}(T^{\prime})=m_{Q}$ for a PCZT $Q$ that the Signer signed under $\mathsf{rk}$ . The collision case of the proof of Proposition “Bundle binding” uses only that each node of the digest tree hashes a string from which its children and fields are recovered uniquely, which holds equally for the version- $5$ tree (ZIP 244, “TxId Digest” and “Signature Digest”), where the anchors are among the hashed fields and are effecting data (Definition 12.3); it therefore applies to both transaction versions and gives $T^{\prime}=T_{Q}$ as effecting data, except with negligible probability under Assumption “Collision resistance of BLAKE2b”. The digest covers the value and script of each transparent input (§12.3), so a false value in $Q$ yields a digest that validation does not compute and a signature that is not accepted. For each Action whose spend the Signer signed, relations (a) and (d) make the displayed data an opening of $\mathsf{cv}^{\mathsf{net}}$ and of $\mathsf{cmx}$ , and by Lemma “Hiding and binding of net value commitments” and Proposition “Hiding and binding of note commitments” of the Ironwood Guide no other opening is feasible; relation (b) identifies the consumed note, whose commitment fixes its value; relation (e) makes the created note decryptable by its recipient (Proposition “Decryption correctness”); and the check of $\mathsf{user\_address}$ ties each recipient to the displayed string. □

Pre-authorisation (ZIP 374, “Signer” and “Anchors and pre-authorization”). For a transaction of version $6$ a Signer MAY sign while the shielded anchors, witnesses or proofs are absent, since signatures commit to none of them (Proposition 12.13). A Signer asked to do so SHOULD be aware, and where applicable make its user aware, that a spend without a witness may be of a note that never exists on chain: the signature authorises the spend whether or not the note is created. For a transaction of version $5$ the anchors are in the digest and MUST be present before signing.

Lemma 12.18 (Binding key after IO finalisation).

If IO finalisation (Construction 12.14) succeeded for an Orchard-protocol bundle, and its commitments $\mathsf{cv}^{\mathsf{net}}_{i}$ and its $\mathsf{value\_sum}$ are unchanged afterwards, then a binding signature under $\mathsf{bsk}$ on the signature digest is valid under the $\mathsf{bvk}$ that validation derives from the transaction’s $\mathsf{cv}^{\mathsf{net}}_{i}$ and balancing value $v^{\mathsf{balance}}$ .

Proof.

Validation computes $\mathsf{bvk}$ from the same commitments and balancing value (Ironwood Guide, §“The binding signature”, Definition “Binding validating key”), and IO finalisation checked that it equals $[\mathsf{bsk}]\,R^{\mathsf{Orchard}}$ (Lemma 12.15). Correctness of RedPallas in the binding-signature instance (Ironwood Guide, §“The binding signature”, Construction “Binding signature”) gives validity. □

The hypothesis of Lemma 12.18 holds for every PCZT reached by the roles after finalisation: $\mathsf{cv}^{\mathsf{net}}$ is required effecting data, which no later role changes and the merge of §12.9 keeps equal, and a finalised bundle merges only with a bundle of equal Action count and $\mathsf{value\_sum}$ .

12.8 Proving

Per Orchard-protocol Action the Prover requires the spend’s recipient, value, $\rho$ , $\mathsf{rseed}$ , $\mathsf{fvk}$ , witness and $\alpha$ , the output’s recipient, value and $\mathsf{rseed}$ , and the Action’s $\mathsf{rcv}$ ; the bundle’s anchor MUST be set, and before proving the Prover MUST verify that the path of the witness of every spend of non-zero value roots to it, and fail otherwise. For Sapling it requires per spend the recipient, the value, $\mathsf{rcm}$ or $\mathsf{rseed}$ , $\mathsf{rcv}$ , the proof generation key and the witness, and per output the recipient, the value, $\mathsf{rseed}$ and $\mathsf{rcv}$ . The Prover needs no spending key; a delegated Prover learns the note data of the bundle but gains no spending authority (§12.9) (ZIP 374, “Prover”).

Construction 12.19 (Proof creation from a PCZT).

For an Orchard-protocol bundle with no Actions the Prover does nothing. Otherwise, for each Action $i$ , it rebuilds the consumed note from its explicit data and the created note from its explicit data with $\rho^{\mathsf{new}}_{i}=\mathsf{nf}_{i}$ ; forms the primary input

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

with $\mathit{rt}$ the bundle’s anchor, and the auxiliary input from the witness, the two notes, $\alpha_{i}$ , the components of $\mathsf{fvk}_{i}$ and $\mathsf{rcv}_{i}$ (Ironwood Guide, §“The Action statement”); and fails if the pair does not satisfy the Action statement, in particular if $\mathsf{fvk}_{i}$ does not own the consumed note or $\mathsf{cmx}_{i}$ differs from the commitment of the rebuilt created note. It then creates one Halo 2 proof for all Actions of the bundle (Ironwood Guide, §“The Action circuit and the Halo 2 proof”; Halo 2 Guide, §“The Halo 2 proof system”) and sets $\mathsf{zkproof}$ . The Ironwood bundle is proved in the same way with its own anchor. The primary input consists of effecting data and the anchor only.

An Action whose $\mathsf{rk}$ is the identity point $\mathcal{O}$ is invalid (protocol specification, §“Action Descriptions”; ZIP 256, “Orchard identity rk”), and the Transaction Extractor MUST refuse it (ZIP 374, “Transaction Extractor”). A Prover that refuses it as well spares a proof of a transaction that cannot be valid; ZIP 374 does not state that check for the Prover, and it is designed but unspecified (Definition 1.1).

12.9 Combining, redaction, and privacy

Construction 12.20 (Binary merge).

The merge $P\sqcup Q$ of two PCZTs is defined, or fails, as follows (ZIP 374, “Combiner”).

(1)

Global. The fields $\mathsf{tx\_version}$ , $\mathsf{version\_group\_id}$ , $\mathsf{consensus\_branch\_id}$ , $\mathsf{fallback\_lock\_time}$ , $\mathsf{expiry\_height}$ and $\mathsf{coin\_type}$ MUST be equal. The field $\mathsf{tx\_modifiable}$ merges bitwise, bits $0$ , $1$ and $7$ by AND and bit $2$ by OR, bits $3$ to $6$ being required zero on both sides.
(2)

Lists of inputs, outputs, spends and Actions. If either side’s bundle is IO-finalised, its $\mathsf{bsk}$ being present, both sides have equally many entries and equal $\mathsf{value\_sum}$ . Otherwise the entries at the positions common to both lists merge pairwise, and the extra entries of the longer list are appended provided the shorter side’s $\mathsf{tx\_modifiable}$ permits additions of that kind, the merge failing otherwise. The merged shielded bundle’s $\mathsf{value\_sum}$ is that of the side each of whose lists of the bundle is at least as long as the other side’s, the merge failing if neither side is; with lists of equal lengths the two MUST be equal. ZIP 374 leaves this unstated, so it is designed but unspecified (Definition 1.1).
(3)

Required fields of merged entries, and the bundle $\mathsf{flags}$ , $\mathsf{note\_version}$ and, in version $1$ , $\mathsf{anchor}$ , MUST be equal.
(4)

Optional fields merge as $x\sqcup\bot=\bot\sqcup x=x$ , and $x\sqcup y=x$ if $x=y$ , failing otherwise; in version $2$ this rule covers the anchors.
(5)

Maps merge by union of their keys, the values of a common key being required equal.

The Combiner of $k$ PCZTs merges them into one that contains every field of each, or fails. It MUST NOT combine PCZTs that do not represent the same transaction, that is, PCZTs not derived by roles from a common ancestor, which rules (1) to (3) check structurally. Once the input and output set is final, the effecting data determine the transaction identifier, which then identifies the PCZT; for version $6$ , re-anchored copies keep that identifier.

BIP 174 lets a combiner keep one of two conflicting values and discard the other. The PCZT merge requires equality instead, which is always possible because every field is typed and known in advance, so every conflict fails at the Combiner and none diverges later (ZIP 374, “Combiner rejecting non-identical duplicates”).

Lemma 12.21 (Commutativity of the merge).

For PCZTs $P$ and $Q$ , the merge $P\sqcup Q$ is defined if and only if $Q\sqcup P$ is, and then the two are equal.

Proof.

By cases on the rules of Construction 12.20. The equality tests of rules (1) and (3) are symmetric; AND and OR are commutative; the rule for optional fields and the union of maps with equal values on common keys are symmetric; the condition on IO-finalised bundles is symmetric; in rule (2) the longer list and the side whose permission is consulted are determined by the lengths, not by the order of the arguments, and so is the merged $\mathsf{value\_sum}$ , which is required equal at equal lengths; and the pairwise merges of common entries commute by induction on the structure of the entries. □

ZIP 374 requires further that combining SHOULD be functionally order-independent, $\mathrm{Combine}(f_{A}(p),f_{B}(p))=f_{A}(f_{B}(p))=f_{B}(f_{A}(p))$ for participants that apply $f_{A}$ and $f_{B}$ to $p$ . That is a requirement on roles, not a property proved here for all of them; Proposition 12.22 proves it for the Prover and the Signer.

Proposition 12.22 (Order independence of proving and signing).

Let $p$ be an IO-finalised PCZT on which the Prover (Construction 12.19) and a Signer (§12.7) are both defined, the anchors being set for proving and, for a transaction of version $5$ , fixed before signing (Definition 12.12). Fix the random coins of both roles. Then $\mathrm{Prove}(\mathrm{Sign}(p))$ and $\mathrm{Sign}(\mathrm{Prove}(p))$ are defined and both equal $\mathrm{Prove}(p)\sqcup\mathrm{Sign}(p)$ : the two roles run in either order, or in parallel on copies whose outputs are merged by Construction 12.20. For a transaction of version $6$ signing may moreover precede the setting of the anchors (Proposition 12.13). If a copy is redacted before either role, and retains the fields that role reads, the equality holds up to the redacted fields, which the merge restores from the other side.

Proof.

Signing. The signed digest is computed from effecting data only, excluding proofs and signatures (Lemma 11.21), and the relations of Definition 12.16 read effecting and context data; $\mathrm{Prove}$ writes neither, so $\mathrm{Sign}$ reads the same values on $p$ and on $\mathrm{Prove}(p)$ and, with its coins fixed, writes the same signatures and bits. Proving. The primary input of the Action statement consists of effecting data and the anchor, and the auxiliary input of context data (Construction 12.19; Ironwood Guide, §“The Action statement”); $\mathrm{Sign}$ writes none of them, and the Prover reads no spending key, so $\mathrm{Prove}$ writes the same proofs on $p$ and on $\mathrm{Sign}(p)$ . Merge. The role $\mathrm{Prove}$ sets only proof fields, absent in $p$ , and $\mathrm{Sign}$ only signatures, absent in $p$ , and bits of $\mathsf{tx\_modifiable}$ , which it only clears, or sets in the case of bit $2$ ; the bundle of $p$ is finalised on both sides with equal counts and value sums. Neither role writes a required field, so rule (3) holds, and a transparent signature is a new key of $\mathsf{partial\_signatures}$ , merged by rule (5). Rules (1) to (5) of Construction 12.20 therefore give $\mathrm{Prove}(p)\sqcup\mathrm{Sign}(p)=\mathrm{Prove}(\mathrm{Sign}(p))=% \mathrm{Sign}(\mathrm{Prove}(p))$ . ZIP 374, “Prover”, states the same independence. □

Redactor (ZIP 374, “Redactor” and the field descriptions). Anyone may clear fields that later roles do not need: per Orchard-protocol Action the spend’s $\mathsf{spend\_auth\_sig}$ , recipient, value, $\rho$ , $\mathsf{rseed}$ , $\mathsf{fvk}$ , witness, $\alpha$ , derivation record, dummy key and proprietary entries, the output’s recipient, value, $\mathsf{rseed}$ , $\mathsf{ock}$ , derivation record, $\mathsf{user\_address}$ and proprietary entries, and $\mathsf{rcv}$ ; the corresponding Sapling fields; and the transparent and Global lookup data. A PCZT with inputs of several independent Signers is sent to each with only what that Signer needs, for example without the other Signers’ values of $\alpha$ .

Proposition 12.23 (Disclosure by a PCZT).

A PCZT carries strictly more than its transaction: for each shielded spend or output it may carry the counterparty address, the value, the note randomness, $\mathsf{rcv}$ , which opens $\mathsf{cv}^{\mathsf{net}}$ , the full viewing key of the spending account, derivation records, $\mathsf{ock}$ , which opens $C_{\mathsf{out}}$ , and address strings. Every recipient of a PCZT at a stage learns all data present at that stage; a delegated Prover learns the note data of the spends and outputs but gains no spending authority; the extracted transaction contains none of these data. Participants SHOULD send a PCZT only to entities needed for the remaining roles and SHOULD redact what those do not need, and wallets SHOULD protect stored PCZTs as they protect their note records (ZIP 374, “Privacy Implications”).

Proof.

The listed fields are context data (Definition 12.3), which extraction omits (§12.10); a recipient reads every field present. The Prover’s data (Construction 12.19) contain $\mathsf{fvk}$ but no $\mathsf{ask}$ , and an accepted spend of a note of the key without a signature under $\mathsf{ask}+\alpha$ on a digest that the key holder signed is excluded, except with negligible probability, by Ironwood Guide, §“Authorisation of spends”, Theorem “Spend authority”, under its assumptions, whose adversary holds the full viewing key. □

12.10 Spend finalisation and extraction

Spend Finalizer (ZIP 374, “Spend Finalizer” and “TransparentInput”; BIP 11; BIP 16). For each transparent input with enough data, the Spend Finalizer builds $\mathsf{script\_sig}$ : for P2PKH, the push of the one signature, with its hash-type byte, under the key that hashes to the address, followed by the push of that key; for P2SH multisignature, the opcode $\mathsf{OP\_0}$ , the pushes of $m$ signatures in the key order of the redeem script and the push of the redeem script, failing with fewer than $m$ signatures. It MUST fail on a signature whose hash type is not the input’s $\mathsf{sighash\_type}$ . It SHOULD then clear the input’s redeem script, partial signatures, derivation records and preimages. It keeps $\mathsf{value}$ and $\mathsf{script\_pubkey}$ , required fields that the digest needs, and $\mathsf{sequence}$ and the lock-time requirements, which the digest and Definition 12.24 read at extraction; ZIP 374’s “all other optional data” would include these last fields, a gap in the specification.

Definition 12.24 (Lock-time determination).

If no transparent input has a required time or height lock, the lock time is $\mathsf{fallback\_lock\_time}$ , or $0$ if it is absent. Otherwise the lock type is one supported by every input that states a requirement, an input that states both types supporting both; an input that states neither supports both. If both types remain possible, the height type is chosen; if none remains, the requirements are unsatisfiable. The lock time is the maximum required value of the chosen type (ZIP 374, “Determining Lock Time”).

Construction 12.25 (Transaction extraction).

The Transaction Extractor checks, failing on any violation (ZIP 374, “Transaction Extractor”), that

(i)

$\mathsf{tx\_version}$ , $\mathsf{version\_group\_id}$ and $\mathsf{consensus\_branch\_id}$ name a supported format, and the lock-time requirements are satisfiable (Definition 12.24);
(ii)

for $\mathsf{tx\_version}=5$ the Ironwood bundle is canonical empty;
(iii)

every $\mathsf{script\_sig}$ is set;
(iv)

every Sapling spend has its proof and signature, and every Sapling output its proof;
(v)

every Orchard-protocol bundle with $n\geq 1$ Actions has a $\mathsf{zkproof}$ of the canonical length of $2720+2272\,n$ bytes (Ironwood Guide, §“The transaction format”), and every Action a $\mathsf{spend\_auth\_sig}$ ;
(vi)

every non-empty shielded bundle has its anchor and $\mathsf{bsk}$ ;
(vii)

no $\mathsf{rk}$ is $\mathcal{O}$ .

It then sets each bundle’s balancing value to $v^{\mathsf{balance}}$ , failing if it lies outside the signed $64$ -bit range of the transaction field; sets the lock time by Definition 12.24; computes $\mathsf{SigHash}$ ; for each bundle derives $\mathsf{bvk}$ from its value commitments and balancing value, fails unless it matches $\mathsf{bsk}$ , and signs $\mathsf{SigHash}$ under $\mathsf{bsk}$ , by RedPallas for the Orchard and Ironwood bundles and by RedJubjub for Sapling (Lemma 12.18); and outputs the transaction, without any context data (ZIP 229). It SHOULD then verify every proof and signature of that transaction, each $\mathsf{spend\_auth\_sig}$ under its $\mathsf{rk}$ on $\mathsf{SigHash}$ included, so that an invalid transaction is found before submission.

A party that holds an Orchard-protocol output’s recipient, value and $\mathsf{rseed}$ , with $\rho^{\mathsf{new}}$ the $\mathsf{nf}$ of its Action’s spend, recovers the full note plaintext, memo included, without $\mathsf{ock}$ or any viewing key, by the derivation of $\mathsf{esk}$ stated with Theorem 11.22 (§11.8; Ironwood Guide, §“Encryption to the recipient”, Proposition “Decryption correctness”; ZIP 212). The random $C_{\mathsf{enc}}$ of a fabricated output decrypts to nothing, as the construction intends.