Terminology

The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14 1 when, and only when, they appear in all capitals.

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

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

We define the following additional terms:

• Asset: A type of note that can be transferred on the Zcash blockchain. Each Asset is identified by an Asset Identifier Specification: Asset Identifier.
  • ZEC is the default (and currently the only defined) Asset for the Zcash mainnet.
  • TAZ is the default (and currently the only defined) Asset for the Zcash testnet.
  • We use the term "Custom Asset" to refer to any Asset other than ZEC and TAZ.
• Native Asset: a Custom Asset with issuance defined on the Zcash blockchain.
• Wrapped Asset: a Custom Asset with native issuance defined outside the Zcash blockchain.
• Issuance Action: an instance of a single issuance of a Zcash Shielded Asset. It defines the issuance of a single Asset Identifier.
• Issuance Bundle: the bundle in the transaction that contains all the issuance actions of that transaction.

Abstract

This ZIP (ZIP 227) proposes the Orchard Zcash Shielded Assets (OrchardZSA) protocol, in conjunction with ZIP 226 10. This protocol is an extension of the Orchard protocol that enables the creation, transfer and burn of Custom Assets on the Zcash chain. The creation of such Assets is defined in this ZIP (ZIP 227), while the transfer and burn of such Assets is defined in ZIP 226 10. This ZIP must only be implemented in conjunction with ZIP 226 10. The proposed issuance mechanism is only valid for the OrchardZSA transfer protocol, because it produces notes that can only be transferred via this protocol.

Motivation

This ZIP introduces the issuance mechanism for Custom Assets on the Zcash chain. While originally part of a single ZSA ZIP, the issuance mechanism turned out to be substantial enough to stand on its own and justify the creation of this supporting ZIP for ZIP 226 10.

This ZIP only enables transparent issuance. As a first step, transparency will allow for proper testing of the applications that will be most used in the Zcash ecosystem, and will enable the supply of Assets to be tracked.

The issuance mechanism described in this ZIP is broad enough for issuers to either create Assets on Zcash (i.e. Assets that originate on the Zcash blockchain), as well as for institutions to create bridges from other chains and import Wrapped Assets. This enables what we hope will be a useful set of applications.

Use Cases

The design presented in this ZIP enables issuance of shielded Assets in various modes:

• The issuer may or may not know the receivers of the issued Asset in advance.
• The Asset can be of non-fungible type, where each Asset type can be made part of a single “series”.
• The supply of the Asset can be limited in advance or not.
• The Asset can be a wrapped version of an Asset issued by another chain (as long as there is a bridge that supports transfer of that Asset between chains).

See the Concrete Applications section for more details.

Requirements

• Any user of the Zcash blockchain can issue Custom Assets on chain.
• The issuance mechanism should enable public tracking of the supply of the Assets on the Zcash blockchain.
• Issuing or changing the attributes of a specific Asset should require cryptographic authorization.
• The Asset identification should be unique (among all shielded pools) and different issuer public keys should not be able to generate the same Asset Identifier.
• An issuer should be able to issue different Assets in the same transaction. In other words, in a single "issuance bundle", the issuer should be able publish many "issuance actions", potentially creating multiple Custom Assets.
• Every "issuance action" should contain a \(\mathsf{finalize}\) boolean that defines whether the specific Custom Asset can have further tokens issued or not.

Specification: Issuance Keys and Issuance Authorization Signature Scheme

The OrchardZSA Protocol adds the following keys to the key components 24 25:

1. The issuance authorizing key, denoted as \(\mathsf{isk}\!\) , is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer.
2. The issuance validating key, denoted as \(\mathsf{ik}\!\) , is the key that is used to validate issuance transactions. This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer.

The relations between these keys are shown in the following diagram:

Specification: Asset Identifier

For every new Asset, there MUST be a new and unique Asset Identifier, denoted \(\mathsf{AssetId}\!\) . We define this to be a globally unique pair \(\mathsf{AssetId} := (\mathsf{ik}, \mathsf{asset\_desc})\!\) , where \(\mathsf{ik}\) is the issuance key and \(\mathsf{asset\_desc}\) is a byte string.

