# Zcash Shielded Assets - Issuance

The design concerns about ZSAs can be roughly split into three areas:

- How to issue (and redeem / burn) assets.
- How to transact with them.
- How to handle fees.

This document covers the first area: what is necessary for defining, issuing, and removing from issuance (redeeming or burning) non-ZEC assets.

The goal of this document is to document:

- the requirements that various use cases place on issuance functionality; and
- the functionality that various issuance designs provide,

to enable us to find the intersection of these two groups.

## Definitions

- "Asset ID": the globally-unique identifier for a specific asset within the Zcash block chain.
- "Native asset": an asset natively defined within the Zcash block chain.
- "Guest asset": an asset defined off-chain, that can be locked up there and represented equivalently within the Zcash block chain.
- "Issuance": addition of some amount of a specific asset to general circulation within the Zcash block chain.
- "Redemption": removal of some amount of a specific asset from general circulation within the Zcash block chain.
- "Governing body": the entity or entities that control a specific asset, and are permissioned to perform issuance, redemption, or other similar actions.
- "Rotation": altering the effective membership of the governing body for a specific asset. This might not alter the actual membership (e.g. a member rotating their key).

## Potential use cases

### Generating custom native currency assets.

TODO: Expand this.

Possible requirements:
- Asset issuance and redemption is public.

### Generating custom native non-currency tokens.

TODO: Expand this (and how it differs in use-case from "custom native currency asset").

Possible requirements:
- Asset issuance and redemption is public.

### Enabling existing off-chain assets to be wrapped as guest assets.

> This section needs expanding. In particular, we need feedback from existing bridgemakers to elucidate what they actually require.
> [name=str4d]

TODO: Expand on the ways in which people do cross-chain asset movement.

Requirements:
- Asset issuance and redemption is public.
- This is necessary to ensure that the amount of the guest asset within the Zcash block chain matches the amount of the guest asset locked up off-chain.

Possible requirements:

- Asset issuance and redemption is public.
- Support for some kind of multisig.
- [UNCONFIRMED] Support for FROST-like multisig.
- [UNCONFIRMED] Support for Bitcoin-style multisig.
- [UNCONFIRMED] Support for existing BTC/ETH sigs/curves/ideally keys.

### tBTC

> A dynamic set of keys with the power to issue a single asset ID would be ideal for our designs.
> [name=Matt Luongo]

Requirements:

- A signature scheme that's verifiable on Ethereum. So secp256k1 curve, but ECDSA or BLS works.
- I don't know of any Schnorr implementation that's efficient on the EVM [name=Matt Luongo]
- Multiple governing bodies for a specific asset ID.
- A way to verify redemptions. In particular, need to know:
- X amount of asset ID was burned to redeem,
- committing to Y Ethereum account.

## Possible issuance designs

We assume for the moment that all designs are implemented as a TZE. This would potentially enable some degree of custom issuance logic; we'd split the logic into "common to all ZSAs" (part of the TZE logic) and "per-ZSA" (provided in the TZE witness for each issuance or redemption transaction).

TODO: Rework how this is outlined; TZEs are conceptually just the implementation mechanism, but they do place some constraints on how issuance transactions actually work (mostly due to the UTXO model).

### Single-key == asset

An asset ID is derived from a single public key that controls the asset. Issuance and redemption transactions are authorized by a signature from this public key.

Full nodes would need to maintain:
- A list of currently-issued assets, and the amount of each that has been issued. Assets that have never been issued or never been redeemed could be elided.

Notes:

- This is the absolute simplest approach to design, specify, and implement.
- It is compatible with threshold multisignature schemes like FROST (where the multisignature public key is indistinguishable from a single key).
- It is _not_ compatible with Bitcoin-style multi-key multisignatures (where all keys involved in a signature are revealed).
- It does not support key rotation. Changing the public key changes the asset ID.

### Single-key registered to asset

When an asset ID is first "registered" (e.g. on first use), it can specify a single public key that controls the asset.

Full nodes would need to maintain an indefinitely-growing list of registered assets,

- It is compatible with threshold multisignature schemes like FROST.
- It could be extended to support key rotation, by having a "rotation" action that is authorized by the previous key.

### Multi-key == asset

Equivalent to "single-key == asset", but instead the asset ID is derived from a concatenated list of public keys.

- It could be extended to a threshold scheme by also including the required threshold in the asset ID derivation.

### Multi-key registered to asset

Equivalent to "single-key registered to asset", but instead registering a list of public keys.

- It could be extended to a threshold scheme by also including the required threshold in the asset ID derivation.
- The threshold could potentially be updateable.

Key rotation could be defined with a potentially-different authorization mechanism for individual keys:

- Issuance or redemption requires signatures from all keys on the list (or a subset of them if a threshold is specified).
- but rotating an individual key

### scriptpubkey registered to an asset:
We use a TZE to store {assetID: scriptpubkey} supporting two operations three operations:
1) register: creates a new assetID,scriptpubKey pair (either a random asset ID, or the hash of the scruptpubKey)
2) mint: issues x units of an asset with assID IFF the script pubkey is satisfied
3) update: for assetID ID, change the scriptpubkey from X to Y IFF x is satisfied.

### "Smart contract" registered to asset

We likely won't do this, but including it here as a design alternative.

TODO: Describe.