ZSA Guide Zcash Shielded Assets: asset identity, issuance, transfer, and burn 1 Introduction 3 Notes and note commitments

2 Asset identity

This section constructs the identity of an Asset in dependency order: the issuance key pair, the issuance authorisation signature scheme and the issuer identifier (§2.1); the asset description and the Asset Identifier (§2.2); the Asset Digest, the Asset Base and its byte encoding (§2.3); and the Asset Base of the Native Asset (§2.4). Every construction of the section is taken from ZIP 227 and ZIP 226, both Draft. The results of the section separate Assets computationally: distinct pairs of issuer and description yield distinct Asset Identifiers and distinct Asset Bases, and no Asset Base of a Custom Asset coincides with a fixed generator of the Orchard protocol, except with negligible probability.

Throughout, $\mathbb{B}^{\mathbb{Y}[k]}$ denotes the set of byte strings of length $k$ and $\mathbb{B}^{\mathbb{Y}[\mathbb{N}]}$ the set of byte strings of arbitrary length; $\|$ denotes concatenation. For a $16$ -byte personalisation $P$ and a byte string $x$ , $\mathsf{BLAKE2b\text{-}256}(P,x)$ and $\mathsf{BLAKE2b\text{-}512}(P,x)$ denote unkeyed BLAKE2b with personalisation $P$ , input $x$ and an output of $32$ and $64$ bytes respectively (protocol specification, §“BLAKE2 Hash Functions”). The former is the function $\mathsf{h}$ of the Ironwood Guide, §“Transaction digests and signatures”.

2.1 Issuance keys and the issuer identifier

Definition 2.1 (Issuance key pair).

The issuance authorising key is a byte string $\mathsf{isk}\in\mathbb{B}^{\mathbb{Y}[32]}$ . The issuance validating key is $\mathsf{ik}:=\mathsf{DerivePublic}(\mathsf{isk})$ , with $\mathsf{DerivePublic}$ the algorithm of Definition 2.2; it lies in $\mathbb{B}^{\mathbb{Y}[32]}\cup\{\bot\}$ , and a key pair is usable only when $\mathsf{ik}\neq\bot$ . The key $\mathsf{isk}$ authorises the issuance of Asset Identifiers by one issuer and is used only by that issuer; the key $\mathsf{ik}$ validates those issuances. Neither key is used for spend authorisation, which remains with the Orchard spend authorising key (ZIP 227, “Issuance Keys” and “Rationale”). Class: specified.

Definition 2.2 (Issuance authorisation signature scheme).

The issuance authorisation signature scheme $\mathsf{IssueAuthSig}$ is a digital signature scheme in the sense of the Crypto Guide’s Definition “Digital signature scheme” (protocol specification, §“Signature”), instantiated as BIP-340 Schnorr signatures over secp256k1 with the standard secp256k1 parameters (Crypto Guide, §“The transparent layer’s schemes: ECDSA and BIP-340 over secp256k1”, Construction “BIP-340 Schnorr over secp256k1, schematically”; cited, not re-derived). Let $n$ be the order of the secp256k1 group. The types are

	$\displaystyle\mathsf{Message}$	$\displaystyle=\mathbb{B}^{\mathbb{Y}[\mathbb{N}]},$	$\displaystyle\mathsf{Signature}$	$\displaystyle=\mathbb{B}^{\mathbb{Y}[64]}\cup\{\bot\},$
	$\displaystyle\mathsf{Public}$	$\displaystyle=\mathbb{B}^{\mathbb{Y}[32]}\cup\{\bot\},$	$\displaystyle\mathsf{Private}$	$\displaystyle=\mathbb{B}^{\mathbb{Y}[32]},$

a public key being the $32$ -byte big-endian $x$ -coordinate of BIP 340. The algorithms are the following.

1.

The algorithm $\mathsf{DerivePublic}(\mathsf{isk})$ returns the BIP-340 public key of $\mathsf{isk}$ , or $\bot$ exactly when BIP-340 key derivation fails, that is, when $\mathsf{isk}$ read as a big-endian integer is $0$ or at least $n$ .
2.

