Zcash Shielded Assets -- Asset Swaps and beyond

[vivek]

Hello Zcash community!

The QEDIT team has been working on designing and implementing generic shielded assets (Zcash Shielded Assets, aka ZSAs) on the Zcash blockchain. We’ve been much enjoying the work with the dev teams and the community, and it’s a good time to thank you again for the feedback on the development progress for each milestone.

As we enter the final laps of this project, we are excited to share our proposal for continued development, which aims to get ZSAs ready for deployment and to introduce important features, for a wider adoption of Zcash.

Our proposal outlines the QEDIT ↔ Zcash roadmap for 2023 and beyond, focusing on three significant developments:

1. Enabling ZSAs on the Zcash main-net.
2. Adding Asset Swaps.
3. Improving user control over incoming transactions and additional features for exchange compatibility.

For now, QEDIT will be submitting a Grant Proposal only on parts 1 and 2, and will submit part 3 in 2024.

Below we present, for each of the efforts and features we will work on, the rationale and the tradeoffs we would need to address. As always, please share your thoughts!

Enabling ZSAs on the Zcash mainnet

Over the course of the last year, we have implemented the core ZSA protocol on our own forks of the zcash, orchard, and librustzcash repositories. With these forks we were able to develop efficiently, experiment rapidly, validate our implementations, and iterate, thereby stabilizing a design. Now that the design is more stable, we think it’s useful that more devs and users try it out, play with the features and share their experience.

We are currently on track to integrate our protocol into the next Network Upgrade (NU6), for which we will be working with other developers to ensure that our changes for the ZSA protocol fit in seamlessly with the other developments planned for NU6.

We will be supporting and facilitating an external security audit of the ZSA protocol, so that our design and implementation can be thoroughly vetted for maximum confidence.

We also plan to launch a ZSA-specific testnet, that will allow developers and users to experiment with the issuance and transfer of new assets in a sandboxed environment that allows for us to spot areas for further improvement and increases user confidence in the features. We believe the testnet would benefit from the presence of a dedicated block explorer that gives experimenters a clearer picture of the internals of the blocks post the change from the Orchard to the ZSA protocol, and therefore will be including a block explorer as a part of our deliverables for the testnet. The security audit team will also benefit from the existence of this testnet while vetting the operation of the protocol.

Asset Swaps

One of our major contributions in this proposal will be the addition of support for Asset Swaps for Zcash Shielded Assets. This is a feature that enables users to perform trustless, decentralized transactions with multiple different assets, and will simplify the process of trading assets within the Zcash ecosystem, attracting new users seeking privacy-focused finance solutions. Atomic Swaps are already popular on other blockchains, and their inclusion in the Zcash ecosystem has the potential to significantly boost demand for ZEC and related assets.

There are a number of interesting questions we need to consider while developing Asset Swaps for Zcash.

• If we consider a Swap between two parties, we must consider repercussions of, and possible mitigations for, the “free option” that becomes available to the party that performs the last step of the protocol. That is, it is possible for that party to abort the protocol at this last step if the Swap is no longer beneficial for it.
• Since the “exchange rates” of different Assets are dynamically changing, we would need to provide a mechanism for time-limiting Swaps. This mechanism would also reduce freezing up of Assets due to their being locked up in Swaps that have not been completed. At the same time, some time window would need to be provided in order to find a matching Swap, for example. We would need to balance the length of window based on these considerations.
• The basic notion of an Asset Swap would involve two parties who already have an idea of what Assets they want to Swap decided off-chain (like an over-the-counter transaction). However, we would be able to get much closer to market-like capabilities by allowing for Swaps to occur by matching parties’ Swap offers together (without the parties having found each other ahead of time). This brings up additional considerations, such as who performs the matching of the offers? Privacy considerations would center around the information revealed to the matching party. The simpler notion would involve the matching party learning the amounts and types of Assets being swapped, while a more advanced notion would have these details remaining confidential even to the matching party.
• We would also require a fee mechanism that maintains fairness to all users, and disincentivizes parties from flooding the network with spam Swap offers that are unlikely to be matched. Swaps would be ocuring on top of the ZSA Transfer protocol, and therefore the fees would also need to mesh with the fees for the transfers.
• There would be changes required to the Note structure to allow for Asset Swaps. Our priority would be for changes to be minimal, and to reuse existing cryptography and structures from the Zcash ecosystem in order to allow for more robust security analyses and make full use of the development that has already been done in the ecosystem.

