A Proposal for Shielded Assets (ZSA/UDA) for DeFi on Zcash

This is a great question. We did not finalize any design yet, and as such we hope to hear from the community what it is that works best.
In the proposal we do mean the former (enforced socially) by the default mechanism. That being said we do hope to not go for the default mechanism, it just depends on whether consensus is reached by all stakeholders (or a majority thereof).

Since the fee mechanism structure is independent of the actual cryptographic protocol, we are hoping to work on these two in parallel (at least for the design phase) in order to reach some kind of consensus on the fees by the time we start implementing the ZSA protocol for transfer and issuance.

What would you say is the ideal fees structure for you?


Thank you @rekodi for the input - we had briefly considered this problem but did not try to formulate a solution yet. I appreciate this proposal and will consider it.

Could you potentially elaborate on how it mitigates the “free-rider” problem?
As I understand it we would like to have some form of incremental funding on new tokens, correct?


All it would do is require anyone wanting to use the zcash network to acquire and store a stake in the limited supply of zcash. Without it, they would only need very little zcash due to the small transaction fee structure that is native to the zcash protocol. @LeCryptoMath


@Shawn you bring up a super valid point.
I will start by saying two things:

  1. The point here is not to prioritize one solution over another one as per the team’s preferences. It is to enable a community-backed solution.
  2. QEDIT does not have (yet) a solution fully outlined, which gives us the flexibility to be on the neutral side and take in as much feedback as possible. We have been in this situation before (in ZKProof and in DARPA), as the middle objective technical team in charge of bringing consensus for a solution and we never allow any technical, security or usability compromise.

Of course we hope that things will go smooth, but there are key aspects to this proposal where people in the community have strong opinions about, and we are aware of these. For this it is also important that all discussions happen openly such that there is enough transparency to create the right pressure.

Specifically, when it comes to technical aspects, we will absolutely work with the core ECC team as they have built the Orchard (and every other) protocol (basically) from the ground up (sprout was a result of the Zerocash paper). At QEDIT we have also built such systems, so we know what it entails from a security stand point. Our approach is to first collect all functionality requirements and then ensure that the design encompasses all of these.

In terms of fee structures, we do not have a strong opinion, and we will make sure to align the different parties around an initial MVP solution. If it comes to it, we will go for a community-based vote (why the ZCAP exists), making sure there is enough education on the solutions for individuals to make informed decisions.


I totally agree as well, and I hope the proposal shares this spirit!
I think, and as a general note to how the ZOMG will start funding large core projects, there is a need for the community to own the Zcash roadmap, and not just the ECC and ZF (mostly independently). This is especially important for teams that are being funded directly from the dev fund.

The community should define how this roadmap should be built and how decisions should be made. Different teams should be able to give proposals and then vote on schedules, functionality and features to be included, etc…


:clap: @LeCryptoMath Very well written post!

I’m a big supporter of having broad utility for ZSAs. I have only been thinking about this for a short time but have been pondering how much utility we can achieve from a small set of generic ZSA transaction types/features (e.g. ZCash programmability vs L2 using ZSAs).

I’ll try and simplify some functionality I’ve been thinking on below but I’m hoping that by using this simple base we could then offload any more advance features (like programmability) onto L2 POS style chains that using ZCash ZSAs as their L1…

ZSAs minting/transacting other ZSAs

Scenario 1 - Minting Token

A single user mints a “Minting” asset.

A new “IOU” asset is created and the “Minting” asset is assigned as the “allowed minter” with a 100% weighted threshold for minting. Since there is only 1 Minting token any minting request is 100% weighted and is automatically valid.

The user can transfer the minting token to other addresses which can then be used as the address to mint IOUs.

Scenario 2 - Multiparty Minting Tokens

Four “Minting” token assets are created. 3 joint business owners share the tokens. User 1 is assigned 2 assets while user 2 and 3 are assigned 1 each. The Minting token assigns itself as the “allowed minter” requiring 100% weighting to mint more (e.g. all parties must agree to mint more minting tokens).

A new “IOU” asset is created by the company for assigning IOUs to contractors. The “Minting” asset is assigned as the “allowed minter” with a 51% weighted threshold for minting. Since there are 4 Minting tokens any minting of IOU requires at least 3 of the 4 tokens are required to mint new IOUs.

Scenario 3 - Multiparty Minting Tokens using On-chain “voting”

100 anonymous users are giving 1 “Minting” token.

