#Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 [1] when, and only when, it appears in all capitals.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [2]

The character § is used when referring to sections of the Zcash Protocol Specification. [18]

The terms "Orchard" and "Action" in this document are to be interpreted as described in ZIP 224. [4]

The terms "Orchard shielded pool" and "Ironwood shielded pool" in this document are to be interpreted as described in ZIP 229. [10]

The terms "Asset" and "Custom Asset" in this document are to be interpreted as described in ZIP 227. [5]

We define the following additional terms:

• Split Input: an Action input used to ensure that the output note of that Action is of a validly issued $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$ (see [6]) when there is no corresponding real input note, in situations where the number of outputs are larger than the number of inputs. See formal definition in Split Notes.

• Split Action: an Action that contains a Split Input.

#Abstract

This ZIP (ZIP 226) proposes the Orchard Zcash Shielded Assets (OrchardZSA) protocol, in conjunction with ZIP 227 [5]. The OrchardZSA protocol is an extension of the Orchard protocol that enables the issuance, transfer and burn of custom Assets on the Zcash chain. The issuance of such Assets is defined in ZIP 227 [5], while the transfer and burn of such Assets is defined in this ZIP (ZIP 226). While the proposed OrchardZSA protocol is a modification to the Orchard protocol, it has been designed with adaptation to possible future shielded protocols in mind.

This ZIP is defined relative to the Zcash protocol specification version 2026.8.0 [19].

#Motivation

None of the currently deployed Zcash transfer protocols support Custom Assets. Enabling multi-asset support on the Zcash chain will open the door for a host of applications, and enhance the ecosystem with application developers and Asset custody institutions for issuance and bridging purposes. This ZIP builds on the issuance mechanism introduced in ZIP 227 [5].

#Overview

In order to be able to represent different Assets, we need to define a data field that uniquely represents the Asset in question, which we call the Asset Identifier $𝖠𝗌𝗌𝖾𝗍𝖨𝖽$. This Asset Identifier maps to an Asset Base $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$ that is stored in OrchardZSA notes. These terms are formally defined in ZIP 227 [5].

The Asset Identifier (via means of the Asset Digest and Asset Base) will be used to enforce that the balance of an Action Description [21] [36] is preserved across Assets (see the Orchard Binding Signature [26]), and by extension the balance of an Orchard transaction. That is, the sum of all the $𝗏𝖺𝗅𝗎{𝖾}^{𝗇𝖾𝗍}$ from each Action Description, computed as $𝗏𝖺𝗅𝗎{𝖾}^{𝗈𝗅𝖽}-𝗏𝖺𝗅𝗎{𝖾}^{𝗇𝖾𝗐}$, must be balanced only with respect to the same Asset Identifier. This is especially important since we will allow different Action Descriptions to transfer notes of different Asset Identifiers, where the overall balance is checked without revealing which (or how many distinct) Assets are being transferred.

