ZIP: 227
Title: Issuance of Zcash Shielded Assets
Owners: Pablo Kogan <pablo@qed-it.com>
        Vivek Arte <vivek@qed-it.com>
        Daira-Emma Hopwood <daira@electriccoin.co>
        Jack Grigg <str4d@electriccoin.co>
Credits: Daniel Benarroch
         Aurelien Nicolas
         Deirdre Connolly
         Teor
Status: Draft
Category: Consensus
Created: 2022-05-01
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/618>
Pull-Request: <https://github.com/zcash/zips/pull/680>

Terminology

The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14¹ 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².

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

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 Zcash Shielded Assets (ZSA) protocol, in conjunction with ZIP 226⁴. 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⁵. This ZIP must only be implemented in conjunction with ZIP 226⁶. The proposed issuance mechanism is only valid for the Orchard-ZSA transfer protocol, because it produces notes that can only be transferred under ZSA.

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⁷.

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 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 Orchard-ZSA Protocol adds the following keys to the key components⁸ ⁹:

The issuance authorizing key, denoted as isk, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer.
The issuance validating key, denoted as 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:

Diagram of Issuance Key Components for the Orchard-ZSA Protocol

Issuance Authorization Signature Scheme

We instantiate the issuance authorization signature scheme IssueAuthSig as a BIP-340 Schnorr signature over the secp256k1 curve. The signing and validation algorithms, signature encoding, and public key encoding MUST follow BIP 340¹⁰.

Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results; for example, for a given verification key pk and lift_x(int(pk)) MAY be precomputed.

We define the constants as per the secp256k1 standard parameters, as described in BIP 340.

The associated types of the IssueAuthSig signature scheme are as follows:

IssueAuthSig.Message = 𝔹^{𝕐^[ℕ]}
IssueAuthSig.Signature = 𝔹^{𝕐^[64]} ∪ {⊥}
IssueAuthSig.Public = 𝔹^{𝕐^[32]} ∪ {⊥}
IssueAuthSig.Private = 𝔹^{𝕐^[32]}

where 𝔹^{𝕐^[k]} denotes the set of sequences of k bytes, and 𝔹^{𝕐^[ℕ]} denotes the type of byte sequences of arbitrary length, as defined in the Zcash protocol specification¹¹.

The issuance authorizing key generation algorithm and the issuance validating key derivation algorithm are defined in the Issuance Key Derivation section, while the corresponding signing and validation algorithms are defined in the Issuance Authorization Signing and Validation section.

Issuance Key Derivation

Issuance authorizing key generation for hierarchical deterministic wallets

The issuance authorizing key is generated using the Orchard master key derivation procedure defined in ZIP 32¹². We reuse the functions defined there in what follows in this section.

Let S be a seed byte sequence of a chosen length, which MUST be at least 32 and at most 252 bytes. We define the master extended issuance key m_Issuance := MasterKeyGen("ZIP32ZSAIssue_V1", S).

As in ZIP 32 for Orchard¹³, we only use hardened child key derivation for the issuance authorizing key. We reuse the CDKsk function for Orchard child key derivation from ZIP 32.

We use the notation of ZIP 32¹⁴ for shielded HD paths, and define the issuance authorizing key path as m_Issuance/purpose′/coin_type′/account′. We fix the path levels as follows:

purpose: a constant set to 227 (i.e. 0xe3). purpose′ is thus 227′ (or 0x800000e3) following the BIP 43 recommendation.
coin_type: Defined as in ZIP 32¹⁵.
account: fixed to index 0.

From the generated (sk, c), we set the issuance authorizing key to be isk := sk.

Derivation of issuance validating key

Define IssueAuthSig.DerivePublic : (isk : IssueAuthSig.Private) → IssueAuthSig.Public as:

ik := PubKey(isk)
Return ⊥ if the PubKey algorithm invocation fails, otherwise return ik.

where the PubKey algorithm is defined in BIP 340¹⁶. Note that the byte representation of ik is in big-endian order as defined in BIP 340.

It is possible for the PubKey algorithm to fail with very low probability, which means that IssueAuthSig.DerivePublic could return ⊥ with very low probability. If this happens, discard the keys and repeat with a different isk.

This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32¹⁷. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.

Issuance Authorization Signing and Validation

Define IssueAuthSig.Sign : (isk : IssueAuthSig.Private) × (M : IssueAuthSig.Message) → IssueAuthSig.Signature as:

Let the auxiliary data a = [0x00]³².
Let σ = Sign(isk, M).
Return ⊥ if the Sign algorithm fails in the previous step, otherwise return σ.

where the Sign algorithm is defined in BIP 340 and a denotes the auxiliary data used in BIP 340¹⁸. Note that IssueAuthSig.Sign could return ⊥ with very low probability.

Define IssueAuthSig.Validate : (ik : IssueAuthSig.Public) × (M : IssueAuthSig.Message) × (σ : IssueAuthSig.Signature) → 𝔹 as:

Return 0 if σ = ⊥.
Return 1 if Verify(ik, M, σ) succeeds, otherwise 0.

where the Verify algorithm is defined in BIP 340¹⁹.

Specification: Asset Identifier

For every new Asset, there must be a new and unique Asset Identifier, denoted AssetId. We define this to be a globally unique pair AssetId := (ik, asset_desc), where ik is the issuance key and asset_desc is a byte string.

A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, AssetDigest, which is simply is a 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

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.
ik be the issuance validating key of the issuer, a public key used to verify the signature on the issuance transaction's SIGHASH.

Define AssetDigest_AssetId := BLAKE2b-512("ZSA-Asset-Digest", EncodeAssetId(AssetId)), where

EncodeAssetId(AssetId) = EncodeAssetId((ik, asset_desc)) := 0x00||ik||asset_desc.
Note that the initial 0x00 byte is a version byte.

Define AssetBase_AssetId := ZSAValueBase(AssetDigest_AssetId)

In the case of the Orchard-ZSA protocol, we define ZSAValueBase(AssetDigest_AssetId) := GroupHash^ℙ("z.cash:OrchardZSA", AssetDigest_AssetId) where GroupHash^ℙ is defined as in²⁰.

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

Diagram relating the Asset Identifier, Asset Digest, and Asset Base in the ZSA Protocol

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

Wallets MUST NOT display just the 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: Global Issuance State

Issuance requires the following additions to the global state defined at block boundaries:

previously_finalized, a set of AssetId that have been finalized (i.e.: the finalize flag has been set to 1 in some issuance transaction preceding the block boundary).

Specification: Issuance Action, Issuance Bundle and Issuance Protocol

Issuance Action Description

An issuance action, IssueAction, is the instance of issuing a specific Custom Asset, and contains the following fields:

assetDescSize: the size of the Asset description, a number between 0 and 512, stored in two bytes.
asset_desc: the Asset description, a byte string of up to 512 bytes as defined in the Specification: Asset Identifier section.
vNotes: an array of Note containing the unencrypted output notes of the recipients of the Asset.
flagsIssuance: a byte that stores the finalize boolean that defines whether the issuance of that specific Custom Asset is finalized or not.

An asset's AssetDigest is added to the previously_finalized set after a block that contains any issuance transaction for that asset with finalize = 1. It then cannot be removed from this set. For Assets with AssetDigest ∈ previously_finalized, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with AssetDigest ∉ previously_finalized, new issuance actions can be issued in future transactions. These must use the same Asset description, asset_desc, and can either maintain finalize = 0 or change it to finalize = 1, denoting that this Custom Asset cannot be issued after the containing block.

Bytes	Name	Data Type	Description
`2`	`assetDescSize`	`byte`	The length of the `asset_desc` string in bytes.
`assetDescSize`	`asset_desc`	`byte[assetDescSize]`	A byte sequence of length `assetDescSize` bytes which SHOULD be a well-formed UTF-8 code unit sequence according to Unicode 15.0.0 or later.
`varies`	`nNotes`	`compactSize`	The number of notes in the issuance action.
`noteSize * nNotes`	`vNotes`	`Note[nNotes]`	A sequence of note descriptions within the issuance action, where `noteSize` is the size, in bytes, of a Note.
`1`	`flagsIssuance`	`byte`	An 8-bit value representing a set of flags. Ordered from LSB to MSB: finalize The remaining bits are set to 0.

We note that the output note commitment of the recipient's notes are not included in the actual transaction, but when added to the global state of the chain, they will be added to the note commitment tree as a shielded note. This prevents future usage of the note from being linked to the issuance transaction, as the nullifier key is not known to the validators and chain observers.

Issuance Bundle

An issuance bundle, IssueBundle, is the aggregate of all the issuance-related information. Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself. It contains the following fields:

ik: the issuance validating key, that allows the validators to verify that the AssetId is properly associated with the issuer.
vIssueActions: an array of issuance actions, of type IssueAction.
issueAuthSig: the signature of the transaction SIGHASH, signed by the issuance authorizing key, isk, that validates the issuance.

