ZSA Guide Zcash Shielded Assets: asset identity, issuance, transfer, and burn 5 Burn and the binding signature 7 The global issuance state

6 Issuance of Custom Assets

This section constructs the objects of ZIP 227 that create value of a Custom Asset: the Issue Note and the rule by which validators compute its commitment (§6.1); the Issuance Action and the Issuance Bundle that carry Issue Notes (§6.2); the element $\rho$ of an Issue Note, derived from the first nullifier of the Action Group (§6.3); the reference note (§6.4); and the rules and the digest hypothesis that bind an Issuance Bundle to its issuer and to one transaction (§6.5). Issuance is public. The one privacy property that it keeps, the unlinkability of a later spend of an Issue Note, is proved in §6.1. The rules that update the global issuance state are those of “The global issuance state” (§7). Every construction of the section is taken from ZIP 227, which is Draft, together with the objects of ZIP 226 that it uses.

6.1 Issue Notes

Definition 6.1 (Issue Note).

An Issue Note represents the issuance of a value $v$ of one Custom Asset to one recipient. It is a tuple

(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\mathsf{rseed})

of type

	$\displaystyle\mathsf{Note}^{\mathsf{Issue}}:={}$	$\displaystyle\{0,1\}^{88}\times\bigl{(}\mathcal{E}(\mathbb{F}_{p_{\mathsf{% Pallas}}})\setminus\{\mathcal{O}\}\bigr{)}\times\{0,\dots,2^{64}-1\}$
		$\displaystyle\times\mathcal{E}^{*}\times\mathbb{F}_{p_{\mathsf{Pallas}}}\times% \mathbb{B}^{\mathbb{Y}[32]},$

with the following components.

1.

The pair $(d,\mathsf{pk_{d}})$ is the recipient’s address, of the type of the Ironwood Guide’s Construction “Diversified address”: the diversifier $d$ and the diversified transmission key $\mathsf{pk_{d}}$ , a point other than the identity (ZIP 227 types it in $\mathsf{KA}^{\mathsf{Orchard}}.\mathsf{Public}$ , protocol specification, §“Orchard Key Components”).
2.

The value $v$ counts units of the Asset. The lengths $88$ and $64$ are the constants $\ell_{\mathsf{d}}$ and $\ell_{\mathsf{value}}$ of the protocol specification, §“Constants”.
3.

The point $\mathsf{AssetBase}\in\mathcal{E}^{*}$ is the Asset Base of the Custom Asset issued (Construction 2.10).
4.

The element $\rho$ is fixed by Construction 6.7, in “Computation of $\rho$ for Issue Notes” (§6.3).
5.

The note seed $\mathsf{rseed}$ is a $32$ -byte string that the issuer MUST sample uniformly at random.

An Issue Note carries no $\psi$ and no $\mathsf{rcm}$ ; both are to be derived from $\mathsf{rseed}$ (Remark 6.2). ZIP 227 writes the fourth and fifth factors of the type as $\mathbb{P}^{*}$ and $\mathbb{F}_{q_{\mathbb{P}}}$ (Table 1; ZIP 227, “Issue Note”). Class: specified.

Commitments of Issue Notes. No note commitment of an Issue Note is transmitted. Every validator MUST compute the commitment $\mathsf{cm}$ of each Issue Note by $\mathsf{NoteCommit}^{\mathsf{OrchardZSA}}$ (Definition 3.2), exactly as for an OrchardZSA note with the same fields, and, when the transaction is included in the block chain, append its extracted form $\mathsf{cmx}$ to the note commitment tree after the commitments of the Action Group’s Actions. The order is Definition 7.4, in “State transition of a transaction” (§7.2), and the tree is the one that Remark 1.7 leaves open (ZIP 227, “Issue Note”, “Specification: Consensus Rule Changes” and “Addition to the Note Commitment Tree”). Class: specified; its evaluability is qualified by Remark 6.2.

Remark 6.2 (Commitment inputs of an Issue Note).

The OrchardZSA note of an Issue Note $(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\mathsf{rseed})$ is $(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\psi,\mathsf{rcm})$ , with $\psi$ and $\mathsf{rcm}$ derived from $\mathsf{rseed}$ as in Definition 3.5. With $\underline{\rho}:=\mathsf{I2LEOSP}_{256}(\rho)$ and $\mathsf{g_{d}}:=\mathsf{DiversifyHash}(d)$ ,

	$\displaystyle\psi$	$\displaystyle:=\mathrm{ToBase}\bigl{(}\mathsf{PRFexpand}_{\mathsf{rseed}}([% \mathtt{0x09}]\,\\|\,\underline{\rho})\bigr{)},$
	$\displaystyle\mathsf{rcm}$	$\displaystyle:=\mathsf{Derive\_rcm}_{\mathsf{rseed}}(\mathsf{leadByte},\mathsf% {g_{d}}^{\star},\mathsf{pk_{d}}^{\star},v,\underline{\rho},\psi).$

