[Grant Update] Zcash Shielded Assets Monthly Updates

can you provide a sensitivity around a base case and expected?

I recently watched the QEDIT sessions at Zcon4, very interesting that ZSAs are not only useful for shielding coins but could be used for NFTs and even decentralized governance/voting.

With the transition to Zebra as the core, what kind of timing are we looking at to get this on testnet? Or the next NU?


@shawn You might also be interested in the ZSA updates from recent Arborist calls. (sorry abt the poor sorting)



That link is weird for me idk, gonna try this one

1 Like

Dear Zcash community,

Best wishes to all of you for 2024! We are happy to share with you an update on what we have been working on over the last few weeks. We have made some exciting progress on Zcash Shielded Assets as well as the Asset Swaps and Zebra node work, which we will be detailing below.

V6 Transaction structure for the Zebra node

We have implemented the initial V6 transaction format as specified in ZIP 230, thereby enabling support for Zcash Shielded Assets (ZSA) features such as burn and issuance.

The major changes involved in this include an extension to the ShieldedData struct and a Rust feature flag activation for all V6 transaction changes. More details can be found in PR#3 and PR#5 on our fork of the repository.

Zcash / Zebra Transaction Testing

Due to the move to Zebra and the fact that Zebra does not generate transactions but only verifies them, we are developing a test tool for transaction generation. While this tool will eventually be used for ZSA/TxV6 testing, it will also be helpful for testing the existing transaction structure. Therefore, we decided to add TxV5 support as well, and focus on this for the initial release. Later, when librustzcash is ready with full V6 transaction support, we will upgrade the tool to perform both V5 and V6 transaction testing.

Additionally, the Zcash Foundation has recently added an experimental test-only internal miner into the Zebra codebase, which allows us to mine native ZEC Assets more easily during our tests. This addition supports our testing effort since we can now focus on the Orchard pull and avoid dealing with unshielded transactions.

Zebra node test setup for forks

The Zebra node is currently being tested only against the main-net chain. We are therefore working on upgrading the existing test setup for the Zebra node to support different chains. This will allow us to test the node against modified chains that support different sets of consensus rules, such as the future ZSA-enabled chain.

Moving to the Bitcoin Schnorr scheme for the Issuance Authorization Signature

We had previously described our changes to the ZIPs in order to move to the BIP 340 Schnorr signature scheme for the issuance authorization signature. We have essentially completed the implementation of this scheme change in the Orchard-ZSA implementation and will merge it in the coming days after an internal review.

Extending Orchard-ZSA with backward compatibility for V5 transactions

We have been working on generalizing our additions to the Orchard crate so as to simultaneously support both V5 and V6 transactions, which is a necessary step for integration in NU6. We are excited to announce that we are in the final stages of this work, and that we will soon also be merging in these changes. We look forward to having a version of the implementation that handles both V5 and V6 Orchard bundles.

Atomic Swaps Design

We have made changes and improvements to the Atomic swap design as part of the initial review and the community feedback. We encourage everyone to have a look at the draft document!

Edits to the ZIPs

There aren’t significant changes in this area, our ZIPs have been largely stable for some time now. We received some comments from the ZIP Editors regarding rearrangements that would improve readability and clarify ambiguity, which we have incorporated. We look forward to having them merged and included on the zips.z.cash site soon!

As always, please feel free to play around with our work. Let us know if you have any questions, or just what you think!


The QEDIT Team.


I really appreciate this Grant, let’s pass everything on to Brazilian community. You’re sure to love it.



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.


are ZSAs like the engine part?
but someone has to build a DEX front-end for it also?
is this correct thinking? or is there more to make it all work after ZSAs are ready to launch?

The ZSA Protocol allows for issuing new Assets, and for transferring Assets between parties.

If we are keen to have a transaction where we want to exchange Assets, the Transfer protocol allows you to send me Assets and me to send you Assets. However, since the two transfers are not “linked”, there is a possibility that your transfer transaction gets on the chain and I prevent mine from getting on the chain. So then I have the Assets you sent me, but I haven’t held up my end of the bargain.

That’s where the Swaps protocol comes in. You create an Order for the transaction you want to happen, I create an Order for the transaction I want to happen (which would be the reverse of your Order, essentially). Neither of us lose custody of our Assets until the two Orders get combined into a single transaction, and that transaction gets on the chain.

This immediately allows for a much wider range of financial transactions using ZSAs, since it reduces the need for trust between two peers exchanging Assets. Swaps, as they stand, also support us sending our Orders to some matching service that looks at the orders coming in and matches them and creates the total transaction to settle on the chain. Those could be CLOBs, AMMs, and so on. But that would be separate work to build these services, it isn’t part of the consensus protocol on Zcash.


thanks. sounds great that swaps are possible with no other service.

but we will need someone to still build the AMMs etc. wonder who will do that.

1 Like

Dear Zcash community,

We have been working towards making progress on our milestones for the ZSA and Asset Swaps grants. On the back of our initial draft of the Asset Swaps ZIP a few days ago, we’re really excited to share that we have now published our tool for testing transactions to Zebra nodes. This corresponds to Milestone #8 of our Zcash Shielded Assets Grant.

We believe that this tool will help not just us as we continue with our implementation of ZSAs with Zebra, but also to other developers in general who want to locally test their wallets or other tools with Zebra nodes.

The repository for this tool can be found here: GitHub - QED-it/zcash_tx_tool: A testing tool for Zcash transaction generation

The functionality, in brief

Developers will be able to use this tool to create and send Zcash V5 transactions to a Zebra node. We have included a Docker image creation process to set up the testing scenario.

We highlight that there are a few changes to our mode of node operation as compared to the normal Zebra node.

  • We have an activation height of 1,060,755 blocks. For ease of operation and reduction in the sync time that would be needed to get these many blocks, we have pre-mined blocks up to the activation height and stored them in a database that is built into the Docker image.
  • The consensus branch ID is set to a custom value — this ensures that the testing takes place on a fork of the main chain.
  • The node does not connect to peers (it has an empty peers list). This allows for testing in a manner similar to Regtest mode on zcashd. Furthermore, while zcashd regtest mode had proof of work enabled but set to a low difficulty for block mining, this tool disables proof of work so as to simplify the generation of new blocks by the single node, and focuses on the creation and sending of transactions.

Please go ahead and try it out, and let us know your thoughts or comments!


The QEDIT Team.