The algorithm $\mathsf{Sign}(\mathsf{isk},M)$ runs BIP-340 signing on $M$ under $\mathsf{isk}$ with auxiliary data $a:=[\mathtt{0x00}]^{32}$ and returns its output $\sigma\in\mathbb{B}^{\mathbb{Y}[64]}$ , or $\bot$ if it fails. With $a$ fixed, signing is a deterministic function of $(\mathsf{isk},M)$ .
3.

The algorithm $\mathsf{Validate}(\mathsf{ik},M,\sigma)$ returns $0$ if $\sigma=\bot$ ; otherwise it returns $1$ if BIP-340 verification of $\sigma$ on $M$ under $\mathsf{ik}$ succeeds, and $0$ if not.

ZIP 227 writes the verification key in $\mathsf{Validate}$ as $\mathsf{key}$ , although the parameter is named $\mathsf{ik}$ ; the reading $\mathsf{ik}$ is the only one that type-checks. Batch verification MAY be used; precomputation MAY be used if and only if it produces equivalent results (ZIP 227, “Issuance Authorization Signature Scheme”, “Orchard ZSA Issuance Authorization Signature Scheme”, “Derivation of issuance validating key” and “Issuance Authorization Signing and Validation”). Class: specified.

Assumption 2.3 (Unforgeability of the issuance signature).

The scheme $\mathsf{IssueAuthSig}$ , with key generation that samples $\mathsf{isk}$ uniformly from $\mathbb{B}^{\mathbb{Y}[32]}$ conditioned on $\mathsf{DerivePublic}(\mathsf{isk})\neq\bot$ , and with $H_{\mathtt{BIP0340/challenge}}$ and $H_{\mathtt{BIP0340/nonce}}$ modelled as independent random oracles, is existentially unforgeable under chosen-message attack (Crypto Guide, Definition “Existential unforgeability under chosen-message attack”).

The assumption is justified, not proved. The Crypto Guide’s Theorem “EUF-CMA security of Schnorr signatures in the ROM” (§“Security in the random oracle model and the forking lemma”) proves the property for Schnorr signatures under the discrete-logarithm assumption, and that volume’s remark following Construction “BIP-340 Schnorr over secp256k1, schematically” carries the proof to BIP-340 with the tagged challenge hash $H_{\mathtt{BIP0340/challenge}}$ modelled as a random oracle. With $a$ fixed, the nonce is $H_{\mathtt{BIP0340/nonce}}(t\,\|\,\mathsf{ik}\,\|\,M)$ for the secret $t:=d\oplus H_{\mathtt{BIP0340/aux}}(a)$ , where $d$ is the BIP-340 secret scalar of $\mathsf{isk}$ , fixed per key. With $H_{\mathtt{BIP0340/nonce}}$ also modelled as a random oracle, independent of the challenge oracle, the nonce is a fresh uniform value per message to any party ignorant of $t$ , and the proof carries over as for deterministic nonces (Crypto Guide, Construction “EdDSA, schematically”).

Definition 2.4 (Issuer identifier and signature encodings).

For $\mathsf{ik}\neq\bot$ , the validating-key encoding is $\mathsf{ik\_encoding}:=[\mathtt{0x00}]\,\|\,\mathsf{ik}$ , of $33$ bytes, and the issuer identifier is $\mathsf{issuer}:=\mathsf{ik\_encoding}$ . For $\sigma\neq\bot$ , the signature encoding is $\mathsf{issueAuthSig}:=[\mathtt{0x00}]\,\|\,\sigma$ , of $65$ bytes. In both encodings the initial byte names the signature scheme and MUST be $\mathtt{0x00}$ , which denotes BIP 340 (ZIP 227, “Derivation of issuance validating key”, “Issuance Authorization Signing and Validation”). The map $\mathsf{ik}\mapsto\mathsf{issuer}$ is injective. Note owners and validators use the identifier to associate an Asset with its issuer; ZIP 227, “Issuer Identifier”, records that the equality $\mathsf{issuer}=\mathsf{ik\_encoding}$ may cease to hold once key rotation is specified. Class: specified; its carrier is not.

The encoding $\mathsf{ik\_encoding}$ occurs only in the $\mathsf{issuer}$ field of the Issuance Bundle of “Issuance Actions and Issuance Bundles” (§6.2). No transaction format carrying that field is specified.

2.2 Asset descriptions and Asset Identifiers

Definition 2.5 (Asset description).