As was initially proposed by Jack Grigg and Daira-Emma Hopwood [37] [38], we propose to make this happen by changing the value base point, ${𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, in the Homomorphic Pedersen Commitment that derives the value commitment, $𝖼{𝗏}^{𝗇𝖾𝗍}$, of the net value in an Orchard Action.

Because in a single transaction all value commitments are balanced, there must be as many different value base points as there are Asset Identifiers for a given shielded protocol used in a transaction. We propose to make the Asset Base an auxiliary input to the proof for each Action statement [28], represented already as a point on the Pallas curve. The circuit then should check that the same Asset Base is used in the old note commitment and the new note commitment [33], and as the base point in the value commitment [32]. This ensures (1) that the input and output notes are of the same Asset Base, and (2) that only Actions with the same Asset Base will balance out in the Orchard binding signature.

In order to ensure the security of the transfers, and as we will explain below, we are redefining input dummy notes [25] for Custom Assets, as we need to enforce that the $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$ of the output note of that Split Action is the output of a valid $𝖹𝖲𝖠𝖵𝖺𝗅𝗎𝖾𝖡𝖺𝗌𝖾$ computation defined in ZIP 227 [5].

We include the ability to pause the ZSA functionality, via a $𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠$ boolean flag. When this flag is set to false, the proof will fail for any non-native Asset, making it impossible to perform transactions involving Custom Assets. When this flag is set to true, the circuit will allow transactions involving Custom Assets subject to the values of the $𝖾𝗇𝖺𝖻𝗅𝖾𝖲𝗉𝖾𝗇𝖽𝗌𝖮𝗋𝖼𝗁𝖺𝗋𝖽$ and $𝖾𝗇𝖺𝖻𝗅𝖾𝖮𝗎𝗍𝗉𝗎𝗍𝗌𝖮𝗋𝖼𝗁𝖺𝗋𝖽$ flags, similar to the vanilla Orchard setting.

Finally, in this ZIP we also describe the burn mechanism, which is a direct extension of the transfer mechanism. The burn process uses a similar mechanism to what is used in Orchard to unshield ZEC, by using the $𝗏𝖺𝗅𝗎𝖾𝖡𝖺𝗅𝖺𝗇𝖼𝖾$ of the Asset in question. Burning Assets is useful for many purposes, including bridging, and removing supply of Assets.

#Privacy Implications

• After the protocol upgrade, the Ironwood shielded pool will be shared by the Orchard protocol and the OrchardZSA protocol. The Orchard shielded pool cannot contain OrchardZSA notes.

• Deploying the OrchardZSA protocol does not necessitate disabling the Orchard protocol. Both can co-exist and be addressed via different transaction versions.

• OrchardZSA note commitments for the native asset (ZEC) are indistinguishable from OrchardZSA note commitments for non-native Assets.

• When including new Assets we would like to maintain the amount and identifiers of Assets private, which is achieved with the design.

#Specification

Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.

#Asset Identifiers

For every new Asset, there MUST be a new and unique Asset Identifier. Every Asset is defined by an Asset description, $𝖺𝗌𝗌𝖾𝗍\_𝖽𝖾𝗌𝖼$, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance validating key of the issuer, the specific Asset Identifier, $𝖠𝗌𝗌𝖾𝗍𝖨𝖽$, the Asset Digest, and the Asset Base ($𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$) are derived as defined in ZIP 227 [5].

This Asset Base will be the base point of the value commitment for the specific Custom Asset. Note that the Asset Base of the ZEC Asset will be kept as the original value base point, ${𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

#Rationale for Asset Identifiers

In future network and protocol upgrades, the same Asset description string can be carried on, potentially mapping into a different shielded pool. In that case, nodes should know how to transform the Asset Identifier, the Asset Digest, and the Asset Base from one shielded pool to another, while ensuring there are no balance violations [3].

We prevent a potential malleability attack on the Asset Identifier by ensuring the output notes receive an Asset Base that exists on the global state.

#Note Structure and Commitment

An OrchardZSA note differs from an Orchard note [20] by additionally including the Asset Base, $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$. So an OrchardZSA note is a tuple $(𝖽,𝗉{𝗄}_{𝖽},𝗏,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,\text{rho },\text{psi },𝗋𝖼𝗆)$, where

• $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾:{\mathbb{P}}^{*}$ is the unique element of the Pallas group [34] that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 [6], a valid group element that is not the identity and is not $\perp$. The byte representation of the Asset Base is defined as $mathsf{asset_base} : mathbb{B}^{mathbb{Y}^{[ell_{mathbb{P}}/8]}} := mathsf{LEBS2OSP}_{ell_{mathbb{P}}}(mathsf{repr}_{mathbb{P}}(mathsf{AssetBase}))$.

• The remaining terms are as defined in §3.2 ‘Notes’ [20].

Note that the above assumes a canonical encoding, which is true for the Pallas group, but may not hold for future shielded protocols.

Let $𝖭𝗈𝗍{𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠}$ be the type of a OrchardZSA note, i.e.

where ${\mathbb{P}}^{*}$ is the Pallas group excluding the identity element, and the other types are as defined in §3.2 ‘Notes’ [20].

Non-normative note: The type and definition of the OrchardZSA note reflect that it is a tuple of all the components of an Orchard note, with the addition of the Asset Base into the tuple.

We define the note commitment scheme $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠}$ as follows:

• ${𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠}:𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖳𝗋𝖺𝗉𝖽𝗈𝗈𝗋$ $\times {𝔹}^{[{\ell }_{\mathbb{P}}]}$ $\times {𝔹}^{[{\ell }_{\mathbb{P}}]}$ $\times \{0..2^{{\ell }_{𝗏𝖺𝗅𝗎𝖾}}-1\}$ $\times {𝔽}_{q_{\mathbb{P}}}$ $\times {𝔽}_{q_{\mathbb{P}}}$ $\times {\mathbb{P}}^{*}\to 𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.𝖮𝗎𝗍𝗉𝗎𝗍$

where $\mathbb{P},{\ell }_{\mathbb{P}},q_{\mathbb{P}}$ are as defined for the Pallas curve [34], and where $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}.\{𝖳𝗋𝖺𝗉𝖽𝗈𝗈𝗋,𝖮𝗎𝗍𝗉𝗎𝗍\}$ are as defined in §4.1.8 ‘Commitment’ [23]. This uses the note commitment scheme defined in §5.4.8.4 ‘Sinsemilla Commitments’ [33] as follows:

\mathsf{NoteCommit^{OrchardZSA}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase}) :=
  \begin{cases}
    \mathsf{NoteCommit^{Orchard}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}), &\!\!\textsf{if } \mathsf{AssetBase} = \mathcal{V}^{\mathsf{Orchard}} \\
    \mathsf{cm_{ZSA}} &\!\!\textsf{otherwise}
  \end{cases}

where:

• \mathsf{cm_{ZSA}} := \mathsf{SinsemillaHashToPoint}(\texttt{“z.cash:ZSA-NoteCommit-M”},\hspace{-6em} $hspace{6em}mathsf{g_{d}star} ,||, mathsf{pk_{d}star} ,||, mathsf{I2LEBSP_{64}(v)} ,||, mathsf{I2LEBSP}_{ell^{mathsf{Orchard}}_{mathsf{base}}}(text{ρ})hspace{-6em}$ $hspace{6em},||, mathsf{I2LEBSP}_{ell^{mathsf{Orchard}}_{mathsf{base}}}(text{ψ}) ,||, mathsf{asset_base})hspace{-4em}$ \hspace{4em}\,+\; [\mathsf{rcm}]\,\mathsf{GroupHash}^{\mathbb{P}}(\texttt{“z.cash:Orchard-NoteCommit-r”}, \texttt{“”})

Note that ${𝗋𝖾𝗉𝗋}_{\mathbb{P}}$ and ${𝖦𝗋𝗈𝗎𝗉𝖧𝖺𝗌𝗁}^{\mathbb{P}}$ are as defined for the Pallas curve [34], ${\ell }_{𝖻𝖺𝗌𝖾}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ is as defined in §5.3 ‘Constants’ [30], and $𝖨\mathrm{𝟤}𝖫𝖤𝖡𝖲𝖯$ is as defined in §5.1 ‘Integers, Bit Sequences, and Endianness’ [29].

The nullifier is generated in the same manner as in the Orchard protocol §4.16 ‘Computing ρ values and Nullifiers’ [27].

The OrchardZSA note plaintext also includes the Asset Base $𝖺𝗌𝗌𝖾𝗍\_𝖻𝖺𝗌𝖾:{𝔹}^{[{\ell }_{\mathbb{P}}]}$ in addition to the components in the Orchard note plaintext [35].

Open Issue: The encoding of OrchardZSA bundles in the transaction format of ZIP 248 [13] is yet to be specified, including the explicit encoding of the OrchardZSA note plaintext. These encodings, including that of the note plaintext [12], were specified for the withdrawn ZIP 230 design [11].

When § 4.7.3 'Sending Notes (Orchard)' [24] or § 4.8.3 'Dummy Notes (Orchard)' [25] are invoked directly or indirectly in the computation of $\text{rho }$ and $\text{psi }$ for an OrchardZSA note, $𝗅𝖾𝖺𝖽𝖡𝗒𝗍𝖾$ MUST be set to {{ZSALEADBYTE}}. This is a placeholder for the note plaintext lead byte of OrchardZSA notes, whose value is yet to be assigned.

The explicit order of addition of the note commitments to the note commitment tree is specified in ZIP 227 [8].

#Rationale for Note Commitment

In the OrchardZSA protocol, the instance of the note commitment scheme, $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠}$, differs from the Orchard-protocol note commitment scheme $𝖭𝗈𝗍𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗆}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ in that for Custom Assets, the Asset Base will be added as an input to the commitment computation. In the case where the Asset is the ZEC Asset, the commitment is computed identically to the Orchard-protocol note commitment, without making use of the ZEC Asset Base as an input. As we will see, the nested structure of the Sinsemilla-based commitment [33] allows us to add the Asset Base as a final recursive step.