Exchange Compatibility and Improved User Control

Note: We will submit the Grant Proposal for this section formally in 2024.

We want it to be as easy as can be to onboard new adopters of Zcash. One way of doing so is by making it easier for them to interact between fiat and ZEC through major exchanges, that is, simplifying the purchase and sale of ZEC and ZSAs.

We aim to improve compatibility with major exchanges, such as Gemini, Coinbase, and Kraken, by enabling greater wallet control over incoming transactions and adding optional sender information in Zcash transactions, under the control of the user. This will make it easier for users to buy and sell ZEC and bridge Assets through these exchanges, driving further adoption of the Zcash ecosystem.

The status quo in Zcash is that funds simply appear in the user’s wallet once they are sent by a sender. We would like to give users and exchanges more control over the transactions they allow into their wallets.

There are a few different approaches we can take for this:

• We can allow transactions to enter the users wallet by default, and require explicit action by the user if they want to refuse a transaction.
• In contrast, we could require explicit authorization by the user if they want to accept a transaction, and have transactions refused by default.
• Another option could be to allow users to opt-in to accepting certain types of Assets by default, and refusing others by default.

Each approach has different trade-offs with respect to design and privacy, and these need to be carefully analysed before choosing the best option. For example, the opt-in approach exists on Algorand, but in a private cryptocurrency like Zcash, allowing for automatic rejection of specific types would require the users “blacklist” being public, and also result in the type of Asset being transferred in a transaction being revealed. The accept/reject by-default approaches would require time-limiting features, since they run the risk of Assets being frozen in transactions waiting for approval.

Most exchanges need compliance and travel rule requirements to be met before they can provide cryptocurrencies in exchange for fiat, and vice versa. We propose to add the option for the user to attach additional sender information, in a privacy-preserving manner, to a transaction on ZSA. This gives users the option to add necessary compliance information to the transaction when they are interacting with the exchanges. We believe this would bring Zcash further into the mainstream and allow it to be exchanged as popularly as other cryptocurrencies like Bitcoin and Ethereum.

Risks and Mitigation

• As we move towards making ZSA production-ready, our increased focus will be on ensuring security audits and addressing the challenges of increased complexity. Although this presents risks, we believe that collaborating with outside teams, in addition to our work with ECC, will help in mitigating potential security flaws effectively.
• The introduction of ZSA is a significant feature in the Zcash ecosystem, and we recognize that other major features, such as execution of contracts in zero knowledge, may be implemented in the future. With this in mind, our team aims to design our solutions with openness to future adaptations and compatibility with upcoming developments.

Our team is committed to addressing these challenges and delivering a robust, secure, and user-friendly solution that strengthens the privacy-focused nature of Zcash.

Overview of the way ahead

Our team will be working closely with the Electric Coin Company (ECC), the Zcash Foundation, and the wider Zcash community as we proceed . We will release a series of ZIPs (Zcash Improvement Proposals) detailing the design of the new features, and submit pull requests to the appropriate repositories as we make progress on our implementations. We will simultaneously provide regular updates on our progress through community forum posts.

Our testnet deployment and setup would involve the construction of the network, and maintenance for a period of 12 months. Furthermore, we will also develop and maintain a block explorer for our testnet.

Milestones, Timing and Budget Plan

For this proposal we will follow a similar budget plan as the current grant that QEDIT is executing.