An asset description $\mathsf{asset\_desc}$ is a byte string chosen by the issuer, carrying any information about the issuance. ZIP 227 requires it to be non-empty and states that it SHOULD be a well-formed UTF-8 code-unit sequence according to Unicode 15.0.0 or later; no maximum length is imposed (ZIP 227, “ZIP 227 Asset Identifiers”). Only its hash $\mathsf{assetDescHash}$ (Definition 2.6) is visible to consensus, so neither non-emptiness nor the UTF-8 condition can be enforced by consensus: both are issuer-side conventions. Within the scope of one issuer, distinct Assets are obtained from distinct descriptions. Class: specified.

Definition 2.6 (Asset Identifier and its encoding).

For an issuer identifier $\mathsf{issuer}\in\mathbb{B}^{\mathbb{Y}[33]}$ and an asset description $\mathsf{asset\_desc}$ , let

	$\displaystyle\mathsf{assetDescHash}$	$\displaystyle:=\mathsf{BLAKE2b\text{-}256}(\texttt{ZSA-AssetDescCRH},\mathsf{% asset\_desc})\in\mathbb{B}^{\mathbb{Y}[32]},$
	$\displaystyle\mathsf{AssetId}$	$\displaystyle:=(\mathsf{issuer},\mathsf{assetDescHash}),$
	$\displaystyle\mathsf{EncodeAssetId}(\mathsf{AssetId})$	$\displaystyle:=[\mathtt{0x00}]\,\\|\,\mathsf{issuer}\,\\|\,\mathsf{assetDescHash% }\in\mathbb{B}^{\mathbb{Y}[66]}.$

The pair $\mathsf{AssetId}$ is the Asset Identifier and $\mathsf{EncodeAssetId}(\mathsf{AssetId})$ its canonical encoding (ZIP 227, “ZIP 227 Asset Identifiers”). The leading byte of the encoding is a version byte, reserving room for other issuance protocols; it is distinct in role from the scheme byte that begins $\mathsf{issuer}$ , so every current encoding begins with two $\mathtt{0x00}$ bytes of different meaning. The encoding is injective, since its three components have the fixed lengths $1$ , $33$ and $32$ bytes. Class: specified.

Proposition 2.7 (Uniqueness of Asset Identifiers).

Consider two distinct pairs of issuer identifier and asset description, $(\mathsf{issuer},\mathsf{asset\_desc})$ and $(\mathsf{issuer}^{\prime},\mathsf{asset\_desc}^{\prime})$ , with Asset Identifiers $\mathsf{AssetId}$ and $\mathsf{AssetId}^{\prime}$ .

1.

If $\mathsf{issuer}\neq\mathsf{issuer}^{\prime}$ , then $\mathsf{AssetId}\neq\mathsf{AssetId}^{\prime}$ .
2.

If $\mathsf{issuer}=\mathsf{issuer}^{\prime}$ , then $\mathsf{asset\_desc}\neq\mathsf{asset\_desc}^{\prime}$ , and $\mathsf{AssetId}=\mathsf{AssetId}^{\prime}$ holds exactly when the two descriptions collide under $\mathsf{BLAKE2b\text{-}256}(\texttt{ZSA-AssetDescCRH},\cdot)$ .

Hence, under the Ironwood Guide’s Assumption “Collision resistance of BLAKE2b”, no efficient algorithm outputs two distinct pairs of issuer and description with equal Asset Identifiers, or with equal encodings $\mathsf{EncodeAssetId}$ , except with negligible probability. Status: proved here for the specified construction; conditional on no unspecified object.

Proof.

The issuer identifier is a component of $\mathsf{AssetId}$ , so distinct issuers give distinct pairs, which is claim 1. For one issuer the descriptions differ, and equal identifiers mean equal values $\mathsf{assetDescHash}$ on distinct descriptions, a BLAKE2b-256 collision under one personalisation; this is claim 2. An algorithm that outputs such a collision outputs two distinct inputs $(P,x)\neq(P,x^{\prime})$ of $\mathsf{h}$ with equal values, which the Ironwood Guide’s Assumption “Collision resistance of BLAKE2b” (§“Transaction digests and signatures”) excludes except with negligible probability. Equal encodings imply equal identifiers by the injectivity recorded in Definition 2.6. □