A new “IOU” asset it created and assigns the “Minting” token as the “allowed minter” and requires 50% weighted threshold for minting. Since the anonymous users don’t know each other they have to “register” their vote to mint on-chain with a new “transaction type” (e.g. vote/sign). I like the pseudo “sign” analogy since we can think of them as signature objects that possibly have things like valid after/before timestamps.

If the 50% threshold is reached the tokens are minted.

Scenario 4 - L2 programmability using ZSAs

100 stakers all run a “ZCompute” (fictional programable L2) node while holding/staking/locking “ZCompute Staking” tokens.

The staking tokens have “minting” and “transaction” rights for the ZCompute tokens and require at least 50% vote for minting and/or transactions to occur. As they compute (or verify a compute/proof) they place their votes for minting or transacting tokens.

Additionally to this ZCompute staking tokens need to be “lockable/destroyable/0x0 transferable” to disincentivize bad actors. Stakers can vote to “destroy” staker tokens from bad actors.

@LeCryptoMath I’d be interested to know your thoughts on this and if this is a feasible end goal :).


Fantastic proposal from QEDIT and very good approach.

I think, and as a general note to how the ZOMG will start funding large core projects, there is a need for the community to own the Zcash roadmap, and not just the ECC and ZF (mostly independently). This is especially important for teams that are being funded directly from the dev fund.

Looking forward to see the community involvement, this is another aspect that should be thought carefully considering also past experiences.


Hi all, just wanted to point out that we updated the proposal with concrete milestones, an estimated timeline and a budget. This is officially our proposal submitted to the ZOMG (hopefully to be made public as soon as they review it).

Any thoughts are welcome :slight_smile:


Assuming this grant is indeed a zebra implementation, we would need to make sure zcashd team has the resources to independently implement it on their side. Otherwise we’d have to fund another independent implementation (can’t be same team).


Timeline looks optimistic :slightly_smiling_face::+1:


Meaning too ambitious or conservative / doable? Let’s discuss at the arborist call :slight_smile:


Looks great guys.
Quick question, this grant is targeting essentially zsa funcionality and not the ux on mint those right? How would you expect to implement it? Or is this a task included on ecc wallet roadmap ?


Discussion about this ZSA proposal on the Arborist call is now up:


9 women don’t make a baby in a month, but is there buffer within the team if you wanted to allocate more man-hours to parallelise/speed certain things?

Correct, the proposal leaves out of scope an actual UX wallet. I would imagine that wallet providers would take responsibility of implementing the frontend for ZSA, or so I hope!


Well, we will have several people working on the same milestone to advance in parallel, but there is a limit to how much you can parallelize this kind of work since there are too many moving pieces that are dependent, and the security risk is also high.

We will do our best!


@egg is working on exploratory design elements to support both tokens & NFTs in @NighthawkWallet, we will be sharing these designs soon.

The NFT market has exploded to multiple billions of dollars in total volume just this year. Shielded NFTs will provide privacy in ownership and transfers while keeping portion of public facing data visible.

How are you planning to support public facing data and possibly minting of a Shielded NFT and a Metadata standard? i.e. exposing the NFT type, policy-id, and properties in a simple JSON format - see Minting NFTs | Cardano Developer Portal & CIP - NFT Metadata Standard - CIPs - Cardano Forum

Settling on a Metadata standard makes possible public gallery of tokens like this: pool.pm
(following Cardano’s example over Ethereum standard is a better idea as Cardano uses UTXO model over Ethereum’s Account based/smart contract model for each asset).


Curious - how would this create synergies with ECC’s roadmap for interoperability as published on their blog? How would your one-way bridge (outside-to-in) work with their Cosmos approach (bi-directional, presumably)?


(Speaking for myself, not ECC)

Note that the ECC roadmap uses Cosmos as an example, not as a solution. It is too early to be restricting the PoS design space to specifically the Cosmos stack, or even PoS designs that are compatible with Cosmos’ IBC (which IIRC places specific finality requirements on the underlying consensus layer). However, the ability to which a particular design enables interoperability is something we will be considering as part of the design exploration process, and IBC-based interoperability is an attractive option given the existing ecosystem.

Now, assuming that a PoS approach was taken that enabled us to leverage IBC directly, that on its own would only be a one-way bridge (inside-to-out: ZEC could move from the Zcash chain to other ecosystems). Even though IBC itself is bi-directional, other assets could not move onto the Zcash chain because there’s currently nowhere for them to “live”. So I personally see ZSAs as entirely complementary to ECC’s interoperability roadmap.


amazing. the outcome i was hoping for. duplication of efforts might not be ideal.