A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the OrchardZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, \(\mathsf{AssetDigest}\!\) , which is simply is a \(\textsf{BLAKE2b-512}\) hash of the Asset Identifier. From the Asset Digest, we derive a specific Asset Base within each shielded protocol using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.

Let

• \(\mathsf{asset\_desc}\) be the asset description, which includes any information pertaining to the issuance, and is a byte sequence of up to 512 bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.
• \(\mathsf{ik}\) be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

Define \(\mathsf{AssetDigest_{AssetId}} := \textsf{BLAKE2b-512}(\texttt{“ZSA-Asset-Digest”},\; \mathsf{EncodeAssetId}(\mathsf{AssetId}))\!\) , where

• \(\mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}((\mathsf{ik}, \mathsf{asset\_desc})) := \mathtt{0x00} || \mathsf{ik} || \mathsf{asset\_desc}\!\!\) .
• Note that the initial \(\mathtt{0x00}\) byte is a version byte.

Define \(\mathsf{AssetBase_{AssetId}} := \mathsf{ZSAValueBase}(\mathsf{AssetDigest_{AssetId}})\)

In the case of the OrchardZSA protocol, we define \(\mathsf{ZSAValueBase}(\mathsf{AssetDigest_{AssetId}}) := \mathsf{GroupHash}^\mathbb{P}(\texttt{"z.cash:OrchardZSA"}, \mathsf{AssetDigest_{AssetId}})\) where \(\mathsf{GroupHash}^\mathbb{P}\) is defined as in 27.

The relations between the Asset Identifier, Asset Digest, and Asset Base are shown in the following diagram:

Note: To keep notations light and concise, we may omit \(\mathsf{AssetId}\) (resp. \(\mathsf{Protocol}\!\) ) in the subscript (resp. superscript) when the Asset Identifier (resp. Protocol) is clear from the context.

Wallets MUST NOT display just the \(\mathsf{asset\_desc}\) string to their users as the name of the Asset. Some possible alternatives include:

• Wallets could allow clients to provide an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers via a petname system. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
• The Asset Digest could be used as a more compact bytestring to uniquely determine an Asset, and wallets could support clients scanning QR codes to load Asset information into their wallets.

Specification: Issuance Action, Issuance Bundle and Issuance Protocol

Specification: Global Issuance State

Issuance requires the following additions to the global state:

A map, \(\mathsf{issued\_assets} : \mathbb{P}^* \to \{0 .. \mathsf{MAX\_ISSUE}\} \times \mathbb{B}\!\) , from the Asset Base, \(\mathsf{AssetBase} : \mathbb{P}^*\!\) , to a tuple \((\mathsf{balance}, \mathsf{final})\!\) , for every Asset that has been issued. We use the notation \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{balance}\) and \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{final}\) to access, respectively, the elements of the tuple stored in the global state for a given \(\mathsf{AssetBase}\!\) . If \(\mathsf{issued\_assets}(\mathsf{AssetBase}) = \bot\!\) , it is assumed that \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{balance} = 0\) and \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{final} = 0\!\) .

For any Asset represented by \(\mathsf{AssetBase}\!\) :

• \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{balance} \in \{0 .. \mathsf{MAX\_ISSUE}\}\) stores the amount of the Asset in circulation, computed as the amount of the Asset that has been issued less the amount of the Asset that has been burnt.
• \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{final} : \mathbb{B}\) is a Boolean that stores the finalization status of the Asset (i.e.: whether the \(\mathsf{finalize}\) flag has been set to \(1\) in any preceding issuance transaction for the Asset). The value of \(\mathsf{issued\_assets}(\mathsf{AssetBase}).\!\mathsf{final}\) for any \(\mathsf{AssetBase}\) cannot be changed from \(1\) to \(0\!\) .

The maximum total supply of any issued Custom Asset is denoted by the constant \(\mathsf{MAX\_ISSUE} := 2^{64} - 1\!\) .

Specification: Consensus Rule Changes

For every transaction:

• The output issuance state of the transaction MUST be initialized to be the same as the input issuance state, \(\mathsf{issued\_assets}_{\mathsf{OUT}} = \mathsf{issued\_assets}_{\mathsf{IN}}\!\) .
• The \(\mathsf{assetBurn}\) set MUST satisfy the consensus rules specified in ZIP 226 12.
• It MUST be the case that for all \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}\!\) , \(\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\!\mathsf{balance} \geq \mathsf{v}\!\) . The node then MUST update \(\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase})\) prior to processing the issuance bundle in the following manner. For every \((\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{AssetBurn}\!\) , \(\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\!\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\!\mathsf{balance} - \mathsf{v}\!\) .
• Let \(\mathsf{SigHash}\) be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification 26 with the modifications described in ZIP 226 13, using \(\mathsf{SIGHASH\_ALL}\!\) .
• The issuance authorization signature, \(\mathsf{issueAuthSig}\!\) , MUST be a valid \(\mathsf{IssueAuthSig}\) signature over \(\mathsf{SigHash}\!\) , i.e. \(\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{ik}, \mathsf{SigHash}, \mathsf{issueAuthSig}) = 1\!\) .
• For every issuance action description ( \(\mathsf{IssueAction}_\mathsf{i},\ 1 \leq i \leq \mathtt{nIssueActions}\!\) ) in the issuance bundle:
  • It MUST be the case that \(0 < \mathtt{assetDescSize} \leq 512\!\) .
  • It MUST be the case that \(\mathsf{asset\_desc}\) is a string of length \(\mathtt{assetDescSize}\) bytes.
  • Elements of every issue note description in IssueAction MUST be valid encodings of the types given in Issue Note Description, and MUST encode the same \(\mathsf{AssetBase}\!\) .
  • This \(\mathsf{AssetBase}\) MUST satisfy the derivation from the issuance validating key and asset description described in the Specification: Asset Identifier section.
  • It MUST be the case that \(\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\!\mathsf{final} \neq 1\!\) .
  • For every issue note description ( \(\mathsf{note}_{\mathsf{j}},\ 1 \leq j \leq \mathtt{nNotes}\!\) ) in IssueAction:
    • It MUST be the case that \(\mathsf{issued\_assets}_{\mathsf{OUT}}.\!\mathsf{balance} + \mathsf{v} \leq \mathsf{MAX\_ISSUE}\!\) , where \(\mathsf{v}\) is the value of \(\mathsf{note}_{\mathsf{j}}\!\) . The node then MUST update \(\mathsf{issued\_assets}_{\mathsf{OUT}}.\!\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}.\!\mathsf{balance} + \mathsf{v}\!\) .
    • The node MUST compute the note commitment, \(\mathsf{cm}_{\mathsf{i,j}}\!\) , as defined in the Note Structure and Commitment section of ZIP 226 11.
  • If \(\mathsf{finalize} = 1\) within the flagsIssuance field of IssueAction, the node MUST set \(\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\!\mathsf{final} = 1\!\) .
• If all the consensus rules are satisfied, the node MUST add the note commitments, \(\mathsf{cm}_{\mathsf{i,j}}\ \forall\ \mathsf{i} \in \{1..\mathtt{nIssueActions}\},\ \mathsf{j} \in \{1..\mathtt{nNotes}\}\!\) , to the Merkle tree of note commitments.
• (Replay Protection) If an issue bundle is present, the fees MUST be greater than zero.

Rationale

The following is a list of rationale for different decisions made in the proposal:

• The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This keeps the issuance details and the Asset Identifiers consistent across multiple shielded pools. It also separates the issuance authority from the spend authority, allowing for the potential transfer of issuance authority without compromising the spend authority.
• The Custom Asset is described via a combination of the issuance validating key and an asset description string, to preclude the possibility of two different issuers creating colliding Custom Assets.
• The \(\mathsf{asset\_desc}\) is a general byte string in order to allow for a wide range of information type to be included that may be associated with the Assets. Some are:
  • links for storage such as for NFTs.
  • metadata for Assets, encoded in any format.
  • bridging information for Wrapped Assets (chain of origin, issuer name, etc)
  • information to be committed by the issuer, though not enforceable by the protocol.
• We limit the size of the \(\mathsf{asset\_desc}\) string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.
• We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.

TxId Digest - Issuance

This section details the construction of the subtree of hashes in the transaction digest that corresponds to issuance transaction data. Details of the overall changes to the transaction digest due to the OrchardZSA protocol can be found in ZIP 226 13. As in ZIP 244 18, the digests are all personalized BLAKE2b-256 hashes, and in cases where no elements are available for hashing, a personalized hash of the empty byte array is used.