We propose to work per milestones, and we list here the different milestones or outputs we will deliver as part of this project. For brevity, we divide our milestones into different parts for the different aspects of our project:

1. Enabling ZSAs in the Zcash mainnet:
   1. Integration with NU6
      • Work with ECC and ZF to update the final NU6 specification
      • Adapt compatibility of the ZSA implementation with the Orchard protocol
   2. Testnet infrastructure setup:
      • Successful build and compilation of the ZSA-specific libraries, set-up of a local testnet over a few nodes, testing of successful communication,
      • Choice of genesis block and DNS seeder details, deployment of testnet, and public call to join
      • On-going support for ZSA-specific testnet:
        • Updates to the testnet based on analyses of the data generated from usage.
        • Maintenance and issue debugging.
   3. External Audit Support
      • Publish a call for proposal for a security audit of the ZSA protocol
      • Work with the chosen team to ensure the audit is smooth and has the highest coverage.
   4. Development and launch of Block Explorer for ZSA-specific testnet
2. Asset Swaps on ZSAs:
   1. Asset Swaps ZIP
      • Gather feedback on the initial designs and tradeoffs from the community and stakeholders
      • Publish a full ZIP specification of the atomic swaps feature
      • Work with the stakeholders to upgrade the ZIP to proposed status
   2. Asset Swaps Implementation
      • PRs to the Orchard and zcashd repositories
      • This includes protocol and circuit changes, as well as node and consensus changes
      • Includes extensive tests within a self-contained environment
   3. Asset Swaps Integration
      • Ensure PRs for the ZIPs and implementation are merged with the main branches
      • Take care of any pending issues and help support additional testing
3. Compatibility with Exchanges:
   1. Transaction Control ZIP
      • Gather feedback on the initial designs and tradeoffs from the community and stakeholders
      • Publish a full ZIP specification of the feature to allow users to refuse transactions
      • Work with the stakeholders to upgrade the ZIP to proposed status
   2. Transaction Control Implementation
      • PRs to the Orchard and zcashd repositories
      • This includes protocol and circuit changes, as well as node and consensus changes
      • Includes extensive tests within a self-contained environment
   3. Transaction Control Integration
      • Ensure PRs for the ZIPs and implementation are merged with the main branches
      • Take care of any pending issues and help support additional testing
   4. Exchange Compatibility ZIP
      • Gather feedback on the initial designs and tradeoffs from the community and stakeholders
      • Publish a full ZIP specification of the features to include compatibility with major exchanges
      • Work with the stakeholders to upgrade the ZIP to proposed status
   5. Exchange Compatibility Implementation
      • PRs to the Orchard and zcashd repositories
      • This includes protocol and circuit changes, as well as node and consensus changes
      • Includes extensive tests within a self-contained environment
   6. Exchange Compatibility Integration
      • Ensure PRs for the ZIPs and implementation are merged with the main branches
      • Take care of any pending issues and help support additional testing

The expected budget is roughly $150k per month of work, covering a team of about 8-9 engineers and contributors.

---

We believe that these new features will play a crucial role in establishing Zcash as the go-to platform for privacy-respecting finance on the internet. The introduction of Asset Swaps, improved compatibility with major exchanges, and enhanced user control over transactions will not only expand the functionality and utility of Zcash but also attract new users and businesses seeking a secure and private financial ecosystem.

We are confident that these developments will contribute to the growth and success of Zcash, benefitting the entire community. Thanks to the joint efforts of everyone involved, we believe Zcash will keep leading the space of privacy-focused digital currency, and pave the way for secure, private, and decentralized finance!

---

Acknowledgements

The QEDIT team involved in writing this proposal includes Pablo Kogan, Alexey Koren, Constance Beguier, Eran Tromer, Jonathan Rouach, Antoine Rondelet and Vivek Arte (myself).