The requirement of ZIP 226, “Asset Identifiers”, that every new Asset have a new and unique Asset Identifier is met by the choice of a new description. ZIP 227, “Rationale”, argues the separation of issuers informally; that argument is a rationale of the ZIP, whose class is designed but unspecified, and Proposition 2.7 supplies its proof. Since the proposition separates Assets only through the issuer and any issuer may reuse any description, ZIP 227, “ZIP 227 Asset Identifiers”, requires that wallets MUST NOT display $\mathsf{asset\_desc}$ alone as the name of an Asset (see also ZIP 227, “Displaying Asset Identifier information to users”).

2.3 Asset Digests and Asset Bases

OrchardZSA adds three inputs of $\mathsf{GroupHash}$ to those of the Orchard protocol, which the Ironwood Guide lists in its table of §“GroupHash, domain separation, and nothing-up-my-sleeve generators”. Table 3 lists them as strings, each with the subsection that uses it (ZIP 227, “OrchardZSA Asset Bases”; ZIP 226, “Split Notes” and “Note Structure and Commitment”). The objects they define are constructed at their uses.

Domain separator $D$	Message $M$	Use	Subsection
z.cash:OrchardZSA	$64$ -byte Asset Digest	Asset Base of a Custom Asset	§2.3
z.cash:Orchard	L	additional term of a split nullifier	§4.2
z.cash:SinsemillaQ	z.cash:ZSA-NoteCommit-M	hash base, Custom Asset note commitment	§3.2

Table 3: Group-hash inputs of OrchardZSA, in addition to those of the Orchard protocol. The subsections are “Asset Digests and Asset Bases”, “Nullifiers of OrchardZSA notes” and “Note commitments”. The commitment to a Custom Asset note reuses the blinding input (z.cash:Orchard-NoteCommit-r,

\varepsilon

) and the Sinsemilla table entries of the Orchard protocol, so they add no row. The table lists input strings only.

Lemma 2.8 (Distinctness of the OrchardZSA group-hash inputs).

The input pairs of Table 3 are pairwise distinct and distinct from every input pair of the Ironwood Guide’s table of §“GroupHash, domain separation, and nothing-up-my-sleeve generators”. Hence, under the Ironwood Guide’s Assumption “GroupHash as a random oracle”, the values of $\mathsf{GroupHash}$ at all these pairs are independent uniform points of $\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})$ , and, under that assumption and the Ironwood Guide’s Assumption “Discrete logarithms on Pallas”, that volume’s Lemma “Relations among fixed generators” applies to any polynomial collection of them together with the Orchard generators. Status: proved here; conditional on no unspecified object.

Proof.

The separator z.cash:OrchardZSA occurs in no row of the Orchard table. Under z.cash:Orchard the Orchard table has only the messages G and K, both distinct from L. Under z.cash:SinsemillaQ it has only the messages z.cash:Orchard-NoteCommit-M, z.cash:Orchard-CommitIvk-M and z.cash:Orchard-MerkleCRH, all distinct from z.cash:ZSA-NoteCommit-M. The three new pairs have pairwise distinct separators or messages. The map from $(D,M)$ to the input hashed by $\mathsf{GroupHash}$ is injective, as the Ironwood Guide’s Remark “Domain separation” records, so distinct pairs are distinct oracle inputs; the random-oracle assumption then gives independent uniform values, and the cited lemma applies verbatim, its hypothesis being only that the inputs are distinct. □

The Ironwood Guide’s Assumption “Collision resistance of BLAKE2b” concerns the $32$ -byte output only. The Asset Digest is a $64$ -byte output, hence a separate assumption.

Assumption 2.9 (Collision resistance of BLAKE2b-512).

No efficient algorithm outputs, except with negligible probability, two inputs $x\neq x^{\prime}$ with $\mathsf{BLAKE2b\text{-}512}(P,x)=\mathsf{BLAKE2b\text{-}512}(P,x^{\prime})$ under one $16$ -byte personalisation $P$ , in the sense of the Crypto Guide’s Definition “Collision resistance” (§“Security notions: preimage, second-preimage, and collision resistance”).

Construction 2.10 (Asset Digest and Asset Base).

For the Asset Identifier $\mathsf{AssetId}$ of a Custom Asset, the Asset Digest is