The derivation of $\psi$ does not depend on the lead byte and is specified. The derivation of $\mathsf{rcm}$ is designed but unspecified, and the value of its lead byte is an open problem (Remark 3.6). An Issue Note has no plaintext that could carry a lead byte. Three consequences follow.

(a)

Until the value is assigned, the commitment that every validator MUST compute is not computable from live text. The gap is at consensus level. For the created note of a transfer the same gap binds only sender and recipient, since consensus sees only $\mathsf{cmx}$ .
(b)

The recipient needs the same $\mathsf{rcm}$ to open the commitment when it spends the note, in condition A1^′ of Definition 4.6.
(c)

The Ironwood Guide’s Proposition “Hiding under the derived trapdoor” does not transfer to Issue Notes. Hiding plays no role for them: every field, $\mathsf{rseed}$ included, is public (Remark 6.6).

(ZIP 227, “Issue Note” and “Specification: Consensus Rule Changes”; ZIP 226, “Note Structure and Commitment”; ZIP 2005, “Changes to the Protocol Specification”, amending the protocol specification’s §“Sending Notes (Orchard)”.)

Remark 6.3 (Commitment $\bot$ for an Issue Note).

The commitment $\mathsf{NoteCommit}^{\mathsf{OrchardZSA}}$ may return $\bot$ . For a note created by an Action, the sender repeats the derivation with a new $\mathsf{rseed}$ when the extracted commitment is $\bot$ (protocol specification, §“Sending Notes (Orchard)”). ZIP 227 states no rule for an Issue Note whose commitment is $\bot$ , and no text proposes one: the consequence for the transaction is an open problem. An Issue Note is in the custom branch of Definition 3.2, its Asset Base being a derived one (Proposition 2.13), where the commitment is $\bot$ only if the hash point is; for uniform $\mathsf{rseed}$ the event therefore has negligible probability, by Proposition 3.3(c) (ZIP 227, “Issue Note” and “Specification: Consensus Rule Changes”).

Proposition 6.4 (Unlinkability of spends of Issue Notes).

Let a key be generated with $\mathsf{use\_qsk}=\mathsf{false}$ from a uniform spending key, with nullifier deriving key $\mathsf{nk}$ . Consider the game of the Ironwood Guide’s Proposition “Nullifier unlinkability”, modified as follows. The adversary, which receives $(\mathsf{dk},\mathsf{ivk})$ and $\mathsf{ak}^{\mathbb{P}}$ but not $\mathsf{nk}$ , submits adaptively Issue Notes $n_{i}$ of its choice, in particular to addresses of the key, each published in full as issuance publishes it, together with elements $\psi_{i}\in\mathbb{F}_{p_{\mathsf{Pallas}}}$ and $\mathsf{rcm}_{i}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$ of its choice, such that the elements $\rho_{i}$ are pairwise distinct and the OrchardZSA commitments $\mathsf{cm}_{i}$ of the notes $(d_{i},\mathsf{pk}_{\mathsf{d},i},v_{i},\mathsf{AssetBase}_{i},\rho_{i},\psi_{% i},\mathsf{rcm}_{i})$ are not $\bot$ . In the real game it receives the nullifier $\mathsf{DeriveNullifier}_{\mathsf{nk}}(\rho_{i},\psi_{i},\mathsf{cm}_{i})$ that a later spend of the note publishes by condition A5^′ with $\mathsf{split\_flag}=0$ ; in the ideal game it receives $\mathsf{Extract}_{\mathbb{P}}([u_{i}]\,K^{\mathsf{Orchard}}+\mathsf{cm}_{i})$ for independent uniform $u_{i}\in\mathbb{F}_{p_{\mathsf{Vesta}}}$ . Then its distinguishing advantage is at most the bound of the cited proposition, which is negligible under the assumptions that proposition names, the Ironwood Guide’s Assumption “Poseidon is a PRF” among them.

The ideal answers are independent of the published notes when $K^{\mathsf{Orchard}}\neq\mathcal{O}$ , so a spend’s nullifier does not link it to its issuance for any party without $\mathsf{nk}$ , the issuer included. The statement holds for every $\psi_{i}$ and every $\mathsf{rcm}_{i}$ , in particular for the derived $\psi_{i}$ and for any value that a future lead byte gives $\mathsf{rcm}_{i}$ ; it is therefore independent of the open lead byte. It concerns the nullifier only; the other published components of the spending Action are treated in “Hiding of the Asset type” (§9.5). It fails for the reference note (Definition 6.10), whose recipient key is the all-zero spending key: its $\mathsf{nk}$ is public, and its nullifier is computable by anyone. Status (Definition 1.3): proved here for the specified construction; conditional on the assumptions of the cited proposition. ZIP 227, “Issue Note”, states the property as rationale.