The note commitment output is still indistinguishable from Orchard-protocol ZEC note commitments, by definition of the Sinsemilla hash function [31]. OrchardZSA-protocol note commitments will therefore be added to the same note commitment tree as the Orchard-protocol notes of the Ironwood shielded pool. In essence, we have:

This definition can be viewed as a generalization of the Orchard-protocol note commitment, and will allow maintaining a single commitment instance for the note commitment, which will be used both for pre-ZSA Orchard-protocol notes and OrchardZSA-protocol notes.

#Value Commitment

In the case of the OrchardZSA protocol, the value of different Asset Identifiers in a given transaction will be committed using a different value base point. The value commitment becomes:

where ${𝗏}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}^{𝗇𝖾𝗍}={𝗏}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}^{𝗈𝗅𝖽}-{𝗏}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}^{𝗇𝖾𝗐}$ such that

• ${𝗏}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}^{𝗈𝗅𝖽}$ and ${𝗏}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}^{𝗇𝖾𝗐}$ are the values of the old and new notes of Asset Identifier $𝖠𝗌𝗌𝖾𝗍𝖨𝖽$ respectively,

• $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌{𝖾}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}$ is defined in ZIP 227 [5], and

• \mathcal{R}^{\mathsf{Orchard}} := \mathsf{GroupHash^{\mathbb{P}}}(\texttt{“z.cash:Orchard-cv”}, \texttt{“r”}), as in the Orchard protocol.

For ZEC, we define ${𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾}_{𝖠𝗌𝗌𝖾𝗍𝖨𝖽}:={𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ so that the value commitment for ZEC notes is computed identically to the Orchard protocol deployed in NU5 [4]. As such $𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗏}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}(𝗏)$ as defined in [4] is used as $𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋𝖼𝗏}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠}({𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽},𝗏)$ here.

#Rationale for Value Commitment