A new issuance transaction digest algorithm is defined that constructs the subtree of the transaction digest tree of hashes for the issuance portion of a transaction. Each branch of the subtree will correspond to a specific subset of issuance transaction data. The overall structure of the hash is as follows; each name referenced here will be described in detail below:

issuance_digest
├── issue_actions_digest
│   ├── issue_notes_digest
│   ├── assetDescription
│   └── flagsIssuance
└── issuanceValidatingKey

In the specification below, nodes of the tree are presented in depth-first order.

T.5a: issue_actions_digest    (32-byte hash output)
T.5b: issuanceValidatingKey   (32 bytes)

"ZTxIdSAIssueHash"

BLAKE2b-256("ZTxIdSAIssueHash", [])

T.5a.i  : notes_digest            (32-byte hash output)
T.5a.ii : assetDescription        (field encoding bytes)
T.5a.iii: flagsIssuance           (1 byte)

"ZTxIdIssuActHash"

T.5a.i.1: recipient                    (field encoding bytes)
T.5a.i.2: value                        (field encoding bytes)
T.5a.i.3: assetBase                    (field encoding bytes)
T.5a.i.4: rho                          (field encoding bytes)
T.5a.i.5: rseed                        (field encoding bytes)

"ZTxIdIAcNoteHash"

BLAKE2b-256("ZTxIdIAcNoteHash", [])

Signature Digest

The per-input transaction digest algorithm to generate the signature digest in ZIP 244 19 is modified so that a signature digest is produced for each transparent input, each Sapling input, each Orchard action, and additionally for each Issuance Action. For Issuance Actions, this algorithm has the exact same output as the transaction digest algorithm, thus the txid may be signed directly.

The overall structure of the hash is as follows. We highlight the changes for the OrchardZSA protocol via the [ADDED FOR ZSA] text label, and we omit the descriptions of the sections that do not change for the OrchardZSA protocol:

signature_digest
├── header_digest
├── transparent_sig_digest
├── sapling_digest
├── orchard_digest
└── issuance_digest         [ADDED FOR ZSA]

S.1: header_digest          (32-byte hash output)
S.2: transparent_sig_digest (32-byte hash output)
S.3: sapling_digest         (32-byte hash output)
S.4: orchard_digest         (32-byte hash output)
S.5: issuance_digest        (32-byte hash output)  [ADDED FOR ZSA]

Authorizing Data Commitment - Issuance

This section covers the construction of the subtree of hashes in the authorizing data commitment that corresponds to issuance transaction data. Details of the overall changes to the authorizing data commitment due to the OrchardZSA protocol can be found in ZIP 226 14.

A.4a: issueAuthSig            (field encoding bytes)

"ZTxAuthZSAOrHash"

BLAKE2b-256("ZTxAuthZSAOrHash", [])

OrchardZSA Fee Calculation

In addition to the parameters defined in the Fee calculation section of ZIP 317 20, the OrchardZSA protocol upgrade defines the following additional parameters:

Wallets implementing this specification SHOULD use a conventional fee, viz. \(zsa\_conventional\_fee\!\) , that is calculated in zatoshis. Additional definitions that are used in the formula for the calculation are in the table below:

The other inputs to this formula are taken from transaction fields defined in the Zcash protocol specification 29 and the global state. They are defined in the Fee calculation section of ZIP 317 20. Note that \(nOrchardActions\!\) , that is used in the computation of \(logical\_actions\!\) , is redefined in the above table, and now combines the actions for native ZEC as well as OrchardZSA transfer actions for Custom Assets.

The formula for the computation of the \(zsa\_logical\_actions\) (with the updated computation of \(logical\_actions\) as described above) is:

The formula for the computation of the \(zsa\_conventional\_fee\) is:

It is not a consensus requirement that fees follow this formula; however, wallets SHOULD create transactions that pay this fee, in order to reduce information leakage, unless overridden by the user.

Security and Privacy Considerations

Other Considerations

Test Vectors

• LINK TBD

Reference Implementation

• LINK TBD
• LINK TBD

Deployment

TBD

References