Proof.

The proof is that of the Ironwood Guide’s Proposition “Nullifier unlinkability”. Its game already lets the adversary choose every field of every submitted note, so publishing an Issue Note in full, $\mathsf{rseed}$ included, gives the adversary nothing that it does not hold. Its hybrids use a submitted note only through the triple $(\rho_{i},\psi_{i},\mathsf{cm}_{i})$ , with $\mathsf{cm}_{i}$ a point other than $\bot$ and the $\rho_{i}$ pairwise distinct: the hops $H_{1}$ to $H_{3}$ change the key material only, the hop $H_{4}$ uses the distinctness of the $\rho_{i}$ for the lazily sampled random function, and the hop $H_{5}$ and the final statement use $\mathsf{cm}_{i}$ only as a point to which $[s_{i}]\,K^{\mathsf{Orchard}}$ or $[u_{i}]\,K^{\mathsf{Orchard}}$ is added. The nullifier of an OrchardZSA note is $\mathsf{DeriveNullifier}$ of the Ironwood Guide’s Definition “Nullifier” with the OrchardZSA commitment in place of the Orchard one (ZIP 226, “Note Structure and Commitment”; §4.2). Every hybrid and every bound therefore carries over verbatim. The hypothesis that the $\rho_{i}$ are pairwise distinct is supplied, for the Issue Notes of a valid chain, by Proposition 6.9, except with negligible probability.

For the reference note, $\mathsf{nk}:=\mathrm{ToBase}(\mathsf{PRFexpand}_{\mathsf{sk}}([\mathtt{0x07}]))$ with $\mathsf{sk}$ the all-zero string (Ironwood Guide, §“The spending key and the spend-side secrets”) is a public constant, so the real answer is computable from public data and differs from the ideal one. □

6.2 Issuance Actions and Issuance Bundles

ZIP 227 specifies issuance through three components: the Issuance Bundle of a transaction, in which a publicly named issuer creates Issue Notes; the flag $\mathsf{finalize}$ of each Issuance Action, which, once set, ends issuance of its Asset permanently; and the global issuance state kept by every node, constructed in “The global issuance state” (§7).

Definition 6.5 (Issuance Action and Issuance Bundle).

Let

\mathsf{IssueNoteFields}:=\{0,1\}^{88}\times\bigl{(}\mathcal{E}(\mathbb{F}_{p_% {\mathsf{Pallas}}})\setminus\{\mathcal{O}\}\bigr{)}\times\{0,\dots,2^{64}-1\}% \times\mathbb{F}_{p_{\mathsf{Pallas}}}\times\mathbb{B}^{\mathbb{Y}[32]},

the fields $(d,\mathsf{pk_{d}},v,\rho,\mathsf{rseed})$ of an Issue Note without its Asset Base.

1.

An Issuance Action is a triple $(\mathsf{assetDescHash},\mathsf{vNotes},\mathsf{flagsIssuance})$ , where the hash $\mathsf{assetDescHash}\in\mathbb{B}^{\mathbb{Y}[32]}$ is the description hash of Definition 2.6; $\mathsf{vNotes}$ is a finite sequence of elements of $\mathsf{IssueNoteFields}$ , the unencrypted Issue Notes of the Asset; and $\mathsf{flagsIssuance}$ is a byte that carries the Boolean $\mathsf{finalize}$ , which the issuer sets to signal that no further issuance of the Asset will occur.
2.

An Issuance Bundle is a triple $(\mathsf{issuer},\mathsf{vIssueActions},\mathsf{issueAuthSig})$ , where $\mathsf{issuer}=\mathsf{ik\_encoding}\in\mathbb{B}^{\mathbb{Y}[33]}$ is the issuer identifier of Definition 2.4; $\mathsf{vIssueActions}$ is a finite sequence of Issuance Actions; and $\mathsf{issueAuthSig}=[\mathtt{0x00}]\,\|\,\sigma$ encodes a signature $\sigma$ by $\mathsf{isk}$ on the transaction’s $\mathsf{SigHash}$ (Definition 6.12).

The pair $(\mathsf{issuer},\mathsf{assetDescHash})$ is an Asset Identifier and determines $\mathsf{AssetBase}$ by Construction 2.10. With it, each element $(d,\mathsf{pk_{d}},v,\rho,\mathsf{rseed})$ of $\mathsf{vNotes}$ determines the Issue Note $(d,\mathsf{pk_{d}},v,\mathsf{AssetBase},\rho,\mathsf{rseed})$ of Definition 6.1 completely. The commitment is omitted, because every validator recomputes it (ZIP 227, “Issuance Action”, “Issuance Bundle”, “Issue Note” and “Issuance Protocol”). Class: specified.

