ECC's work to date and next steps for ZSAs


Thank you, @joshs and the many others at ECC working on this, for this great update.

I too think that Zcash Shielded Assets are a crucial next step for the Zcash vision, and you’re doing impressive work in addressing it simultaneously from all of these complementary angles. Can’t wait to see what is learned from these first steps, and what are the next ones!

How can the rest of the community help? What finer-grained questions would you like to bring up for brainstorming or input-gathering, and what ZSA-related efforts/projects would you like to see initiated by others in our community, supported by ZOMG, etc? And putting on my cryptographer hat, what kind of interesting ZSA-related protocol/cryptography/security questions need research attention?


There are questions about native shielded support - whether TZEs are sufficient to support something like a native zUSDC or whether they would need to be issued on another chain first.

Another question related to regulated assets is whether, or how, assets can be frozen. Regulated stablecoin issuers have to be able to freeze assets on addresses that show up on an OFAC sanctions list.


Another concept that’s come up a couple times is a shielded DEX. How do we allow ZSA swaps within a shielded pool? Might be a killer feature.


let’s not support fiat based stablecoins on Zcash. It’s only going to get negative attention towards Zcash.

shielded DEX is great idea. Has there been any research into this? Is that feasible?

Would be awesome to see a Zdai or something along those lines, a decentralised, shielded stablecoin


These are good questions.
TZEs allow stateful smart contracts like functionality on zcash in a really elegant way, but the “contracts” are hardcoded into the client, which means that “writing a contract” has to go through the entire release cycle for zcashd. This is enough to do issuance of private currencies.

This is also enough to build a DEX , but only if there’s some offchain sequencer who updates the TZE state which is what, increasingly, a lot of AMMs look like. The one thing TZEs don’t let you do is have multiple people try to call functions on a single “contract” at the same time. To avoid that, someone has to sequence calls and update state. But again, none of this is a problem for issuance of centralized stable coins where there’s a single logical entity who controls the reserves and owns the issuance contract.

So, out of the box, we can trivially support tether and the like in exactly the same way they support it on Bitcoin via colored coins, but with privacy , better scale, and lower fees. And we can do all the multisig/threshold bits you need for treasury management.

If you need more complicated issuance, we can do that via a custom TZE or a bridge to a smart contract platform. The bridging already, mostly, exists for wrapping ZEC on other chains.

I would be curious if this is someone reflexively asking for feature parity with ethereum even if those features are unused or can be achieved in other ways. As far as compliance goes,most such lists can be kept on the operator side for actual withdraws.
This gets you most compliance and indeed most of the lists for, e.g., politically exposed persons and the like are maintained by the operators/institutions anyway and have to be for confidentiality reasons. As far as I know, no one puts those on chain.There’s a reason most of the on chain block features are never used and IIRC USDC has one banned address in it.

Of course, the one thing you can never do in Zcash, b/c private transactions are fungible, is freeze funds and prevent them from moving on chain. Stablecoin issuers can block conversion to FIAT using KYC/AML rules though.


@hdevalence is building exactly this (called Zswap) for Penumbra. I see lots of overlap between where Zcash wants to be & what’s being built for Penumbra. I wish hdevalence stayed with ZF to build this!!


Well, permisionless means someone will do it on Zcash. If it’s useful, then why not?

1 Like

What’s the scope of ZSAs? I’ve read the about the wrapped token use cases for ZSAs but are there any others? If so is there a discussion listing those? Some ideas.

  1. Voting tokens (think ECC airdropping voting tokens)
  2. Signing tokens (think transferable signing keys)
  3. Encryption tokens (think transferable encryption keys)
  4. Authentication token (think transferable authentication token)

Note: I understand there’s a desire to keep complexity of ZDAs down but I was just curious if these discussions have been had as I couldn’t find any references.


Have their been any tech discussion on UDA/ZSA other than what’s been shared in the forum?

@GGuy probably you have seen these but might be relevant:

1 Like

Thanks @tokidoki,

With that in mind I’ll detail some of the scenarios I imagine a ZSA might play a part in (some of these might be a few versions down the line).

TLDR; ZSAs should allow us to support any use case JOSE (JWTs, JWSs, etc) are used for. Only on chain we get the benefit of being transferable.

voting token

  1. ECC airdrops 1:1 voting tokens to all holder of an asset (e.g. ZCash). Optional feature to allow setting an expiry/lock/destroy date.

  2. Token holders transfer their token to specified address(es) to vote (with memo if required).

Ability to airdrop X:Y ratio of tokens.
Maybe expiry (think JWT claims)

transferable signing token

  1. Issuance of a non-fungible token to be used for signing.

  2. Online attestation service signing and storing on chain somehow (e.g. linking email accounts to ZCash addresses).

  3. Attestation business is sold and signing token is transfered.

What even is a signing token anyways? Is it just the ability to issue new ZSAs (maybe non-fungible?) referencing itself (aka issuer) and the material to sign?
Issue a (non-fungible?) token referencing issuer (signing token) and material being attested (on-chain or off-chain data/hash/key/etc).
Ability to transfer signing token and original owner no longer has the ability to sign.

transferable access token - non-fungible

  1. Online service issues access token upon successful authentication. Optional on chain issuance, approved actions, expiry, etc.

  2. Transfer access token to partner to act on my behalf.

  3. Partner uses service on behalf of user.

APIs for service to service to do token based authentication and authorisation.