[Grant Update] Zcash Shielded Assets Monthly Updates

Dear Zcash community,

We are really excited to share with you the first DRAFT versions of the ZIP (specifically ZIP 228) that covers the ZSA Swap protocol. This corresponds to Milestone #6 of our Asset Swaps and Beyond grant.

This ZIP has been in the works for the past few months and we have interacted with the community, the ECC and the ZF developers while designing for compatibility, usability, and security of the protocol. We’ve mentioned the draft Google Doc in previous posts, where we’ve had some great discussions in the process of creating this design.

A short description

Motivating use case

The primary scenario we have in mind is one where there are two parties who want to exchange some quantity of Assets between each other.

ZSA Swaps

  • The ZIP provides a specification for a Swap Order, which is what a party creates when it wants to send some quantity (q1) of an Asset (A1) in return for some quantity (q2) of another Asset (A2).
  • In the P2P case, one party sends it’s Swap Order off-chain to another party who wants to send the quantity q2 of Asset A2 in return for receiving q1 amount of Asset A1. This second party creates it’s own Swap Order to that effect independently
  • Once the two Swap Orders are present, the ZIP specifies how the party can combine them into a transaction that simultaneously transfers the respective amounts of the two Assets between the two parties.
  • We have included a time limit for the validity of a Swap Order, so that the party receiving the Order in order to settle it does not get the unfair advantage (free option) to wait indefinitely until it can profit from a more favourable exchange position.

Under the Hood

Our design required some changes to the Orchard-ZSA protocol in order to be able to handle valid Orders in all scenarios. The major update has been addition of the time limit as mentioned above, and the grouping of Actions based on the Merkle tree root they are constructed under, so that the zero-knowledge proofs in them can be verified appropriately.

Our aim has been to keep these changes to a minimum so that we can stand on the shoulders of the existing cryptography that is already in place in Orchard and Orchard-ZSA. We encourage you to go through the ZIP for the specifics and let us know your comments.

Discussion points

  • Though creating a design to support the peer-to-peer case has been our main focus, we do note that our design is flexible enough to allow for the secure use of Matchers in place of having one of the parties submit the Swap transaction to the chain. This allows for the support of Zcash transaction relays, and support for Matching Services, centralized or otherwise.
  • We have provided a discussion on the considerations for fees as well as some ideas for maintaining fairness and preventing denial of service attacks


These ZIPs are in DRAFT mode and will definitely see some changes in the months to come, as we receive feedback from the community and developers, as well as changes that arise in the implementation process. We will soon begin working on a prototype of these designs.

We welcome any comments and questions! We hope to hear from you all about your thoughts on our work.

The QEDIT Team.