Encoding status. The byte encoding of the Issuance Bundle and of the Issuance Action exists only in withdrawn ZIP 230 and is designed but unspecified; it is not the version- $6$ format of ZIP 229 (Remark 8.1; ZIP 227, “Issuance Action” and “Issuance Bundle”).

Issuance Actions without notes. The rules of ZIP 227 place no requirement on the number of Issue Notes of an Issuance Action. Withdrawn ZIP 230 admits an Issuance Action with none, so that an issuer can finalise an issued Asset without issuing more of it. The validity of such an action for an Asset without an entry in the issuance state is the open case of Remark 7.5, in “State transition of a transaction” (§7.2) (ZIP 227, “Specification: Consensus Rule Changes”; ZIP 230, “Issuance Action Description”).

Remark 6.6 (Public issuance).

ZIP 227 enables only public issuance, so that the supply of each Asset can be tracked (ZIP 227, “Motivation”; “Requirements”: the issuance mechanism should enable public tracking of the supply). The Issue Notes are unencrypted. The issuer, the Asset (through $\mathsf{assetDescHash}$ , from which anyone recomputes $\mathsf{AssetBase}$ ), every value, every recipient address, every $\rho$ and $\mathsf{rseed}$ , and every flag $\mathsf{finalize}$ are public, so issuance publicly links each recipient address to an Asset and an amount. Since $\mathsf{rseed}$ is public, so is $\psi$ , and so, once the lead byte is assigned, are the commitment and the leaf of each Issue Note. With the public burn set (Definition 5.1), the amount of each Asset in circulation, issued less burnt, is a public function of the chain, which ZIP 227 records as the balance of the global issuance state (“Global Issuance State”). The later use of an Issue Note remains private, to the extent of Proposition 6.4. In this volume issuance is called public and Issue Notes unencrypted (ZIP 227, “Issuance Action”).

6.3 Computation of $\rho$ for Issue Notes

An Issue Note is created outside any Action, so the Ironwood Guide’s Construction “Chaining rule” (§“Nullifier chaining”) gives it no $\rho$ .

Construction 6.7 (Derivation of issued rho values).

Define

\mathsf{DeriveIssuedRho}\colon\mathbb{F}_{p_{\mathsf{Pallas}}}\times\{0,\dots,% 2^{32}-1\}\times\{0,\dots,2^{32}-1\}\to\mathbb{F}_{p_{\mathsf{Pallas}}}

	$\displaystyle\mathsf{DeriveIssuedRho}(\mathsf{nf},i_{A},i_{N})$
	$\displaystyle\quad:=\mathrm{ToBase}\bigl{(}\mathsf{PRFexpand}_{\mathsf{I2LEOSP% }_{256}(\mathsf{nf})}([\mathtt{0x84}]\,\\|\,\mathsf{I2LEOSP}_{32}(i_{A})\,\\|\,% \mathsf{I2LEOSP}_{32}(i_{N}))\bigr{)},$

with $\mathsf{PRFexpand}$ the Ironwood Guide’s Construction “Expansion function” and $\mathrm{ToBase}$ its Definition “Field reductions”. The expansion input after the key has $1+4+4=9$ bytes. The element $\rho$ of the Issue Note at zero-based position $i_{N}$ of the Issuance Action at zero-based position $i_{A}$ of the Issuance Bundle is

\rho:=\mathsf{DeriveIssuedRho}(\mathsf{nf}_{0,0},i_{A},i_{N}),

where $\mathsf{nf}_{0,0}$ is the nullifier published by the first Action of the transaction’s Action Group (Definition 4.13), whatever the kind of its consumed note. The definition presupposes an Action Group, which rule (I1) of Definition 6.12 enforces. The derivation adds one row to the Ironwood Guide’s Construction “Domain bytes of PRF expansion”:

$b$	Key $\kappa$	Remainder $t^{\prime}$	$f$	Output	Section
$\mathtt{0x84}$	$\mathsf{I2LEOSP}_{256}(\mathsf{nf}_{0,0})$	$\mathsf{I2LEOSP}_{32}(i_{A})\,\\|\,\mathsf{I2LEOSP}_{32}(i_{N})$	$\mathrm{ToBase}$	$\rho$	§6.3

The key is a public nullifier. No other ZIP and no section of the protocol specification uses the byte $\mathtt{0x84}$ , and no registry of a lower volume lists it. Because the key is public, neither the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion” nor its Lemma “Independence of domain-separated expansions” applies (ZIP 227, “Computation of $\rho$ ”; protocol specification, §“Pseudo Random Functions” and §“Orchard Key Components”). Class: specified.