The Orchard Protocol uses a Homomorphic Pedersen Commitment [32] to perform the value commitment, with fixed base points ${𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and ${ℛ}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ as the values represent the amount of ZEC being transferred.

The use of different value base points for different Assets enables the final balance of the transaction to be securely computed, such that each Asset Identifier is balanced independently, which is required as different Assets are not meant to be mutually fungible.

#Burn Mechanism

The burn mechanism is a transparent extension to the transfer protocol that enables a specific amount of any Custom Asset to be "destroyed" by the holder. The burn mechanism does NOT send Assets to a non-spendable address, it simply reduces the total number of units of a given Custom Asset in circulation. It is enforced at the consensus level, by using an extension of the value balance mechanism used for ZEC Assets. Burning makes it globally provable that a given amount of a Custom Asset has been destroyed. Note that the OrchardZSA Protocol does not allow for the burning of the Native Asset (i.e. ZEC or TAZ).

In the OrchardZSA Transaction Structure, there is now an $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set. For every Custom Asset (represented by its $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$) that is burnt in the transaction, the sender adds to $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ the tuple $(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,𝗏)$, where $𝗏$ is the amount of the Custom Asset the sender wants to burn. We define a constant $𝖬𝖠𝖷\_𝖡𝖴𝖱𝖭\_𝖵𝖠𝖫𝖴𝖤:=2^{63}-1$, which denotes the maximum amount of a given Custom Asset that can be burnt in a transaction. We denote by $L$ the cardinality of the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set in a transaction.

Open Issue: The encoding of the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set is yet to be specified, as noted in Note Structure and Commitment.

As described in Value Balance Verification, this provides the information for the validator of the transaction to compute the value commitment with the corresponding Asset Base. This ensures that the values are all balanced out on a per-Asset basis in the transaction.

#Additional Consensus Rules for the assetBurn set

1. It MUST be the case that for every $(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,𝗏)\in 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇,𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾\ne {𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$. That is, the Native Asset is not allowed to be burnt by this mechanism.

2. It MUST be that for every $(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,𝗏)\in 𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇,𝗏>0$ and $𝗏\le 𝖬𝖠𝖷\_𝖡𝖴𝖱𝖭\_𝖵𝖠𝖫𝖴𝖤$.

3. There MUST be no duplication of Custom Assets in the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set. That is, every $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$ has at most one entry in $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$.

The other consensus rule changes for the OrchardZSA protocol are specified in ZIP 227 [7].

Note: The transparent protocol will not be changed with this ZIP to adapt to a multiple Asset structure. This means that unless future consensus rules changes do allow it, unshielding will not be possible for Custom Assets.

#Rationale for MAX_BURN_VALUE

The maximum amount of any Custom Asset allowed to be burnt in a transaction is set to $𝖬𝖠𝖷\_𝖡𝖴𝖱𝖭\_𝖵𝖠𝖫𝖴𝖤$ in order to prevent it from being incompatible with other valueBalance fields, which are signed 64-bit integers. It will also allow for compatibility with future Custom-asset-specific value balances in subsequent pools that support transferring ZSAs from the Ironwood shielded pool via a turnstile.

#Value Balance Verification

In order to verify the balance of the different Assets, the verifier MUST perform a similar process as for the Orchard protocol [26], with the addition of the burn information.

For a total of $n$ Actions in a transfer, the prover MUST still sign the SIGHASH transaction hash using the binding signature key $𝖻𝗌𝗄=\sum _{i=1}^n{𝗋𝖼𝗏}_i$.

The verifier MUST compute the value balance verification equation:

After computing $𝖻𝗏𝗄$, the verifier MUST use it to verify the binding signature on the SIGHASH transaction hash.

Open Issue: The transaction format of ZIP 248 [13] records value balances as value pool deltas. How the value balance ${𝗏}^{𝖻𝖺𝗅𝖺𝗇𝖼𝖾𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set used in this equation are represented in that format is yet to be specified, as noted in Note Structure and Commitment.

#Rationale for Value Balance Verification

We assume $n$ Actions in a transfer. Out of these $n$ Actions, we further distinguish (for the sake of clarity) between Actions related to ZEC and Actions related to Custom Assets. We denote by $S_{𝖹𝖤𝖢}\subseteq \{1..n\}$ the set of indices of Actions that are related to ZEC, and by $S_{𝖢𝖠}=\{1..n\}⧵S_{𝖹𝖤𝖢}$ the set of indices of Actions that are related to Custom Assets.

The right hand side of the value balance verification equation can be expanded to:

This equation contains the balance check of the Orchard protocol [26]. With ZSA, transfer Actions for Custom Assets must also be balanced across Asset Bases. All Custom Assets are contained within the shielded pool, and cannot be unshielded via a regular transfer. Custom Assets can be burnt, the mechanism for which reveals the amount and identifier of the Asset being burnt, within the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set. As such, for a correctly constructed transaction, we will get $sum_{j in S_{mathsf{CA}}} mathsf{cv}^{mathsf{net}}_j - sum_{(mathsf{AssetBase}, mathsf{v}) in mathsf{assetBurn}} [mathsf{v}],mathsf{AssetBase} = sum_{j in S_{mathsf{CA}}} [mathsf{rcv}^{mathsf{net}}_j],mathcal{R}^{mathsf{Orchard}}$.

When the Asset is not being burnt, the net balance of the input and output values is zero, and there will be no addition to the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ vector. Therefore, the relationship between $𝖻𝗏𝗄$ and $𝖻𝗌𝗄$ will hold if and only if, per Custom Asset, the sum of the net values of the relevant Actions equals the corresponding ${𝗏}_k$ value (or equals $0$ if that Asset is not in the $𝖺𝗌𝗌𝖾𝗍𝖡𝗎𝗋𝗇$ set), and for ZEC, the sum of the net values of the relevant Actions equals the ${𝗏}^{𝖻𝖺𝗅𝖺𝗇𝖼𝖾𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ value.

As in the Orchard protocol, the binding signature verification key, $𝖻𝗏𝗄$, will only be valid (and hence verify the signature correctly), as long as the committed values sum to zero. In contrast, in this protocol, the committed values must sum to zero per Asset Base, as the Pedersen commitments add up homomorphically only with respect to the same value base point.

#Split Notes

A Split Input is a copy of a previously issued input note (that is, a note that has previously been included in the Merkle tree), with the following changes:

• A $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀$ boolean is set to 1.

• The value of the note is replaced with the value 0 during the computation of the value commitment.

Input notes are sometimes split in two (or more) output notes, as in most cases, not all the value in a single note is sent to a single output.

When the number of input notes of a particular Asset Base is smaller than the required number of output notes for the same Asset Base, the sender creates Split Inputs of the same Asset Base as padding for the input-less Actions. Note that we do not care about whether the previously issued note copied to create a Split Input is owned by the sender, or whether it was nullified before.

Wallets and other clients have to choose from the following to ensure the Asset Base is preserved for the output note of a Split Action:

1. The Split Input note could be another note containing the same Asset Base that is being spent by this transaction (but not by this Split Input).

2. The Split Input note could be a different unspent note containing the same Asset Base (note that the note will not actually be spent).

3. The Split Input note could be an already spent note containing the same Asset Base (note that by zeroing the value in the circuit, we prevent double spending).

For Split Notes, the nullifier is generated as follows:

where ${\text{psi }}^{𝗇𝖿}$ is computed as $mathsf{ToBase^{Orchard}}big(mathsf{PRF^{expand}_{rseed_nf}}([mathtt{0x0A}] ,||, underline{text{ρ}^{mathsf{old}}})kern-0.1embig)$ for $mathsf{rseed_nf}$ sampled uniformly at random on $mathbb{B}^{{kern-0.1emtinymathbb{Y}}[32]}$, $mathcal{K}^{mathsf{Orchard}}$ is the Orchard Nullifier Base as defined in §4.16 ‘Computing ρ values and Nullifiers’ [27], and \mathcal{L}^{\mathsf{Orchard}} := \mathsf{GroupHash^{\mathbb{P}}}(\texttt{“z.cash:Orchard”}, \texttt{“L”}). The first-byte domain separator $\mathrm{𝟶}𝚡\mathrm{𝟶}𝙰$ for $𝖯𝖱{𝖥}^{𝖾𝗑𝗉𝖺𝗇𝖽}$ is reserved for this use by ZIP 2005 [17], as recorded in §4.1.2 ‘Pseudo Random Functions’ [22].

#Rationale for Split Notes

In the Orchard protocol, since each Action represents an input and an output, the transaction that wants to send one input to multiple outputs must have multiple inputs. The Orchard protocol gives dummy spend notes [25] to the Actions that have not been assigned input notes.

The Orchard technique requires modification for the OrchardZSA protocol with multiple Asset Identifiers, as the output note of the split Actions cannot contain just any Asset Base. We must enforce it to be an actual output of a GroupHash computation (in fact, we want it to be of the same Asset Base as the original input note, but the binding signature takes care that the proper balancing is performed). Without this enforcement the prover could input a multiple (or linear combination) of an existing Asset Base, and thereby attack the network by overflowing the ZEC value balance and hence counterfeiting ZEC funds.

Therefore, for Custom Assets we enforce that every input note to an OrchardZSA Action must be proven to exist in the set of note commitments in the note commitment tree. We then enforce this real note to be “unspendable” in the sense that its value will be zeroed in split Actions and the nullifier will be randomized, making the note not spendable in the specific Action. Then, the proof itself ensures that the output note is of the same Asset Base as the input note. In the circuit, the split note functionality will be activated by a boolean private input to the proof (aka the $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀$ boolean). This ensures that the value base points of all output notes of a transfer are actual outputs of a GroupHash, as they originate in the Issuance protocol which is publicly verified.

Note that the Orchard dummy note functionality remains in use for ZEC notes, and the Split Input technique is used in order to support Custom Assets.

#Circuit Statement

Every OrchardZSA Action statement is closely similar to the Orchard Action statement [28], except for a few additions that ensure the security of the Asset Identifier system. We detail these changes below.

All modifications in the Circuit are detailed in [39].

#Asset Base Equality

The following constraints must be added to ensure that the input and output note are of the same $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$:

• The Asset Base, $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$, for the note is witnessed once, as an auxiliary input.

• In the Old note commitment integrity constraint in the Orchard Action statement [28], $mathsf{NoteCommit^{Orchard}_{rcm^{old}}}(mathsf{repr}_{mathbb{P}}(mathsf{g_d^{old}}), mathsf{repr}_{mathbb{P}}(mathsf{pk_d^{old}}), mathsf{v^{old}}, text{ρ}^{mathsf{old}}, text{ψ}^{mathsf{old}})$ is replaced with $mathsf{NoteCommit^{OrchardZSA}_{rcm^{old}}}(mathsf{repr}_{mathbb{P}}(mathsf{g_d^{old}}), mathsf{repr}_{mathbb{P}}(mathsf{pk_d^{old}}), mathsf{v^{old}}, text{ρ}^{mathsf{old}}, text{ψ}^{mathsf{old}}, mathsf{AssetBase})$.

• In the New note commitment integrity constraint in the Orchard Action statement [28], $mathsf{NoteCommit^{Orchard}_{rcm^{new}}}(mathsf{repr}_{mathbb{P}}(mathsf{g_d^{new}}), mathsf{repr}_{mathbb{P}}(mathsf{pk_d^{new}}), mathsf{v^{new}}, text{ρ}^{mathsf{new}}, text{ψ}^{mathsf{new}})$ is replaced with $mathsf{NoteCommit^{OrchardZSA}_{rcm^{new}}}(mathsf{repr}_{mathbb{P}}(mathsf{g_d^{new}}), mathsf{repr}_{mathbb{P}}(mathsf{pk_d^{new}}), mathsf{v^{new}}, text{ρ}^{mathsf{new}}, text{ψ}^{mathsf{new}}, mathsf{AssetBase})$.

To make the evaluation of the note commitment easier, we add a boolean $𝗂𝗌\_𝗇𝖺𝗍𝗂𝗏𝖾\_𝖺𝗌𝗌𝖾𝗍$ as an auxiliary witness. We also add some constraints to verify that this variable is activated (i.e. $𝗂𝗌\_𝗇𝖺𝗍𝗂𝗏𝖾\_𝖺𝗌𝗌𝖾𝗍=1$) if the Asset Base is equal to ${𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$ and this variable is not activated (i.e. $𝗂𝗌\_𝗇𝖺𝗍𝗂𝗏𝖾\_𝖺𝗌𝗌𝖾𝗍=0$) if the Asset Base is not equal to ${𝒱}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

#The $𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠$ Flag

The following constraints must be added to disable transactions involving Custom Assets when the $𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠$ flag is set to false:

• if $𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠$ is not activated (i.e. $𝖾𝗇𝖺𝖻𝗅𝖾𝖹𝖲𝖠=0$), then constrain $𝗂𝗌\_𝗇𝖺𝗍𝗂𝗏𝖾\_𝖺𝗌𝗌𝖾𝗍=1$, since the $𝖠𝗌𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$ must be equal to the native asset.

#Value Commitment Correctness

The following constraints must be added to ensure that the value commitment is computed using the witnessed Asset Base:

• The fixed-base multiplication constraint between the value and the value base point of the value commitment, $𝖼𝗏$, is replaced with a variable-base multiplication between the two.

• The witness to the value base point (as defined in the asset base equation) is the auxiliary input $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$.

#Asset Identifier Consistency for Split Actions

Senders must not be able to change the Asset Base for the output note in a Split Action. We do this via the following constraints:

• The Value Commitment Integrity should be changed:

  • Replace the input note value by a generic value, $𝗏\text{'}$, as $𝖼{𝗏}^{𝗇𝖾𝗍}=𝖵𝖺𝗅𝗎𝖾𝖢𝗈𝗆𝗆𝗂{𝗍}_{𝗋}𝖼{𝗏}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽𝖹𝖲𝖠}(𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾,𝗏\text{'}-{𝗏}^{𝗇𝖾𝗐})$

• Add a boolean $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀$ variable as an auxiliary witness. This variable is to be activated $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=1$ if the Action in question has a Split Input and $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=0$ if the Action is actually spending an input note:

  • If $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=1$ then constrain $𝗏\text{'}=0$ otherwise constrain $𝗏\text{'}={𝗏}^{𝗈𝗅𝖽}$ from the auxiliary input.

  • If $𝗌𝗉𝗅𝗂𝗍\_𝖿𝗅𝖺𝗀=1$ then constrain $𝗂𝗌\_𝗇𝖺𝗍𝗂𝗏𝖾\_𝖺𝗌𝗌𝖾𝗍=0$ because split notes are only available for Custom Assets.

• The Merkle Path Validity should check the existence of the note commitment as usual (and not like with dummy notes):

  • Check for all notes except dummy notes that $(𝗉𝖺𝗍𝗁,𝗉𝗈𝗌)$ is a valid Merkle path of depth $𝖬𝖾𝗋𝗄𝗅𝖾𝖣𝖾𝗉𝗍{𝗁}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$, from $𝖼{𝗆}^{𝗈𝗅𝖽}$ to the anchor $𝗋{𝗍}^{𝖮𝗋𝖼𝗁𝖺𝗋𝖽}$.

  • The new constraint is $underbrace{(mathsf{v^{old}} = 0 land mathsf{is_native_asset} = 1)}_text{It is a dummy note} lor underbrace{(mathsf{Valid,Merkle,Path})}_text{The Merkle Path is valid}$.

• The Nullifier Integrity will be changed to prevent the identification of notes as defined in the Split Notes section.

#Backwards Compatibility with ZEC Notes

The input note in the old note commitment integrity check must either include an Asset Base (OrchardZSA note) or not (pre-ZSA Orchard note). If the note is a pre-ZSA Orchard note, the note commitment is computed in the original Orchard fashion [23]. If the note is an OrchardZSA note, the note commitment is computed as defined in the Note Structure and Commitment section.

#OrchardZSA Transaction Structure

ZIP 248 [13] specifies a new transaction version, and provisionally registers a bundle variant for OrchardZSA in its format.

Open Issue: The encoding of OrchardZSA bundles is yet to be specified, as noted in Note Structure and Commitment.

#Implications for Wallets

Once the transaction version specified by ZIP 248 is allowed on the network, that ZIP requires wallets to be able to parse transactions of that version, and to send only such transactions [16]. For ZSAs, the corresponding requirements on wallets are:

• Once ZSAs have activated, all wallets should switch to sending only the transaction version that supports ZSAs. They should also use the OrchardZSA bundle variant for all of their Ironwood-pool actions, including those that transfer ZEC. The main consequence of not doing so is that users would not otherwise obtain the privacy benefit of indistinguishability between native and non-native assets in the Ironwood shielded pool, because actions in v6 and earlier transactions, and in bundles of other variants, can only transfer the native ZEC asset.

• All wallets should be ready to receive funds in outputs of the transaction version that supports ZSAs as soon as they activate. The consequence of not doing so would be that funds sent to Orchard-protocol addresses of a wallet without this support could be temporarily inaccessible, until the wallet is upgraded to fully support the relevant transaction version and note plaintext lead byte, and to rescan Ironwood-pool outputs since ZSA activation.

#Sighash

ZIP 248 specifies the digest algorithms for the transaction version that it defines [14], and a mechanism for versioning sighash algorithms [15]. Each bundle type defines its contributions to those digests, and the sighash versions available to its signers together with the associated data that each version requires.

Open Issue: The digests of OrchardZSA bundles, and the sighash versions available to their signers, are yet to be specified.

#Transaction Fees

The fee mechanism for the upgrades proposed in this ZIP will follow the mechanism described in ZIP 317 for the OrchardZSA protocol upgrade, and are described in ZIP 227 [9].

#Backward Compatibility

In order to have backward compatibility with the ZEC notes, we have designed the circuit to support both ZEC and OrchardZSA notes. As we specify above, there are three main reasons we can do this:

• Note commitments for ZEC notes will remain the same, while note commitments for Custom Assets will be computed taking into account the $𝖠𝗌𝗌𝖾𝗍𝖡𝖺𝗌𝖾$ value as well.

• The Ironwood shielded pool, which already holds Orchard-protocol notes, will also hold the new OrchardZSA-protocol notes after the upgrade.

• The value commitment is abstracted to allow for the value base-point as a variable private input to the proof.

• The ZEC-based Actions will still include dummy input notes, whereas the OrchardZSA Actions will include split input notes and will not include dummy input notes.

#Deployment

The Zcash Shielded Assets protocol is scheduled to be deployed in Network Upgrade 7 (NU7). This ZIP currently assumes that this will be the case.

#Test Vectors

• https://github.com/QED-it/zcash-test-vectors

#Reference Implementation

• https://github.com/QED-it/zcash (in zcashd)

• https://github.com/QED-it/orchard (in orchard)

• https://github.com/QED-it/librustzcash (in librustzcash)

• https://github.com/QED-it/halo2 (in halo2)

#References