<p>The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 <aid="footnote-reference-1"class="footnote_reference"href="#bcp14">1</a> when, and only when, they appear in all capitals.</p>
<p>The character § is used when referring to sections of the Zcash Protocol Specification <aid="footnote-reference-2"class="footnote_reference"href="#protocol">2</a>.</p>
<p>This proposal defines a new Zcash peer-to-peer transaction format, which includes data that supports the Orchard-ZSA protocol and all operations related to Zcash Shielded Assets (ZSAs). The new format adds and describes new fields containing ZSA-specific elements. Like the existing v5 transaction format, it keeps well-bounded regions of the serialized form to serve each pool of funds.</p>
<p>This ZIP also depends upon and defines modifications to the computation of the values <strong>TxId Digest</strong>, <strong>Signature Digest</strong>, and <strong>Authorizing Data Commitment</strong> defined by ZIP 244 <aid="footnote-reference-3"class="footnote_reference"href="#zip-0244">8</a>.</p>
<p>The Orchard-ZSA protocol requires serialized data elements that are distinct from any previous Zcash transaction. Since ZIP 244 was activated in NU5, the v5 and later serialized transaction formats are not consensus-critical. Thus, this ZIP defines format that can easily accommodate future extensions, where elements or a given pool are kept separate.</p>
<p>The new format must fully support the Orchard-ZSA protocol.</p>
<p>The new format should lend itself to future extension or pruning to add or remove value pools.</p>
<p>The computation of the non-malleable transaction identifier hash must include all newly incorporated elements except those that attest to transaction validity.</p>
<p>The computation of the commitment to authorizing data for a transaction must include all newly incorporated elements that attest to transaction validity.</p>
<p>More general forms of extensibility, such as definining a key/value format that allows for parsers that are unaware of some components, are not required.</p>
<td>A sequence of issuance action descriptions, where IssueActionSize is the size, in bytes, of an IssueAction description.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>ik</code></td>
<td><code>byte[32]</code></td>
<td>The issuance validating key of the issuer, used to validate the signature.</td>
</tr>
<tr>
<td><code>64</code></td>
<td><code>issueAuthSig</code></td>
<td><code>byte[64]</code></td>
<td>The signature of the transaction SIGHASH, signed by the issuer, validated as in Issuance Authorization Signature Scheme <aid="footnote-reference-4"class="footnote_reference"href="#zip-0227">7</a>.</td>
</tr>
</tbody>
</table>
<ul>
<li>The fields <code>valueBalanceSapling</code> and <code>bindingSigSapling</code> are present if and only if
<li>The fields <code>flagsOrchard</code>, <code>valueBalanceOrchard</code>, <code>anchorOrchard</code>, <code>sizeProofsOrchardZSA</code>, <code>proofsOrchardZSA</code>, and <code>bindingSigOrchard</code> are present if and only if
<li>The elements of <code>vSpendProofsSapling</code> and <code>vSpendAuthSigsSapling</code> have a 1:1 correspondence to the elements of <code>vSpendsSapling</code> and MUST be ordered such that the proof or signature at a given index corresponds to the <code>SpendDescriptionV6</code> at the same index.</li>
<li>The elements of <code>vOutputProofsSapling</code> have a 1:1 correspondence to the elements of <code>vOutputsSapling</code> and MUST be ordered such that the proof at a given index corresponds to the <code>OutputDescriptionV6</code> at the same index.</li>
<li>The proofs aggregated in <code>proofsOrchardZSA</code>, and the elements of <code>vSpendAuthSigsOrchard</code>, each have a 1:1 correspondence to the elements of <code>vActionsOrchard</code> and MUST be ordered such that the proof or signature at a given index corresponds to the <code>OrchardZsaAction</code> at the same index.</li>
<li>For coinbase transactions, the <code>enableSpendsOrchard</code> and <code>enableZSAs</code> bits MUST be set to
<spanclass="math">\(0\!\)</span>
.</li>
</ul>
<p>The encodings of <code>tx_in</code>, and <code>tx_out</code> are as in a version 4 transaction (i.e. unchanged from Canopy). The encodings of <code>SpendDescriptionV6</code>, <code>OutputDescriptionV6</code> , <code>OrchardZsaAction</code>, <code>AssetBurn</code> and <code>IssueAction</code> are described below. The encoding of Sapling Spends and Outputs has changed relative to prior versions in order to better separate data that describe the effects of the transaction from the proofs of and commitments to those effects, and for symmetry with this separation in the Orchard-related parts of the transaction format.</p>
<td>A value commitment to the net value of the input note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>nullifier</code></td>
<td><code>byte[32]</code></td>
<td>The nullifier of the input note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>rk</code></td>
<td><code>byte[32]</code></td>
<td>The randomized validating key for the element of spendAuthSigsSapling corresponding to this Spend.</td>
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in §7.3 ‘Spend Description Encoding and Consensus’ of the Zcash Protocol Specification <aid="footnote-reference-5"class="footnote_reference"href="#protocol-spenddesc">3</a>.</p>
<td>A value commitment to the net value of the output note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>cmu</code></td>
<td><code>byte[32]</code></td>
<td>The
<spanclass="math">\(u\!\)</span>
-coordinate of the note commitment for the output note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>ephemeralKey</code></td>
<td><code>byte[32]</code></td>
<td>An encoding of an ephemeral Jubjub public key.</td>
</tr>
<tr>
<td><code>580</code></td>
<td><code>encCiphertext</code></td>
<td><code>byte[580]</code></td>
<td>The encrypted contents of the note plaintext.</td>
</tr>
<tr>
<td><code>80</code></td>
<td><code>outCiphertext</code></td>
<td><code>byte[80]</code></td>
<td>The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key.</td>
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ of the Zcash Protocol Specification <aid="footnote-reference-6"class="footnote_reference"href="#protocol-outputdesc">4</a>.</p>
<td>A value commitment to the net value of the input note minus the output note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>nullifier</code></td>
<td><code>byte[32]</code></td>
<td>The nullifier of the input note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>rk</code></td>
<td><code>byte[32]</code></td>
<td>The randomized validating key for the element of spendAuthSigsOrchard corresponding to this Action.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>cmx</code></td>
<td><code>byte[32]</code></td>
<td>The
<spanclass="math">\(x\!\)</span>
-coordinate of the note commitment for the output note.</td>
</tr>
<tr>
<td><code>32</code></td>
<td><code>ephemeralKey</code></td>
<td><code>byte[32]</code></td>
<td>An encoding of an ephemeral Pallas public key</td>
</tr>
<tr>
<td><code>612</code></td>
<td><code>encCiphertext</code></td>
<td><code>byte[580]</code></td>
<td>The encrypted contents of the note plaintext.</td>
</tr>
<tr>
<td><code>80</code></td>
<td><code>outCiphertext</code></td>
<td><code>byte[80]</code></td>
<td>The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key.</td>
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ of the Zcash Protocol Specification <aid="footnote-reference-7"class="footnote_reference"href="#protocol-actiondesc">5</a>.</p>
<p>An issuance action, <code>IssueAction</code>, is the instance of issuing a specific Custom Asset, and contains the following fields:</p>
<table>
<thead>
<tr>
<th>Bytes</th>
<th>Name</th>
<th>Data Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>2</code></td>
<td><code>assetDescSize</code></td>
<td><code>byte</code></td>
<td>The length of the asset description string in bytes.</td>
</tr>
<tr>
<td><code>assetDescSize</code></td>
<td><code>asset_desc</code></td>
<td><code>byte[assetDescSize]</code></td>
<td>A byte sequence of length <code>assetDescSize</code> bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.</td>
</tr>
<tr>
<td><code>varies</code></td>
<td><code>nNotes</code></td>
<td><code>compactSize</code></td>
<td>The number of notes in the issuance action.</td>
</tr>
<tr>
<td><code>noteSize * nNotes</code></td>
<td><code>vNotes</code></td>
<td><code>Note[nNotes]</code></td>
<td>A sequence of note descriptions within the issuance action, where <code>noteSize</code> is the size, in bytes, of a Note.</td>
</tr>
<tr>
<td><code>1</code></td>
<td><code>flagsIssuance</code></td>
<td><code>byte</code></td>
<td>
<dl>
<dt>An 8-bit value representing a set of flags. Ordered from LSB to MSB:</dt>
<dd>
<ul>
<li>
<spanclass="math">\(\mathsf{finalize}\)</span>
</li>
<li>The remaining bits are set to
<spanclass="math">\(0\!\)</span>
.</li>
</ul>
</dd>
</dl>
</td>
</tr>
</tbody>
</table>
<p>The encodings of each of these elements are defined in ZIP 227 <aid="footnote-reference-9"class="footnote_reference"href="#zip-0227">7</a>.</p>
<td><ahref="https://www.rfc-editor.org/info/bcp14">Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</a></td>
</tr>
</tbody>
</table>
<tableid="protocol"class="footnote">
<tbody>
<tr>
<th>2</th>
<td><ahref="protocol/protocol.pdf">Zcash Protocol Specification, Version 2023.4.0 or later [NU5 proposal]</a></td>