Assumption 6.8 (BLAKE2b-512 as a random oracle).

For each fixed $16$ -byte personalisation $P$ , the function $x\mapsto\mathsf{BLAKE2b\text{-}512}(P,x)$ is a random oracle with $512$ -bit output in the sense of the Crypto Guide’s Definition “Random oracle” (§“The random oracle model”), independent of the oracles of the other personalisations. It is used for the personalisation Zcash_ExpandSeed of $\mathsf{PRFexpand}$ , where the key of Construction 6.7 is public. For a secret uniform key and an adversary that makes polynomially many oracle queries, it implies the Ironwood Guide’s Assumption “Pseudorandomness of PRF expansion”. Its uses in this volume are Proposition 6.9 and Lemma 9.6, whose proof programs one query of the oracle.

Proposition 6.9 (Uniqueness of issued rho values).

(a)

The expansion inputs, key and remainder, of the Issue Notes of a valid chain are pairwise distinct, and each differs from the input of every other row of $\mathsf{PRFexpand}$ .
(b)

Under Assumption 6.8, consider an execution in which at most $q$ queries in total are made to the oracle of personalisation Zcash_ExpandSeed. The probability that two Issue Notes of the chain have equal $\rho$ , or that the $\rho$ of an Issue Note equals one of $M$ elements $\rho$ of notes created by Actions and fixed before the query that yields it, is at most

$\Bigl{(}\frac{q(q-1)}{2}+qM\Bigr{)}\Bigl{(}\frac{1}{p_{\mathsf{Pallas}}}+2^{-5% 12}\Bigr{)}\leq\frac{(q+M)^{2}}{p_{\mathsf{Pallas}}}.$

With no query beyond the $N$ issued values, $q=N$ .

Literal uniqueness is not claimed, nor distinctness from the $\rho$ of notes created by later Actions, which the derivation does not control. Distinct OrchardZSA notes have distinct commitments by Proposition 3.3(b). The proof of the Ironwood Guide’s Proposition “Nullifier uniqueness” then applies with the hash base and message of each note’s branch of Definition 3.2, which unfold as in the proof of Proposition 4.5(i). So distinct notes have distinct nullifiers whatever their $\rho$ , and a collision can affect only notes equal in every field. The proposition extends to Issue Notes part (a) of the Ironwood Guide’s Corollary “Faerie Gold resistance”, which covers only notes created by Actions. Status (Definition 1.3): proved here for the specified derivation; conditional on Assumption 6.8.

Proof.

(a) Within a transaction the key is one and the index pairs $(i_{A},i_{N})$ differ. Across transactions of a valid chain the keys $\mathsf{I2LEOSP}_{256}(\mathsf{nf}_{0,0})$ differ: $\mathsf{nf}_{0,0}$ is a published nullifier, and the nullifier-set rule forbids a nullifier to repeat within a pool (Ironwood Guide, §“Nullifier sets”; the pool is that of Remark 1.7), and $\mathsf{I2LEOSP}_{256}$ is injective on $\mathbb{F}_{p_{\mathsf{Pallas}}}$ . The oracle input is the $32$ -byte key followed by the remainder. Every key of $\mathsf{PRFexpand}$ is a $32$ -byte string (Ironwood Guide, Construction “Expansion function”), so the byte after the key is the lead byte, and $\mathtt{0x84}$ differs from the lead byte of every other row.

(b) By (a) each issued $\rho$ is $\mathrm{ToBase}$ of the oracle value at an input of its own. In the lazy form of the Crypto Guide’s Definition “Random oracle”, the first query at an input returns a fresh uniform $512$ -bit string, independent of all earlier values. The map $\mathrm{ToBase}$ takes each value of $\mathbb{F}_{p_{\mathsf{Pallas}}}$ on at most $\lceil 2^{512}/p_{\mathsf{Pallas}}\rceil$ strings, so the fresh output equals a value fixed before the query with probability at most $\lceil 2^{512}/p_{\mathsf{Pallas}}\rceil/2^{512}<1/p_{\mathsf{Pallas}}+2^{-512}$ . Every issued $\rho$ is the reduced output of one of the $q$ queries. A union bound over the at most $q(q-1)/2$ pairs of queries and the $q M$ pairs of a query and a fixed value (Math Guide, §“The union bound and a birthday calculation”, Theorem “Union bound / Boole’s inequality” and Proposition “Birthday bound”) gives the first bound. The second follows from $2(q(q-1)/2+qM)\leq(q+M)^{2}$ and $1+p_{\mathsf{Pallas}}\,2^{-512}<2$ . □

6.4 Reference notes

Definition 6.10 (Reference note).