\mathsf{AssetDigest}_{\mathsf{AssetId}}:=\mathsf{BLAKE2b\text{-}512}(\texttt{% ZSA-Asset-Digest},\mathsf{EncodeAssetId}(\mathsf{AssetId}))\in\mathbb{B}^{% \mathbb{Y}[64]}.

For $D\in\mathbb{B}^{\mathbb{Y}[64]}$ let

\mathsf{ZSAValueBase}(D):=\mathsf{GroupHash}(\texttt{z.cash:OrchardZSA},D)\in% \mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}}),

with $\mathsf{GroupHash}$ the Ironwood Guide’s Construction “GroupHash on Pallas” (protocol specification, §“Group Hash into Pallas and Vesta”); no cofactor is cleared. The separator gives a string $\mathsf{DST}$ within the $255$ -byte bound of that construction. The Asset Base of the Asset is

\mathsf{AssetBase}_{\mathsf{AssetId}}:=\mathsf{ZSAValueBase}(\mathsf{% AssetDigest}_{\mathsf{AssetId}})

(ZIP 227, “Asset Digests”, “Asset Bases” and “OrchardZSA Asset Bases”). The subscript is dropped when the identifier is clear. The whole chain, from issuer and description to Asset Base, is

	$\displaystyle\mathsf{asset\_desc}$	$\displaystyle\xrightarrow{\ \mathsf{BLAKE2b\text{-}256}(\texttt{ZSA-% AssetDescCRH},\cdot)\ }\mathsf{assetDescHash},$
	$\displaystyle(\mathsf{issuer},\mathsf{assetDescHash})=\mathsf{AssetId}$	$\displaystyle\xrightarrow{\ \mathsf{EncodeAssetId}\ }\mathsf{EncodeAssetId}(% \mathsf{AssetId}),$
	$\displaystyle\mathsf{EncodeAssetId}(\mathsf{AssetId})$	$\displaystyle\xrightarrow{\ \mathsf{BLAKE2b\text{-}512}(\texttt{ZSA-Asset-% Digest},\cdot)\ }\mathsf{AssetDigest},$
	$\displaystyle\mathsf{AssetDigest}$	$\displaystyle\xrightarrow{\ \mathsf{ZSAValueBase}\ }\mathsf{AssetBase}.$

Class: specified.

The Asset Identifier is global across the shielded protocols that support Zcash Shielded Assets; the Asset Base is per protocol, the map $\mathsf{ZSAValueBase}$ being instantiated per protocol, here for OrchardZSA (ZIP 227, “Asset Identifier”, “Asset Bases”).

Let $\mathcal{E}^{*}:=\mathcal{E}(\mathbb{F}_{p_{\mathsf{Pallas}}})\setminus\{% \mathcal{O}\}$ . ZIP 226, “Note Structure and Commitment”, types the Asset Base of a note in $\mathcal{E}^{*}$ , as “a valid group element that is not the identity”; ZIP 227 types the Asset Base of an Issue Note (“Issue Note”) and the domain of the issuance state (“Global Issuance State”) likewise. The codomain of $\mathsf{GroupHash}$ , by contrast, is the whole group.

Lemma 2.11 (Non-identity of derived Asset Bases).

Under the Ironwood Guide’s Assumption “GroupHash as a random oracle”, for every $D\in\mathbb{B}^{\mathbb{Y}[64]}$ ,

\mathrm{Pr}[\mathsf{ZSAValueBase}(D)=\mathcal{O}]=1/p_{\mathsf{Vesta}},

and an algorithm that makes $q$ queries to the oracle finds an Asset Identifier whose Asset Base is $\mathcal{O}$ with probability at most $q/p_{\mathsf{Vesta}}$ , the inputs of its output being counted among the queries. Status: proved here; conditional on no unspecified object.

Proof.

In the model each value is uniform on the Pallas group, of order $p_{\mathsf{Vesta}}$ (Ironwood Guide, §“Fields, groups, and encodings”), so it is $\mathcal{O}$ with probability $1/p_{\mathsf{Vesta}}$ . A union bound over the $q$ queries gives the second claim. □

Remark 2.12 (Identity output of the Asset Base derivation).

The map $\mathsf{ZSAValueBase}$ has no case for the identity, and ZIP 227 states no rule for an issuance whose derived Asset Base is $\mathcal{O}$ . The typing in $\mathcal{E}^{*}$ of the Asset Base of an Issue Note and of the domain of the issuance state makes such an issuance unconstructible, hence invalid. Class: specified; the rejection follows from the normative typing in $\mathcal{E}^{*}$ , and ZIP 227 states no separate rule. By Lemma 2.11 the event has negligible probability.