We would like to thank the following individuals and teams for their help in thinking about the proposal, its contents and implications, as well as for the fruitful discussions since this idea was brought up: Jack Gavigan, Nate Wilcox, Aditya Bharadwaj, Daira Emma Hopwood, Jack Grigg, and the ECC core development team.

[GGuy]

@vivek

The expected budget is roughly $150k per month of work, covering a team of about 8-9 engineers and contributors.

Sounds like the perfect time to offer direct funding.

[GGuy]

Hi. When I pondered atomic swaps I thought about them being implemented as off-chain contracts that the receiving party can optionally execute on-chain… “Options”. On chain would also be awesome too, definitely wouldn’t rule it out but it feels way more complex and harder to get right. Anyways… Just food for thought my comments are below.

@GGuy

Open recipient atomic swaps

I like to call them “options” and think of them in the same way we think of traditional financial options. Someone may receive (for free or paid) an option and can “optionally” execute the atomic swap before the expiry time. (Edit: the assumption here is the options issuer can set the expiry time).

One example is an exchange. They could allow a user to select the exchange pair on their website and enter amount to spend. The website would then issue them (e.g. via QR code) with an option based on the current exchange rate that’s only valid for a short period of time. The user can then execute that atomic swap if they choose. I imagine the slip is largely dependent on how long the option is valid for.

The added benefit here is an exchange could allow users to purchase options with really long expiry times for additional hedging/trading options.

Think about them as options also open up the idea that a failed execution of an option could trigger another action (e.g. think insurance).

@GGuy

Fail case open recipient atomic swaps

Open recipient atomic swaps that allow the receiver to execute a fail case in the event the atomic swap fails (e.g. insured loans, secured loans, etc). This would enable 3rd parties (or DAOs) to insure “options”.

Also, conditional options should be a thing.

@GGuy

Conditional “options”

Think of options that are condition on an option before it being executed.

Imagine a 1year car loan with monthly repayments. Ownership of the car doesn’t transfer until all 12 repayments are made (i.e. executed options). This could be done a few different ways:

• User receives 12 sequential options that must be executed in order. The first 11 are simply ZEC payment to the loan company. Last one is an atomic

---

It wasn’t my intent but now that I think about it stacking options in this way is kind of like an off-chain smart contract . What other features might we need to support this off chain Turing machine . The more I think about it the more I likey !

---

Edit
From an implementation perspective we could pass the contracts/options around in JWTs, CWTs, and/or ZWTs. There are a couple of benefits I see here:

1. The options receive all the privacy features of a memo but are only optionally executed by the receiver. I assume ZWTs are simply CWTs that only need to store the payload as they rely on the underlying cryptographic properties of the memo. The main reason I call them ZWTs is because the APIs and terminology would match and there would be a clear/clean conversion between JWTs, CWTs and ZWTs.

2. ZWTs don’t exist yet but the benefit here is if the memo field is big enough for V1 but not big enough for future complex claims then that work could be offloaded to the others to solve.

3. If we want more complex system such as on-chain exchanges then the problem that needs to be solved is simply making some memos optionally transparent (and possibly labelling/categorising them). The ZWT memo stays the same we just allow a special kind of transaction that’s transparent. Again, optionally could be offloaded to other teams.

@GGuy

I’ve always thought “Zcash Object Signing and Encryption” would be a good idea

[JoakimEQ]

This is very cool!

How can one stay updated and partake in your upcoming testnet? We have been doing research on ZSAs and are very interested in tinkering around

Once something like atomic swaps are interested, one could probably make some kind of structure that displays them on a frontend right? Then we could possible come close to having some kind of order book on chain? (A seperate discussion on if that is wanted or not though)

How can I contact you?

[decentralistdan]

@vivek, QEDIT Team, & Zcash Community, I am happy to inform you that the @ZcashGrants Committee has voted to approve the Zcash Shielded Assets- Assets Swaps & Beyond grant for $1.8m at the most recent meeting.

[zkcroc]

I am so pumped for this