The first Issue Note of the Issuance Action in which a Custom Asset is issued for the first time MUST be a reference note: an Issue Note with $v=0$ , the Asset Base of that Asset, and recipient $(d,\mathsf{pk_{d}})$ the default diversified address, of diversifier index $0$ , of the all-zero Orchard spending key $\mathsf{sk}=[\mathtt{0x00}]^{32}$ . The address is derived by the Ironwood Guide’s constructions of §“The spending key and the spend-side secrets”, §“Viewing keys” and Construction “Diversified address”. The all-zero key passes every acceptance condition of key generation: $\mathsf{ask}\neq 0$ ; $\mathsf{ivk}\notin\{0,\bot\}$ ; and the incoming viewing key of its internal key (ZIP 32, “Orchard internal key derivation”) is not in $\{0,\bot\}$ , the condition of the protocol specification, §“Orchard Key Components”. At index $0$ the diversified base $\mathsf{g_{d}}$ is not the identity. The raw encoding of the address, $\mathsf{LEBS2OSP}_{88}(d)\,\|\,\mathsf{LEBS2OSP}_{256}(\mathsf{pk_{d}}^{\star})$ (protocol specification, §“Orchard Raw Payment Addresses”), is the $43$ -byte string, given in ZIP 227, “Reference Notes”, as

	$\displaystyle($	$\displaystyle 204,54,96,25,89,33,59,107,12,219,150,167,92,23,195,166,$
		$\displaystyle 104,169,127,13,106,140,92,225,100,165,24,234,155,169,165,$
		$\displaystyle 14,167,81,145,253,134,27,15,241,14,98,176).$

Recomputing the address and every acceptance check from the cited constructions reproduces this array. Validators enforce the rule and store the reference note as $\mathsf{note}_{\mathsf{ref}}$ in the global issuance state, by rule (I5) of Construction 7.3, in “State transition of a transaction” (§7.2) (ZIP 227, “Reference Notes” and “Specification: Consensus Rule Changes”). Class: specified; the reference note is mandated and stored in consensus state, and no section of ZIP 227 states its purpose.

Proposition 6.11 (Reference notes as universal Split Inputs).

Let $n_{\mathsf{ref}}$ be the reference note of a Custom Asset with Asset Base $B$ , its extracted commitment a leaf of the note commitment tree.

(a)

Any party can construct a Split Action (Definition 4.2) whose Split Input copies $n_{\mathsf{ref}}$ , with a witness of Definition 4.6 and a spend-authorisation signature that verifies under its $\mathsf{rk}$ , for a created note of Asset Base $B$ and value $0$ to any receiver of its choice. Proposition 4.12 therefore imposes nothing on $n_{\mathsf{ref}}$ , whose recipient key is public by construction.
(b)

Let an efficient adversary output OrchardZSA bundles of valid blocks whose Action proofs and binding signatures verify and whose witnessed and burn-pair Asset Bases meet the premise on the bases of §5.3. Except with negligible probability, in every such bundle in which no extracted witness of Asset Base $B$ has $\mathsf{split\_flag}=0$ , every created note of Asset Base $B$ has value $0$ , and the burn set has no pair of Asset Base $B$ .

Hence $n_{\mathsf{ref}}$ serves exactly the created notes of $B$ that a party holding no note of $B$ can produce. Under Remark 1.7, a copy to a receiver other than that of the copied note would violate the cross-address rule if the notes were in the Orchard pool. Status (Definition 1.3): proved here for the specified constructions; part (a) is conditional on the open lead byte (Remark 6.2); part (b) is conditional on Assumption 4.9 through Proposition 5.6, and its premise on the bases is discharged for valid chains in “Security” (§9). The reading of the purpose is the volume’s; ZIP 227 states none.

Proof.

(a) The construction is explicit. The all-zero spending key is accepted (Definition 6.10), so its $\mathsf{ask}$ , $\mathsf{nk}$ , $\mathsf{r_{ivk}}$ and $\mathsf{ak}^{\mathbb{P}}$ are public constants. The note $n_{\mathsf{ref}}$ is published unencrypted with $\rho$ and $\mathsf{rseed}$ (Remark 6.6), so $\psi$ is public and, once the lead byte is assigned (Remark 6.2), so are $\mathsf{rcm}$ and the commitment. The position of its leaf in the tree is public, by Definition 7.4. The party takes a valid anchor $\mathit{rt}$ whose tree contains the leaf and computes its authentication path, which satisfies A3^′; it opens A1^′ with the fields of $n_{\mathsf{ref}}$ and $v^{\mathsf{old}}=0$ ; it sets $\mathsf{split\_flag}=1$ , $\mathsf{is\_native\_asset}=0$ and $\mathsf{enableZSA}=1$ , which satisfy C1 to C3 since $B\neq V^{\mathsf{Orchard}}$ ; it draws $\psi^{\mathsf{nf}}$ and computes the split nullifier of A5^′ with the public $\mathsf{nk}$ ; it creates a note of base $B$ , value $0$ and any receiver, whose commitment satisfies A2^′, and takes any $\mathsf{rcv}$ for A4^′, which reads $v^{\prime}=0$ and $v^{\mathsf{new}}=0$ . Conditions A6 and A7 hold with the public $(\mathsf{ak},\mathsf{nk},\mathsf{r_{ivk}})$ , from which the reference address is derived; A8 holds since $v^{\mathsf{old}}=0$ , and A9 since $v^{\mathsf{new}}=0$ . The party signs under $\mathsf{rsk}=\mathsf{ask}+\alpha$ for its randomiser $\alpha$ , as any owner does.