Proposition 2.13 (Separation of Asset Bases).

Let the Ironwood Guide’s Assumption “GroupHash as a random oracle” hold, and consider an algorithm that makes $q$ queries to $\mathsf{GroupHash}$ , the inputs of its output being counted among the queries.

1.

The map $\mathsf{AssetId}\mapsto\mathsf{AssetBase}_{\mathsf{AssetId}}$ is not injective; “unique” in ZIP 226, “Note Structure and Commitment”, means only that it is deterministic.
2.

If the algorithm outputs $\mathsf{AssetId}\neq\mathsf{AssetId}^{\prime}$ with equal Asset Bases, then either it has found a collision of $\mathsf{BLAKE2b\text{-}512}(\texttt{ZSA-Asset-Digest},\cdot)$ on distinct encodings, or it is in an event of probability at most $q^{2}/(2p_{\mathsf{Vesta}})$ .
3.

It outputs an Asset Identifier whose Asset Base equals one of $t$ fixed generators, among them $V^{\mathsf{Orchard}}$ , $R^{\mathsf{Orchard}}$ and $K^{\mathsf{Orchard}}$ , each the value of $\mathsf{GroupHash}$ at an input of the Orchard table or of Table 3 other than the first row, with probability at most $qt/p_{\mathsf{Vesta}}$ .

Hence, under Assumption 2.9, the Ironwood Guide’s Assumptions “Collision resistance of BLAKE2b” and “GroupHash as a random oracle”, and by Proposition 2.7, distinct pairs $(\mathsf{issuer},\mathsf{asset\_desc})$ yield distinct Asset Bases, and no Asset Base of a Custom Asset is an Orchard generator, except with negligible probability. Status: proved here for the specified chain; conditional on no unspecified object.

Proof.

Claim 1. The map is defined on all pairs in $\mathbb{B}^{\mathbb{Y}[33]}\times\mathbb{B}^{\mathbb{Y}[32]}$ , of which there are more than $2^{256}$ , and takes values in a group of prime order $p_{\mathsf{Vesta}}<2^{255}$ ; it is therefore not injective. It is a composition of deterministic maps.

Claim 2. By the injectivity of $\mathsf{EncodeAssetId}$ (Definition 2.6), distinct identifiers have distinct encodings; equal digests of distinct encodings are a BLAKE2b-512 collision under ZSA-Asset-Digest. Otherwise the digests are distinct, hence distinct oracle inputs under z.cash:OrchardZSA, whose values are independent uniform points in the model. Among $q$ queried inputs two share a value with probability at most $\binom{q}{2}/p_{\mathsf{Vesta}}\leq q^{2}/(2p_{\mathsf{Vesta}})$ .

Claim 3. By Lemma 2.8 every input under z.cash:OrchardZSA differs from the inputs of the $t$ generators, so each queried Asset Base is uniform and independent of them, and equals a given one with probability $1/p_{\mathsf{Vesta}}$ . A union bound over the $q$ queries and the $t$ generators gives $qt/p_{\mathsf{Vesta}}$ .

The final sentence composes claims 2 and 3 with Proposition 2.7: distinct pairs of issuer and description yield distinct identifiers except with negligible probability, distinct identifiers yield distinct Asset Bases except with negligible probability by claim 2 and Assumption 2.9, and the bounds of claims 2 and 3 are negligible for polynomial $q$ and $t$ . □

Definition 2.14 (Byte encoding of an Asset Base).

The byte encoding of an Asset Base is the $32$ -byte string

\mathsf{asset\_base}:=\mathsf{LEBS2OSP}_{256}(\mathsf{AssetBase}^{\star})\in% \mathbb{B}^{\mathbb{Y}[32]},

with $\mathsf{LEBS2OSP}_{256}$ and the star encoding those of the Ironwood Guide, §“Fields, groups, and encodings”, Definitions “Integer and byte encodings” and “Star encoding” (ZIP 226, “Note Structure and Commitment”). It is typed as a byte string throughout, although ZIP 226 also types it as a bit string in its clause on the note plaintext. The encoding is canonical on the Pallas group, by the canonicity of the star encoding established after the same Definition; ZIP 226 notes that canonicity may fail for future shielded protocols. Class: specified; its carrier is not.

