Shielded Assets (ZSA/UDA) for DeFi on Zcash

Due to lack of space, please see the full technical proposal at this link

Please note that the total amount for the grant is of $1,187,615, but the previous field did not allow to input a value larger than $1m

At QEDIT we believe that privacy is a universal human right. We also believe cryptography is a powerful tool to provide financial privacy, which promotes the freedom of the individual.

With this proposal, we want to bring DeFi to the Zcash ecosystem, and at the same time enable the use of the best privacy technology within the existing DeFi ecosystem! A couple of months ago we asked, and the community answered: generic shielded assets (ZSAs / UDAs) are the most requested feature at the moment.

To pave the path for private DeFi, we wish to extend the Orchard protocol with these three features:

• Implement a permissionless issuance mechanism for native shielded assets, which will provide users with some degree of programmability over minting different types of assets (fungible vs non-fungible, public vs private supply, etc)
• Extend the transfer mechanism to allow for multiple types of assets to be transferred in the same transaction, while maintaining a single anonymity pool for all assets
• Enable a secure one-way bridge with other blockchains, allowing for existing assets to be imported onto the Zcash ecosystem

These features form the basis for a fully fledged native and private DeFi ecosystem on Zcash such as private DEX, AMM and lending (as well as anonymous credentials for identification), which we see as future work. Our goal is to develop these core features with extensibility in mind.

The project is expected to last between 8-10 months of design and development and another two months of review and merger with the main code-base (or as defined by the NU6 deployment roadmap, to be determined).

Approach & desiderata

To build a usable MVP that will enhance adoption of Zcash, since this is the first core development project outside of the ECC and Zcash Foundation, we will work with the community and other stakeholders to test our assumptions, and ensure that our final design includes the user's feedback. The design must prioritize usability, economic and technical considerations. The following is a list of desiderata:

• Usability:
  • take a product and experience (UX) design approach
  • build easy-to-use, stable APIs
  • ensure, when possible, the interoperability of different implementations (e.g. zcashd vs zebrad)
• Economic:
  • design an incentive mechanism for the validators and current users of $ZEC (e.g.:ZEC-based fee structures)
  • ensure reserve integrity for imported assets by verifying collaterals exist in the corresponding blockchain
• Technical:
  • identify underlying commonalities (such as locking / burning mechanisms)
  • ensure the development is aligned with other builder teams, creating a shared roadmap for the development of the Zcash ecosystem
  • incorporate feedback from other experts and work with security teams for ensuring proper review of the code

Applicant background

We are QEDIT, the cryptography team that performed the audits for both Sapling and Orchard before they launched into mainnet. We run the ZKProof standardization effort, and we are leading the [zkInterface interoperability standard]() within the DARPA-funded SIEVE program to advance the state-of-the-art of ZKPs. We've built the first enterprise-grade private asset transfer solution, extending the Sapling protocol.

Technical components & scope

In this proposal we do not aim to provide the exact details of how the features will be designed or implemented. Our goal is to give some intuition of why we believe that this project can be done and to collect feedback and input from the community on these topics.

For each of the outlined components below, there are several aspects to their implementation:

• Core cryptographic protocol design, specification and implementation
• Circuit changes and implementation
• Integration within blockchain components, such as consensus rules, networking, etc.
• Integration with existing nodes (Zcashd & Zebra)
• Security assurance through tests coverage and internal reviews

Due to lack of space, please see the full technical proposal at this link