(b) By Proposition 5.6(a), except with negligible probability, the net values of the Actions of base $B$ , read from the extracted witnesses, sum as integers to the burnt amount $v_{B}$ , which is $0$ if $B$ is not burnt. Every such Action has $\mathsf{split\_flag}=1$ , so its value $v^{\prime}$ is $0$ by the notation of Definition 4.6, and the sum is $-\sum_{i}v^{\mathsf{new}}_{i}\leq 0$ . A burn pair has $v_{B}>0$ by rule (B2) of Definition 5.1, so $v_{B}\geq 0$ . Both sides therefore vanish: every $v^{\mathsf{new}}_{i}$ of base $B$ is $0$ , and $v_{B}=0$ excludes a pair of base $B$ . □

6.5 Issuance authorisation

Definition 6.12 (Issuance authorisation rules).

For a transaction that contains an Issuance Bundle $(\mathsf{issuer},\mathsf{vIssueActions},\mathsf{issueAuthSig})$ :

(I1)

It MUST contain an OrchardZSA Action Group; by Definition 4.13 it contains exactly one.
(I2)

The encoding $\mathsf{ik\_encoding}$ of the issuance validating key $\mathsf{ik}$ MUST be taken from the field $\mathsf{issuer}$ and MUST start with the byte $\mathtt{0x00}$ , which indicates a BIP-340 public key; $\mathsf{ik}$ is the remaining $32$ bytes (Definition 2.4).
(I3)

The first byte of $\mathsf{issueAuthSig}$ MUST be $\mathtt{0x00}$ , and

$\mathsf{IssueAuthSig}.\mathsf{Validate}(\mathsf{ik},\mathsf{SigHash},\sigma)=1$

MUST hold for the $64$ -byte $\sigma$ that follows it (Definition 2.2). ZIP 227 writes the rule with $\mathsf{issueAuthSig}$ in place of $\sigma$ ; the scheme byte is stripped because $\mathsf{Validate}$ is typed over $32$ -byte keys and $64$ -byte signatures.

For every Issuance Action the Issue Notes are then constructed from the elements of its $\mathsf{vNotes}$ , with $\mathsf{AssetBase}$ derived from its $\mathsf{assetDescHash}$ and from $\mathsf{issuer}$ (Remark 6.14). The rules on the issuance state, (T1) to (T4) and (I4) to (I7), are Construction 7.3. The message $\mathsf{SigHash}$ is the transaction’s signature digest (Ironwood Guide, Definition “Signature digest”), which ZIP 227 defines by the protocol specification’s §“SIGHASH Transaction Hashing” “with the modifications described in ZIP 226”, under $\mathsf{SIGHASH\_ALL}$ . The cited section of ZIP 226 does not exist; ZIP 226, “Sighash modifications relative to ZIP 244”, defers to ZIP 246, which is Withdrawn; and the version- $6$ digest of ZIP 229 has no issuance child (ZIP 227, “Specification: Consensus Rule Changes” and “Issuance Authorization Signing and Validation”). Class: rules (I1) to (I3) specified; the signed message designed but unspecified (Remark 8.3).

Assumption 6.13 (Coverage of the signature digest).

The signature digest $\mathsf{SigHash}$ of an OrchardZSA transaction is computed without any signature of the transaction: neither $\mathsf{issueAuthSig}$ , nor a spend-authorisation signature, nor the binding signature is an input. No efficient algorithm outputs, except with negligible probability, two transactions with equal $\mathsf{SigHash}$ that differ in

(i)

the effecting data of the Issuance Bundle: $\mathsf{issuer}$ , the number and order of the Issuance Actions, and, per Issuance Action, $\mathsf{assetDescHash}$ , $\mathsf{finalize}$ and every field $(d,\mathsf{pk_{d}},v,\rho,\mathsf{rseed})$ of every Issue Note;
(ii)

the burn set; or
(iii)

the published data of the Actions of the Action Group, in particular $\mathsf{nf}_{0,0}$ .

