Issuance of Zcash Shielded Assets

• A hash output (32 bytes per Issue Action) incurs lower average bandwidth costs in issuance transactions than the asset description (previously up to 512 bytes).
• The asset description can be longer than 512 bytes without incurring chain costs.
• Including an asset description byte string directly in issuance transactions does not ensure that the "user-visible" asset description is consensus-visible, because the byte string could itself be a hash of another off-chain description (even if the consensus rules had required it to be a Unicode string instead of only recommending it).
• The lack of key rotation in this issuance protocol means that it is not sufficient to mark an $\mathsf{issuer}$ as trusted and then accept whatever asset descriptions are issued by it. Each Asset Identifier needs to be independently verified, which requires some out-of-band protocol that can also convey the corresponding asset description.
• If issuance transactions include the asset descriptions directly, wallets will discover them during scanning. This is an "attractive nuisance" because it would result in wallets being more likely to expose the asset description directly to users without any verification that the received asset has the value that a user might expect from that description. By instead using a collision-resistant hash of an asset description, wallets are forced to look up the corresponding asset description when a payment is received in an unknown asset. That lookup can be mediated by a trusted party or common trusted registry of known assets, or else will need to be approved directly by a user who can personally assert their interest in that specific asset.

Rationale for Global Issuance State

It is necessary to ensure that the balance of any issued Custom Asset never becomes negative within a shielded pool, along the lines of ZIP 209³⁷. However, unlike for the shielded ZEC pools, there is no individual transaction field that directly corresponds to both the issued and burnt amounts for a given Asset. Therefore, we require that all nodes maintain a record of the current amount in circulation for every issued Custom Asset, and update this record based on the issuance and burn transactions processed. This allows for efficient detection of balance violations for any Asset, in which case we specify a consensus rule to reject the transaction or block.

We limit the total issuance of any Asset to a maximum of $\mathsf{MAX\_ISSUE}$. This is a practical limit that also allows an issuer to issue the complete supply of an Asset in a single transaction.

Nodes also need to reject transactions that issue Custom Assets that have been previously finalized. The $\mathsf{issued\_assets}$ map allows nodes to store whether or not a given Asset has been finalized.

Concrete Applications

Asset Features