The placements of $\mathsf{asset\_base}$ in a note plaintext and in the entries of a burn set are encodings of ZIP 230, which is Withdrawn; they are not specified.

Object	Bytes	Defined in	Source
$\mathsf{ik}$	$32$	Definition 2.2	ZIP 227, “Derivation of issuance validating key”
$\mathsf{issuer}=\mathsf{ik\_encoding}$	$33$	Definition 2.4	ZIP 227, “Issuer Identifier”
$\mathsf{issueAuthSig}$	$65$	Definition 2.4	ZIP 227, “Issuance Authorization Signing and Validation”
$\mathsf{assetDescHash}$	$32$	Definition 2.6	ZIP 227, “ZIP 227 Asset Identifiers”
$\mathsf{EncodeAssetId}(\mathsf{AssetId})$	$66$	Definition 2.6	ZIP 227, “ZIP 227 Asset Identifiers”
$\mathsf{AssetDigest}$	$64$	Construction 2.10	ZIP 227, “Asset Digests”
$\mathsf{asset\_base}$	$32$	Definition 2.14	ZIP 226, “Note Structure and Commitment”

Table 4: Sizes along the identity chain, in bytes. ZIP 227 publishes no test vectors, and no worked instance is given.

Every formula of the chain is specified, in Draft ZIP text: the issuance keys and $\mathsf{IssueAuthSig}$ , the identifier $\mathsf{issuer}$ , the hash $\mathsf{assetDescHash}$ , the identifier $\mathsf{AssetId}$ and its encoding, the Asset Digest, the Asset Base, its encoding $\mathsf{asset\_base}$ and the Native Asset Base of §2.4. The identity case is specified, by typing (Remark 2.12). The encodings that would carry the chain on chain belong to the carrier.

2.4 The Native Asset Base

Definition 2.15 (Native Asset Base).

The Native Asset, ZEC on Mainnet and TAZ on Testnet (ZIP 227, “Terminology”), has no Asset Identifier under ZIP 227 and does not pass through the chain of Construction 2.10. Its Asset Base is fixed as

\mathsf{AssetBase}:=V^{\mathsf{Orchard}}=\mathsf{GroupHash}(\texttt{z.cash:% Orchard-cv},\texttt{v}),

the value base of the Ironwood Guide’s Definition “Net value commitment” (§“Value commitments”), where $V^{\mathsf{Orchard}}$ and its companion $R^{\mathsf{Orchard}}=\mathsf{GroupHash}(\texttt{z.cash:Orchard-cv},\texttt{r})$ are constructed; they are cited, not re-derived. ZIP 226, “Asset Identifiers” and “Value Commitment”, writes the definition for ZEC; its burn rules (“Burn Mechanism”, “Additional Consensus Rules for the assetBurn set”) identify the Native Asset, ZEC or TAZ, with the base $V^{\mathsf{Orchard}}$ . Class: specified.

The value commitment and the note commitment of a Native Asset note are computed by the Orchard formulas. Two things differ: the derivation of $\mathsf{rcm}$ takes the OrchardZSA lead byte (Remark 3.6), and the note plaintext carries $\mathsf{asset\_base}$ (Definition 3.7; ZIP 226, “Note Structure and Commitment”). The value commitment of ZIP 226, “Value Commitment”, is $[v^{\mathsf{net}}]\,\mathsf{AssetBase}+[\mathsf{rcv}]\,R^{\mathsf{Orchard}}$ , which at the base $V^{\mathsf{Orchard}}$ is the Orchard net value commitment $[v^{\mathsf{net}}]\,V^{\mathsf{Orchard}}+[\mathsf{rcv}]\,R^{\mathsf{Orchard}}$ of the cited Definition. The note commitment of ZIP 226, “Note Structure and Commitment”, is by its case split the Orchard note commitment when the Asset Base is $V^{\mathsf{Orchard}}$ ; the case split is stated in “Note commitments” (§3.2). The base $V^{\mathsf{Orchard}}$ is a group-hash output under a separator distinct from z.cash:OrchardZSA, so by Proposition 2.13 no Asset Base of a Custom Asset equals it, except with negligible probability.