This hypothesis (H-SIG) concerns a designed but unspecified object. “Transaction digests and the signature message” (§8.2) shows that the digest of withdrawn ZIP 246 meets it under the Ironwood Guide’s Assumption “Collision resistance of BLAKE2b”, and states it as the obligation on any future digest (Remark 8.2). The version- $6$ digest of ZIP 229 does not meet (i).

Remark 6.14 (Recomputation of issued Asset Bases).

Of the identity chain of Construction 2.10, consensus sees exactly two links on the issuance side: $\mathsf{issuer}$ in the Issuance Bundle and $\mathsf{assetDescHash}$ in each Issuance Action. The Asset Identifier, the Asset Digest and the Asset Base of issued notes are never transmitted. Every validator derives

	$\displaystyle\mathsf{AssetBase}:=\mathsf{ZSAValueBase}\bigl{(}$	$\displaystyle\mathsf{BLAKE2b\text{-}512}(\texttt{ZSA-Asset-Digest},$
		$\displaystyle\mathsf{EncodeAssetId}(\mathsf{issuer},\mathsf{assetDescHash}))% \bigr{)}$

by that construction. The same bytes $\mathsf{issuer}$ name the Asset and yield, by (I2), the key under which (I3) verifies the signature; under Assumption 6.13(i), both $\mathsf{issuer}$ and $\mathsf{assetDescHash}$ are in the signed message. The consequence for authority over issuance is Theorem 9.8, in “Authority over issuance” (§9.4) (ZIP 227, “Specification: Consensus Rule Changes” and “Issuance Bundle”).

Remark 6.15 (Signing order of an issuance bundle).

Every $\rho$ of an Issue Note is a function of $\mathsf{nf}_{0,0}$ (Construction 6.7), fixed once the first Action of the Action Group is fixed. Under Assumption 6.13 the signed digest covers every $\rho$ and every other effecting field of the transaction. The issuer can therefore sign only after the nullifier of the first Action and all effecting data are fixed. Its message is the $\mathsf{SIGHASH\_ALL}$ digest that every spend-authorisation signature and the binding signature sign (Ironwood Guide, Definition “Signature digest”; ZIP 227, “Computation of $\rho$ ”, “Issuance Protocol” and “Specification: Consensus Rule Changes”).

Proposition 6.16 (Replay protection of issuance).

Let $\mathsf{ik}$ be the issuance validating key of an honest issuer, which signs only digests $\mathsf{SigHash}$ of transactions it builds. Except with negligible probability, in a valid chain produced by an efficient adversary that obtains the honest issuer’s signatures:

(a)

every Issuance Bundle whose $\mathsf{issuer}$ is $\mathsf{ik\_encoding}$ of $\mathsf{ik}$ belongs to a transaction whose $\mathsf{SigHash}$ the issuer signed;
(b)

no transaction of the chain that contains an Issuance Bundle has the $\mathsf{SigHash}$ of another transaction of the chain.

Hence each digest that the issuer signs authorises the issuance of at most one transaction of the chain. Rule (I1) is what makes (b) hold: without an Action Group, the digest of a transaction that carries only an Issuance Bundle depends on no value that the chain forbids to repeat, and a duplicate of the bundle in a transaction with the same remaining digest inputs has the same $\mathsf{SigHash}$ , so its signature verifies again (ZIP 227, “Rationale”). Status (Definition 1.3): proved here for the specified rules (I1) to (I3); conditional on Assumption 6.13, a hypothesis on the designed but unspecified signed message, and on Assumption 2.3. ZIP 227, “Rationale”, states the replay argument informally.

Proof.

(a) An accepted bundle satisfies (I2) and (I3), so its signature verifies on the transaction’s $\mathsf{SigHash}$ under the key whose encoding is $\mathsf{issuer}$ , which is $\mathsf{ik}$ by the injectivity of $\mathsf{ik}\mapsto\mathsf{issuer}$ (Definition 2.4). A verifying signature on a digest that the issuer never signed is an existential forgery against Assumption 2.3: the reduction answers the adversary’s requests for the issuer’s signatures with its signing oracle and outputs the digest and the signature of the chain.

(b) By (I1) a transaction with an Issuance Bundle has an Action Group, and so a nullifier $\mathsf{nf}_{0,0}$ . Another transaction of the chain with equal $\mathsf{SigHash}$ has, by Assumption 6.13(iii), the same published Action data, except with negligible probability, since the chain is the output of an efficient algorithm; in particular it publishes $\mathsf{nf}_{0,0}$ as well. The nullifier-set rule forbids a nullifier to repeat across the transactions of a valid chain (Ironwood Guide, §“Nullifier sets”), so no such transaction exists. By (a) and (b) the map from the transactions of the chain that carry a bundle under $\mathsf{ik}$ to the digests that the issuer signed is injective, which is the final claim. □