The issuance bundle is then added within the transaction format as a new bundle. That is, issuance requires the addition of the following information to the transaction format²¹.

Bytes	Name	Data Type	Description
`varies`	`nIssueActions`	`compactSize`	The number of issuance actions in the bundle.
`IssueActionSize * nIssueActions`	`vIssueActions`	`IssueAction[nIssueActions]`	A sequence of issuance action descriptions, where IssueActionSize is the size, in bytes, of an IssueAction description.
`32`	`ik`	`byte[32]`	The issuance validating key of the issuer, used to validate the signature.
`64`	`issueAuthSig`	`byte[64]`	The signature of the transaction SIGHASH, signed by the issuer, validated as in Issuance Authorization Signature Scheme.

Issuance Protocol

The issuer program performs the following operations:

For all actions IssueAction:

encode asset_desc as a UTF-8 byte string of size up to 512.
compute AssetDigest from the issuance validating key ik and asset_desc as decribed in the Specification: Asset Identifier section.
compute AssetBase from AssetDigest as decribed in the Specification: Asset Identifier section.
set the finalize boolean as desired (if more issuance actions are to be created for this AssetBase, set finalize = 0, otherwise set finalize = 1).
for each recipient i:
- generate a ZSA output note that includes the Asset Base. For an Orchard-ZSA note this is note_i = (d_i, pk_{d_i}, v_i, ρ_i, rseed_i, AssetBase, rcm_i).
encode the IssueAction into the vector vIssueActions of the bundle.

For the IssueBundle:

encode the vIssueActions vector.
encode the ik as 32 byte-string.
sign the SIGHASH transaction hash with the issuance authorizing key, isk, using the IssueAuthSig signature scheme. The signature is then added to the issuance bundle.

Note: that the commitment is not included in the IssuanceAction itself. As explained below, it is computed later by the validators and added to the note commitment tree.

Specification: Consensus Rule Changes

For the IssueBundle:

Validate the issuance authorization signature, issueAuthSig, on the SIGHASH transaction hash, SigHash, by invoking IssueAuthSig.Validate(ik, SigHash, issueAuthSig).

For each IssueAction in IssueBundle:

check that 0 < assetDescSize ≤ 512.
check that asset_desc is a string of length assetDescSize bytes.
retrieve AssetBase from the first note in the sequence and check that AssetBase is derived from the issuance validating key ik and asset_desc as described in the Specification: Asset Identifier section.
check that the AssetDigest does not exist in the previously_finalized set in the global state.
check that every note in the IssueAction contains the same AssetBase and is properly constructed as note = (g_d, pk_d, v, ρ, rseed, AssetBase).

If all of the above checks pass, do the following:

For each note, compute the note commitment as cm = NoteCommit_rcm^OrchardZSA(repr_ℙ(g_d), repr_ℙ(pk_d), v, ρ, ψ, AssetBase) as defined in the Note Structure and Commitment section of ZIP 226²² and
Add cm to the Merkle tree of note commitments.
If finalize = 1, add AssetDigest to the previously_finalized set immediately after the block in which this transaction occurs.
(Replay Protection) If 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 is in order to keep the issuance details and the Asset Identifiers consistent across multiple shielded pools.
The design decision is not to have a chosen name to describe the Custom Asset, but to delegate it to an off-chain mapping, as this would imply a land-grab “war”.
The 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 require a check whether the finalize flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the previously_finalized` set at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.
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.

Concrete Applications

Asset Features

By using the finalize boolean and the burning mechanism defined in²³, issuers can control the supply production of any Asset associated to their issuer keys. For example,
- by setting finalize = 1 from the first issuance action for that Asset Identifier, the issuer is in essence creating a one-time issuance transaction. This is useful when the max supply is capped from the beginning and the distribution is known in advance. All tokens are issued at once and distributed as needed.
Issuers can also stop the existing supply production of any Asset associated to their issuer keys. This could be done by
- issuing a last set of tokens of that specific AssetId, for which finalize = 1, or by
- issuing a transaction with a single note in the issuance action pertaining to that AssetId, where the note will contain a value = 0. This can be used for application-specific purposes (NFT collections) or for security purposes to revoke the Asset issuance (see Security and Privacy Considerations).
- Note in the above cases, that the setting of the finalize flag will take effect at the block boundary, that is, after all the transactions in the block.
The issuance and burn mechanisms can be used in conjunction to determine the supply of Assets on the Zcash ecosystem. This allows for the bridging of Assets defined on other chains.
Furthermore, NFT issuance is enabled by issuing in a single bundle several issuance actions, where each AssetId corresponds to value = 1 at the fundamental unit level. Issuers and users should make sure that finalize = 1 for each of the actions in this scenario.

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 Orchard-ZSA protocol can be found in ZIP 226²⁴. As in ZIP 244²⁵, 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.5: issuance_digest

A BLAKE2b-256 hash of the following values :

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

The personalization field of this hash is set to:

"ZTxIdSAIssueHash"

In case the transaction has no issuance components, ''issue_actions_digest'' is:

BLAKE2b-256("ZTxIdSAIssueHash", [])

T.5a: issue_actions_digest

A BLAKE2b-256 hash of Issue Action information for all Issuance Actions belonging to the transaction. For each Action, the following elements are included in the hash:

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

The personalization field of this hash is set to:

"ZTxIdIssuActHash"

T.5a.i: issue_notes_digest

A BLAKE2b-256 hash of Note information for all Notes belonging to the Issuance Action. For each Note, the following elements are included in the hash:

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)

The personalization field of this hash is set to:

"ZTxIdIAcNoteHash"

T.5a.i.1: recipient

This is the raw encoding of an Orchard shielded payment address as defined in the protocol specification²⁶.

T.5a.i.2: value

Note value encoded as little-endian 8-byte representation of 64-bit unsigned integer (e.g. u64 in Rust) raw value.

T.5a.i.3: assetBase

Asset Base encoded as the 32-byte representation of a point on the Pallas curve.

T.5a.i.4: rho

Nullifier encoded as 32-byte representation of a point on the Pallas curve.

T.5a.i.5: rseed

The ZIP 212 32-byte seed randomness for a note.

T.5a.ii: assetDescription

The Asset description byte string.

T.5a.iii: flagsIssuance

An 8-bit value representing a set of flags. Ordered from LSB to MSB:

finalize
The remaining bits are set to 0!.

T.5b: issuanceValidatingKey

A byte encoding of issuance validating key for the bundle as defined in the Issuance Key Derivation section.

Signature Digest

The per-input transaction digest algorithm to generate the signature digest in ZIP 244²⁷ 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 Orchard-ZSA protocol via the [ADDED FOR ZSA] text label, and we omit the descriptions of the sections that do not change for the Orchard-ZSA protocol:

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

signature_digest

A BLAKE2b-256 hash of the following values :

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]

The personalization field remains the same as in ZIP 244²⁸.

S.5: issuance_digest

Identical to that specified for the transaction identifier.

Authorizing Data Commitment

The transaction digest algorithm defined in ZIP 244²⁹ which commits to the authorizing data of a transaction is modified by the Orchard-ZSA protocol to have the following structure. We highlight the changes for the Orchard-ZSA protocol via the [ADDED FOR ZSA] text label, and we omit the descriptions of the sections that do not change for the Orchard-ZSA protocol:

auth_digest
├── transparent_scripts_digest
├── sapling_auth_digest
├── orchard_auth_digest
└── issuance_auth_digest        [ADDED FOR ZSA]

The pair (Transaction Identifier, Auth Commitment) constitutes a commitment to all the data of a serialized transaction that may be included in a block.

auth_digest

A BLAKE2b-256 hash of the following values :

A.1: transparent_scripts_digest (32-byte hash output)
A.2: sapling_auth_digest        (32-byte hash output)
A.3: orchard_auth_digest        (32-byte hash output)
A.4: issuance_auth_digest       (32-byte hash output)  [ADDED FOR ZSA]

The personalization field of this hash remains the same as in ZIP 244.

A.4: issuance_auth_digest

In the case that Issuance Actions are present, this is a BLAKE2b-256 hash of the field encoding of the issueAuthSig field of the transaction:

A.4a: issueAuthSig            (field encoding bytes)

The personalization field of this hash is set to:

"ZTxAuthZSAOrHash"

In the case that the transaction has no Orchard Actions, issuance_auth_digest is :

BLAKE2b-256("ZTxAuthZSAOrHash", [])

Security and Privacy Considerations

Displaying Asset Identifier information to users

Wallets need to communicate the names of the Assets in a non-confusing way to users, since the byte representation of the Asset Identifier would be hard to read for an end user. Possible solutions are provided in the Specification: Asset Identifier section.

Issuance Key Compromise

The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended:

If an issuance validating key is compromised, the finalize boolean for all the Assets issued with that key should be set to 1 and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new AssetId.

Bridging Assets

For bridging purposes, the secure method of off-boarding Assets is to burn an Asset with the burning mechanism in ZIP 226³⁰. Users should be aware of issuers that demand the Assets be sent to a specific address on the Zcash chain to be redeemed elsewhere, as this may not reflect the real reserve value of the specific Wrapped Asset.

Other Considerations

Implementing Zcash Nodes

Although not enforced in the global state, it is RECOMMENDED that Zcash full validators keep track of the total supply of Assets as a mutable mapping issuanceSupplyInfoMap from AssetId to (totalSupply, finalize) in order to properly keep track of the total supply for different Asset Identifiers. This is useful for wallets and other applications that need to keep track of the total supply of Assets.

Fee Structures

The fee mechanism described in this ZIP will follow the mechanism described in ZIP 317³¹.

Test Vectors

LINK TBD

Reference Implementation

LINK TBD
LINK TBD

Deployment

This ZIP is proposed to activate with Network Upgrade 6.

References

Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"↩
ZIP 200: Network Upgrade Mechanism ↩
ZIP 224: Orchard ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩
Zcash Protocol Specification, Version 2023.4.0. Section 3.1: Payment Addresses and Keys ↩
Zcash Protocol Specification, Version 2023.4.0. Section 4.2.3: Orchard Key Components ↩
BIP 340: Schnorr Signatures for secp256k1 ↩
Zcash Protocol Specification, Version 2023.4.0. Section 2: Notation ↩
ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard master key generation ↩
ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard child key derivation ↩
ZIP 32: Shielded Hierarchical Deterministic Wallets - Orchard key path ↩
ZIP 32: Shielded Hierarchical Deterministic Wallets - Key path levels ↩
BIP 340: Schnorr Signatures for secp256k1 ↩
ZIP 32: Shielded Hierarchical Deterministic Wallets ↩
BIP 340: Schnorr Signatures for secp256k1 ↩
BIP 340: Schnorr Signatures for secp256k1 ↩
Zcash Protocol Specification, Version 2023.4.0. Section 5.4.9.8: Group Hash into Pallas and Vesta ↩
Zcash Protocol Specification, Version 2023.4.0. Section 7.1: Transaction Encoding and Consensus (Transaction Version 5)↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets - Note Structure & Commitment ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets - TxId Digest ↩
ZIP 244: Transaction Identifier Non-Malleability ↩
Zcash Protocol Specification, Version 2023.4.0. Section 5.6.4.2: Orchard Raw Payment Addresses ↩
ZIP 244: Transaction Identifier Non-Malleability: Signature Digest ↩
ZIP 244: Transaction Identifier Non-Malleability ↩
ZIP 244: Transaction Identifier Non-Malleability: Authorizing Data Commitment ↩
ZIP 226: Transfer and Burn of Zcash Shielded Assets ↩
ZIP 317: Proportional Transfer Fee Mechanism ↩

Files

zip-0227.rst

Latest commit

History

zip-0227.rst

File metadata and controls

Terminology

Abstract

Motivation

Use Cases

Requirements

Specification: Issuance Keys and Issuance Authorization Signature Scheme

Issuance Authorization Signature Scheme

Issuance Key Derivation

Issuance authorizing key generation for hierarchical deterministic wallets

Derivation of issuance validating key

Issuance Authorization Signing and Validation

Specification: Asset Identifier

Specification: Global Issuance State

Specification: Issuance Action, Issuance Bundle and Issuance Protocol

Issuance Action Description

Issuance Bundle

Issuance Protocol

Specification: Consensus Rule Changes

Rationale

Concrete Applications

TxId Digest - Issuance

T.5: issuance_digest

T.5a: issue_actions_digest

T.5a.i: issue_notes_digest

T.5a.i.1: recipient

T.5a.i.2: value

T.5a.i.3: assetBase

T.5a.i.4: rho

T.5a.i.5: rseed

T.5a.ii: assetDescription

T.5a.iii: flagsIssuance

T.5b: issuanceValidatingKey

Signature Digest

signature_digest

S.5: issuance_digest

Authorizing Data Commitment

auth_digest

A.4: issuance_auth_digest

Security and Privacy Considerations

Displaying Asset Identifier information to users

Issuance Key Compromise

Bridging Assets

Other Considerations

Implementing Zcash Nodes

Fee Structures

Test Vectors

Reference Implementation

Deployment

References