• By using the $\mathsf{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 $\mathsf{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 $\mathsf{AssetId}$, for which $\mathsf{finalize} = 1$, or by
  • issuing a transaction with a single note in the issuance action pertaining to that $\mathsf{AssetId}$, where the note will contain a $\mathsf{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).

• 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 $\mathsf{AssetId}$ corresponds to $\mathsf{value} = 1$ at the fundamental unit level. Issuers and users should make sure that $\mathsf{finalize} = 1$ for each of the actions in this scenario.

Modifications relative to ZIP 244³⁹

Relative to the sighash algorithm defined in ZIP 244, the sighash algorithm that applies to v6 transactions differs by including the issuance bundle components within the tree hash. See ZIP 246⁴⁰ for details.

Changes to ZIP 317⁴¹

The conventional fee in ZEC is altered to take into account both the presence of issuance actions within a transaction, and the creation of new Custom Assets within the global chain state. See the Fee calculation section of ZIP 317 ⁴² for details.

Rationale for paying fees in ZEC

Click to show/hide

We choose to maintain the native ZEC Asset as the primary token for the Zcash blockchain, similar to how ETH is needed for ERC20 transactions to the benefit of the Ethereum ecosystem.

An alternative proposal for the OrchardZSA fee mechanism that was not adopted was to adopt a new type of fee, denominated in the custom Asset being issued or transferred. In the context of transparent transactions, such a fee allows miners to “tap into” the ZSA value of the transactions, rather than the ZEC value of transactions. However when transactions are shielded, any design that lifts value from the transaction would also leak information about it.

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, Asset Digest, and Asset Base 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 issuer identifier is compromised, the $\mathsf{finalize}$ boolean for all the Assets issued with that key should be set to $1$; then the issuer should change to a new issuance authorizing key (hence a new issuer identifier), and issue new Assets, each with a new $\mathsf{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 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 $\mathsf{issuanceSupplyInfoMap}$ from $\mathsf{AssetId}$ to $(\mathsf{totalSupply}, \mathsf{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.

Test Vectors

• LINK TBD

Reference Implementation

• LINK TBD
• LINK TBD

Deployment

TBD

References

---

1. 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"↩︎

2. ZIP 200: Network Upgrade Mechanism↩︎

3. Zcash Protocol Specification, Version 2025.6.2 [NU6.1] or later.↩︎

4. ZIP 224: Orchard↩︎

5. ZIP 226: Transfer and Burn of Zcash Shielded Assets↩︎

6. ZIP 226: Transfer and Burn of Zcash Shielded Assets↩︎

7. ZIP 226: Transfer and Burn of Zcash Shielded Assets↩︎

8. ZIP 226: Transfer and Burn of Zcash Shielded Assets↩︎

9. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 4.1.7: Signature↩︎

10. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 2: Notation↩︎

11. ZIP 32: Shielded Hierarchical Deterministic Wallets — Specification: Hardened-only key derivation↩︎

12. ZIP 32: Shielded Hierarchical Deterministic Wallets — Hardened-only child key derivation↩︎

13. ZIP 32: Shielded Hierarchical Deterministic Wallets — Orchard key path↩︎

14. BIP 43: Purpose Field for Deterministic Wallets↩︎

15. ZIP 32: Shielded Hierarchical Deterministic Wallets — Key path levels↩︎

16. BIP 340: Schnorr Signatures for secp256k1↩︎

17. ZIP 32: Shielded Hierarchical Deterministic Wallets↩︎

18. BIP 340: Schnorr Signatures for secp256k1↩︎

19. BIP 340: Schnorr Signatures for secp256k1↩︎

20. An Introduction to Petname Systems. Marc Stiegler, updated June 2010.↩︎

21. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 5.4.9.8: Group Hash into Pallas and Vesta↩︎

22. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 5.3: Constants↩︎

23. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 3.2: Notes↩︎

24. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 3.2: Notes↩︎

25. ZIP 230: Version 6 Transaction Format — Issue Note Description (IssueNoteDescription)↩︎

26. ZIP 230: Version 6 Transaction Format — Issuance Action Description (IssueAction)↩︎

27. ZIP 230: Version 6 Transaction Format — Transaction Format↩︎

28. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 4.2.3: Orchard Key Components↩︎

29. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 5.4.2: Pseudo Random Functions↩︎

30. ZIP 230: Version 6 Transaction Format — Transaction Format↩︎

31. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 4.2.3: Orchard Key Components↩︎

32. Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 4.10: SIGHASH Transaction Hashing↩︎

33. ZIP 226: Transfer and Burn of Zcash Shielded Assets — TxId Digest↩︎

34. ZIP 226: Transfer and Burn of Zcash Shielded Assets — Additional Consensus Rules for the assetBurn set↩︎

35. ZIP 230: Version 6 Transaction Format — Issue Note Description (IssueNoteDescription)↩︎

36. ZIP 226: Transfer and Burn of Zcash Shielded Assets — Note Structure and Commitment↩︎

37. ZIP 209: Prohibit Out-of-Range Shielded Chain Value Pool Balances↩︎

38. ZIP 226: Transfer and Burn of Zcash Shielded Assets↩︎

39. ZIP 244: Transaction Identifier Non-Malleability↩︎

40. ZIP 246: Digests for the Version 6 Transaction Format↩︎

41. ZIP 317: Proportional Transfer Fee Mechanism↩︎

42. ZIP 317: Proportional Transfer Fee Mechanism — Fee calculation↩︎

43. ZIP 226: Transfer and Burn of Zcash Shielded Assets↩︎