# zk-assets: privacy preserving stable coins and wrapped BTC and ETH for Zcash
Authors: Ian Miers (@secparam)

ZK assets (sometimes called user defined assets or ZSAs) allow anyone to make their own private currency on Zcash. These can range from stable coins like Gemini-USD, to wrapped assets issued by things like Ren and TBTC, to algorithmic stable coins like Dai. Transactions of zk-assets are fully private, indistinguishable from both other zk-asset transactions and shielded ZEC transactions. This document lays out the design of zk-assets for Zcash and open problems.

On a technical level, zk-assets require:
1. A small extension to Zcash's zk proofs: instead of a transaction specifying only the owner and the amount of money, there is also a currency type. The zk-proofs ensure money can't change types.
2. An issuance mechanism so users, financial institutions, and smart contracts on other blockchains can issue and manage new currencies.
3. Optionally, a mechanism for charging fees for issuance of zk-assets.

We note, that the use of zk-assets is not limited to currencies. The exact same change also supports privately transferable non-fungible tokens that can be used for access control, counterfeiting prevention, and for art. We leave full support of NFTs to future versions of zk-assets, but hope this document will support the trival case: issue a zk-asset with only one instance.

# Zk assets Version 0.
This describes the core technical prototype for development and beta testing.

## Circuit Changes to Orchard
The circuit changes are analogous to the ones proposed for sapling by Jack Griggs in his [draft ZIP](https://github.com/zcash/zips/pull/269/files). What remains is to port the changes to the plonk constraint system used by the Halo2 proof system in Orchard and implement a very clever (but thankfully simple) optimization by Daira Hopwood that removes the need for an expensive hash operation

See https://github.com/zcash/zcash/issues/830

### Fees for transactions.
The fees paid for moving a zk-asset (as opposed to issuing it), are paid in zec by the same mechanism as shielded zec transactions. The fees must be the same to preserve privacy.

At a reduction in privacy, all zk-asset transactions could have a higher minimum fee that must be output. This does not seem worth the privacy lost.

## Issuance mechanism
See [this](https://hackmd.io/88PN_LuiQPi4QSjwxTBTTg) for more in depth discussion
Assets are issued, either once, or repeatedly, by posting a signed message to the Zcash chain.

We associate the public key with the asset (e.g. the asset ID is the public key). Creating x amount of the asset requires posting to the blockchain a public message signed by that address requesting x amount be printed. This immediately allows stable coins like Gemini-USD where a trusted party already exists to hold backing assets and already holds signing keys to issue assets on other platforms. It also supports cross chain issuance via mechanism like Ren, tBTC, etc which can hold keys.

Asset issuance is intentionally public. A stable coin where you do not know how many coins are issued is problematic.

### Supporting issuance keys from multiple chains.
Issuance should be supported for multiple types of public keys including from Bitcoin, Ethereum, and the zcash shielded pool. This is crucial to integrate with existing custody mechanisms and on chain schemes. It is also CRUCIAL that we support multisig.

### one time asset issuance (Work in Progress)
To allow assets that can be issued only once, we can allow the asset_id to be set to, instead of the public key, the key combined with the last Merkle tree root. This ensures, without adding complicated state keeping, that attempts to issue fixed supply assets multiple times don't produce the same asset.

### Key rotation (WIP/ TBD)
Ideally, we should allow zk-asset issuing keys to be rotated. This is likely a hard requirment for major stable coins.

Issuance key rotation should be realizable in the TZE model without adding global statekeeping. TZEs are, in essence, extensible version of script pubkey and script sig from Bitcoin. A TZE_output can be used to define the mapping from random asset_id to issuing key. Issuance is handled by a transaction spending that TZE_output with a corresponding satisfying TZE_input which specifies the amount to mint and a signature. The TZE output of this second transaction is allowed to reuse the asset_id and map it to a new public_key.

### TBD wire format for issuance/destruction via TZE
Issuance would be via a [TZE](https://zips.z.cash/zip-0222). Exact wire format needs to be worked out by protocol engineers.

We may also need a simple TZE to allow destorying a zk-asset. In the case of a stable coin or wrapped token, this would allow withdraw of the backing coin.

# ZK-assets Version 1
Version 1 extends the core technical protocol to address economic considerations. We consider it separately from version 0, as version 0 is the MVP: It transfers zk-assets privately and pays fees as in existing Zcash transactions.

Version one considers possible economic enhancements.

### Economic non-goals.
Two persistant economic complaints for zk-asssets are:

1. The existence of zk-assets will devalue Zcash because a holder of zec may prefer private wrapped bitcoin or a private stable coin and so abandon ZEC. See, e.g., [here](https://forum.zcashcommunity.com/t/basics-of-blockchain-economics-and-how-it-should-guide-protocol-changes/37915/21).
2. Zk-assets are unfair to zec holders as they don't benefit.

Zk-assets like a wrapped version of Bitcoin (zbtc) are probably not a direct competitor for zcash, nor are stable coins. The (semi) trusted issuance mechanisms make them risky: the asset backing wrapped Bitcoin or shielded Gemini USD may vainish in a way zec itself cannot. The core case for Zec is "sound money" that needs to be private, just like Bitcoin has a value story even given wrapped BTC and stablecoin. Zk-assets and zec are probably complimentary and certainly benefit from a shared anonymity set.

Moreover, we note that credible plans for zk-assets on other chains(e.g. [Tezos](https://masp.dev/), [cosmos](https://penumbra.zone/),and [Ethereum](https://aztec.network/)) make the concern moot. If the existence of zk-assets will undermine zcash, then this will happen when they exist on other chains. We are better off if zk-assets are on Zcash's chain,pay transaction fees in zec, and contribute to anonymity.

As to fairness: Zk-asset traffic could increase the anonymity set considerably and zk-assets pay zec fees same as any other use of the blockchain. And zcash benefits from increased usage, visibility, and exchange support for shielded transactions that could come from zk-asset support.

### Economic goals
The economic concern that remains for zk-assets is one that has existed for Ethereum since its inception and applies to any chain that carries assets such as Cosmos, Avalanche, or Tezos: that a blockchain where the value of a block in other assets greatly exceeds the value of the native asset and block reward, is in a risky position. This is sometimes refered to as "topheavyness"

The concern is valid, albeit distant. Blockchain economics are in their infancy and we don't have good models for security. Empirically, we know Ethereum, Cosmos, etc have fared just fine so far. We have time before those chains have problems, and even more time--- and warning---before Zcash does.

The goal for V1 of zk-assets is to provide a basic means of addressing econimic concerns and a mechanism for future improvement. We should take a similar approach to Ethereum: they shipped a [minimum viable approach](https://github.com/ethereum/frontier-guide/blob/master/SUMMARY.md) and have progressively addressed economic issues e.g., with EIP1559. As of yet, they have not had major economic security problems.

As a starting point, we examine fees for issuing zk-assets.

### Issuance fee options
1. Flat ZEC fee. Each time the issuance instruction is called, a fixed fee must be paid in Zec.
2. Flat fee per units of assets issued.
3. Percentage fee paid in asset type. Each issuance pays a fraction of the asset e.g., 30 basis points (0.03%), that is claimed by the miner. Suppose 1000 units of a zk-asset were issued. The miner who includes the block could then make an additional 30, paid to them, in the coinbase transaction.
4. A Herbeger Tax on issuance. This results in a ZEC denominated fee as a percentage the assets declared value. Issuers our discouraged from undervaluing the asset because they are required offer the issued asets for sale in an auction with the value as a reserve price. This acheives nearly all of the goals of an issuance tax mechenism without price oracles. Unfortunatly, it seems to raise operational and compliance issues for stablecoins and prevent most kinds of NFT usage. See [this](https://hackmd.io/YBDSGGEOSESeffuDr01WhA) document for further discussion and downsides.
5. A percentage of each asset issuance is taken(as in 2), but is auctioned for zec where the zec is burned. (suggested by nuttycom)

### Drawbacks for redistributive fee mechanisms.
Any fee mechanism that distributes some amount of the issued assets to miners/bidders (e.g.2,4,5 above), has some downsides that should be weighed against the magnitude of the economic risks posed by zk-assets and the emprical effects seen in other blockchains like Ethereium,

* Operational concerns. Custodial stable coins may wish to avoid the KYC/OFAC risks of issuing an asset where part of it ends up going to unkown parties they don't control.

* Incompatibility with NFTs. You can't sell a fraction of a Picasso. Similarly, we can’t issue tokens for access control to e.g., members of a maker space, if anyone can bid for the token or (in the case of first refusal) force the issuer to pay an arbitrary amount to retain the the token. This removes a number of privacy preserving applications.

* Privacy and efficiency concerns. Issuance mechnisms that fairly value the asset may cause people to only issue initial batches of valueless tokens and then, after the auction is complete, make them useful. This may fragment assets by resulting in batches of, e.g., wrapped BTC, actually being different and therefor neither fully fungible or fully private.

### Fees for destruction.
It is possible to support fees for destroying or burning zk-assets as well. It is unclear if doing so will encourage hidden destruction mechanisms (e.g. paying to the null key in a shielded transaction). The same choices for issuance fees apply.

# ZK assets version n.
Once these versions have shipped and after a few more iterations, we should consider implementing a native automated market maker on Zcash to support various assets. ZK-assets v0 are just the beginning.

# Discarded mechanisms.

## For TX fees.
If zk-asset transactions and zec transactions must look the same for privacy, then seemingly the only way to have differential fee's is via burning the fee (as in EIP 1559), since this can be done privately. In principle, it's possible to make the burned fee depend on the asset amount and type, but without pricing oracles its unclear how we fairly value the asset. One possibility is to have asset specific gas. Some pricing mechanism for the gas could be done, in the clear, the gas purchased with zec, and then the asset specific gas burned to transaction.

This poses three challenges:
1. Pricing the gas.
2. Circuit complexity to have typed-fees/gas.
3. Usability concerns for wallets. Instead of just needing zec, you need to pre-purchase asset specific gas. And avoid timing correlations between purchase and ussage. Gas cannot be bought on demand for privacy reasons.