[Grant Update] Zcash Shielded Assets Monthly Updates

Great Progress and an excellent summary.
Are each of the ZSA team and ECC tracking Rust version compatibility to this project as their own risk entries? (or is this risk tracking isolated within the ZSA team’s work)
Can you share additional detail about the nature of the build problems that could manifest based on Rust 1.64 or later?

Hi @noamchom ,

The ECC is definitely tracking the compatibility of the Rust version for their own changes to their crates (orchard, librustzcash and so on). I don’t think the ZSA changes need the MSRV to be >1.61 at the moment, but we also want to keep track of how the issues resolve so that our code merges into the zcash repos as effortlessly as possible when the time comes.

As for the specific issues, there were a few messages on the Discord channel. To list the issues from there:

Hope this helps!


Dear Zcash Community,

Right before we meet at Zcon4, we wanted to share with you the updates on our progress with the ZSA Project. Our main focus has been working on the implementation of the transfer circuit (milestone #6) and the client wallet (milestone #9), as well as getting to the final design on the ZIPs.


We are happy to update that we have largely integrated the ZSA circuit into the Orchard code! We have also added a number of tests, both positive and negative, to confirm the implementation works as expected. We hope to update you with the completion of milestone #6 soon :slight_smile:

On the client side, we have been working on adding and integrating RPC calls for wallet info, issuance and transfer of assets.

The overview of the updates is as follows:

  • We have rebased our repositories on top of Orchard 0.5, zcash_primitives 0.12, zcash_note_encryption 0.4 and a recent version of halo2, something that is necessary to ensure that our additions are well in sync with the rest of the code.
  • The issuance key derivation has been updated to a new mechanism, similar to ZIP 32.
  • We have added support for serialization of the burn mechanism data in librustzcash.
  • We have updated the Python test suite with further unit/integration tests.
  • We have updated the way split notes are handled in the orchard crate.
  • In the halo2 repository, we have added / exposed the necessary functions to support the new circuit functionality.
  • We now have a complete un-optimized circuit implementation for ZSA.
  • The zcashd client has been updated to add support for issuance and wallet info RPC.

Our changes can be tracked at the orchard:#372 PR, and the zsa1 branches of the librustzcash, halo2, zcash-test-vectors, and zcash repositories. Please let us know if you have any comments, and stay tuned for more updates!


We have recently completed going through all the pending comments on the old pull requests for the ZSA ZIPs (namely, PR#628 and PR#649). We have moved to PR#680 for further comments at this stage of the discussion, and we are working on addressing comments there. Most of our recent changes have been towards increasing consistency with existing ZIPs and reducing ambiguities. Some of the changes are as follows:

  • Updates to the txid_digest definition: Some changes were required to the Orchard component of the digest due to the increased size of the notes, and we have also added a section for the issuance digest.
  • Updates to the Action Description: Once again, the note changes necessitated updates to this data structure, which we have now detailed.
  • The derivation of the nullifier for the Split Notes has been updated, based on the discussion with ECC here and here.

The updates to the transfer circuit have also now been included in the ZIPs, and we have also shared a draft document with all the details of these changes and how they fit into the context of the entire circuit. We will include this in the ZIPs as a PDF document once it is finalized.

We have also brought in additional eyes to go over our ZIPs from top to bottom and suggest improvements, so that our document has the highest quality.

The ZSA Team.


Dear Zcash Community,

It was great to meet and interact with the community at Zcon4! We had a lot of fruitful discussions, and we were also happy to present our progress with the ZSA and Asset Swap projects. The links to our talks at the event are linked below, please do let us know what you think!

We are very excited to update that we have integrated the ZSA circuit into the Orchard code, and are now submitting the implementation of the transfer circuit, corresponding to Milestone #6 of our grant! Simultaneously, we have been working on the zcashd client, and have the RPC interface up and running.

Transfer Circuit Implementation

A summary of our changes are as follows:


  • We performed updates to the value commitment and note commitment equations, as well as added support for split notes as detailed in the spec. There were some iterations over the generation of the nullifier of the split note in order to achieve security.
  • We added a few new witnesses to the circuit, namely the asset witness for the Asset Base, the is_native_asset boolean for specifying privately whether we are dealing with ZEC or ZSAs, the split_flag boolean for whether we are dealing with split notes or not, and the psi_nf witness for the random nullifier when we are working with split notes.
  • We added the enable_zsa boolean to allow for pausing of the ZSA functionality in case of any vulnerabilities (along the lines of the enableSpends and enableOutputs flags in Orchard).

The complete set of changes along with their context is documented here.

Link to code that corresponds to the circuit changes. This blob is included within the larger PR#372 that we have on the orchard repository.


The changes here largely add functionality for use in the Orchard ZSA circuit.

  • We added methods to perform Variable Base Signed Scalar Multiplication, since this support was needed in the value commitment calculation in the Orchard ZSA circuit (as opposed to the original fixed/variable base scalar multiplication that was sufficient for Orchard).
  • We added functionality for performing the note commitment in constant time after the changes necessary for ZSA.
  • We exposed functions for various requirements, such as to create curve points from constants, for the nullifier computation in the circuit;

Link to Halo2 PR#769.

Node Wallet State Implementation

We are also nearing completion for this milestone — we presented an early version of the RPC interface for the zcashd client at Zcon4, in the ZSA Interaction Workshop! We will share more details about our work in this direction in a subsequent post, so stay tuned!

Next in line is our implementation of the updates to the Fees ZIP (see ZIPs PR#667 for the specification). We are also working on adapting our work for the zebra client. As always, we look forward to hearing your comments on the relevant pull requests and the forum! We also encourage you to try out the demo as shown on stage in the ZSA Interaction Workshop at Zcon4, and let us know how you like it :slightly_smiling_face:


The ZSA Team.


can you add a timeline? where are you on timeline for completion?

We are on track for ZSAs to be included in the next network upgrade (viz. NU6)! :smiley:


Is there an NU6 delivery timeline?
Is it correspondent to the Halving?
It seems JXG (and myself) are wondering about approximate calendar estimates


Is going to happen with the POS transition

really looking for a date.

Very good!

Just to give an update on this, zcashd is currently on clang 15 and Rust 1.69.0. librustzcash is on MSRV 1.65.0. So that’s no longer a blocker.

1 Like

I can’t make any strong predictions, but the progress on ZSAs is significantly ahead of that on PoS for Zcash, and neither NU6 nor ZSAs are blocked by PoS.


Dear Zcash community,

Hope you are all doing well! We’ve been working hard on both the Zcash Shielded Assets implementation and integration, and the protocol design for building Asset Swaps over the Orchard-ZSA protocol. We’re excited to share with all of you the progress we’ve made in the recent weeks!

We will split our update into two sections, one for each grant that is in progress:

Zcash Shielded Assets

The major areas we were working on are:

Circuit Optimizations

We had shared in the previous post that we had completed the integration of the Orchard-ZSA circuit into the code. This was a first step, with various possible places for optimization. Building on that,

  • We first performed a study to understand which optimizations are relevant and applicable.
  • We optimized the short-range check on 4 and 5 bits.
  • We optimized Sinsemilla hash computation for ZEC vs ZSA: the common prefix inside the circuit is now computed only once.

This entire process occurred with the advice and guidance of the ECC core team. We have integrated these changes into the QED-it/orchard and QED-it/halo2 repositories.

The full details and layouts of the circuits, and the nitty-gritty of how these optimizations have improved the various proof parameters, can be found in this document.

Change of the issuance signature scheme to BIP 340 Schnorr over secp256k1

  • After careful consideration and advice from internal and external contributors, we decided, in the case of the issuance authorization signature, to move to the Schnorr signature scheme over the secp256k1 curve, as described in BIP 340. This change was done to maximize compatibility with existing hardware/software wallets that already support BIP340.
  • The changes have been incorporated into ZIP 227 (ZIP 227: Issuance of Zcash Shielded Assets)
  • The implementation changes for the orchard crate are currently in progress.

Definition of Transaction v6

Since the ZSA protocol is expected to be integrated as part of the NU6 network upgrade, we began to define and implement the transaction structure for this upgrade so that it is compatible with Orchard-ZSA.

  • The expected structure has been included as part of the newly reserved ZIP 230.
  • Of course, this transaction structure is not final, and could change as per the requirements of NU6.

Asset Swaps and beyond

This grant covers the design and implementation of Asset Swaps, and other considerations for the integration of ZSAs into the NU6 upgrade

Asset Swaps

We have presented an initial suggestion for the Asset Swap mechanism. Our goal while coming up with this design has been to minimize the changes needed over and above the Orchard-ZSA protocol.

  • We have published a call for comments on the Asset Swaps design. We have created GitHub Issue #736 in order to discuss this design, so we would love to hear your feedback there!
  • The technical details are in this Google doc.

Testing Framework for the Zebra node

We had presented an E2E demo of the Orchard-ZSA work for zcashd at Zcon4. We are now in the process of porting the necessary changes to the Zebra node.

  • Note that unlike zcashd, the Zebra node does not have the ability to generate transactions.
  • Therefore, in order to support ZSAs, we need the ability to create and verify v6 transactions. To do so, we are creating a testing framework that will allow us to generate v6 issuance and transfer transactions.
  • This framework will use the Orchard-ZSA crate, librustzcash, along with additional new code for managing keys and notes.

The Zebra node

  • As part of the move to Zebra, we are in the early stages of adding TX v6 support for the Zebra node.
  • As it stands, new code related to Orchard-ZSA is being conditionally compiled into the node by using a rust feature flag. This will help in the future with gradually integrating the changes (which touch many different parts of the project) instead of pushing one huge pull request into the code base.

We look forward to hearing what you have to say about these designs and updates! Please feel free to join the discussion.


The QEDIT Team.


Dear Zcash community,

We have exciting news that we would love to share with all of you! As you know, there was a recent strategic change of moving from zcashd to zebra for the core protocol for Zcash. For the ZSA project, this means we are now working closely with both the Zcash Foundation engineering team and the ECC team to make this transition a success.

As we mentioned in a recent Arborist call, to deliver ZSA along with NU6, we have proactively started to work on zebra:

  1. QEDIT is re-implementing the full ZSA functionality in zebra (and stopping zcashd).
  2. QEDIT is developing non-ZSA transaction testing functionality that is currently missing in zebra.

For this, we had to update the project milestones as follows:

  1. We have finished ZSA on zcashd (grant 1 / milestone #9):
    1. Our milestone was “Node Wallet State Implementation on Zcashd” (Link)
    2. We delivered this milestone for zcashd and used it for the ZSA demo at Zcon4 (Link)
    3. There was little work left to merge the code, but we stopped working on zcashd.
  2. We are implementing ZSA for Zebra using funds from grant 2 / milestone #2:
    1. This milestone is now “ZSA Transaction Testing on Zebra”
    2. The original deliverable was “Testnet ZSA Block Explorer support” (Link)
    3. We have dropped this for now and are instead replicating milestone #9 above, but for zebra.
  3. The Fees implementation (grant 1 / milestone #8) is contingent on building missing pieces in Zebra:
    1. We are updating this milestone to be the delivery of all the non-ZSA transaction functionality development.
    2. The affected deliverable is the “Fees Structure Implementation PR” (Link)

We are working within the amounts that have been approved by the ZCG in our grants in order to meet the moving target of getting ZSAs out into the ecosystem rather than increasing the funding.

The QEDIT Team.


How much work has been thrown away with this transition?

1 Like

I’d say the work itself was useful but not some of the deliverables (like zcashd itself).

You can access zcashd-ZSA on the QEDIT github, and you can follow along with Vivek’s demo how to run it (links above). So that work isn’t really thrown away.

This effort was also the fastest path to have a working version that people can use, which is arguably useful work. In the course of that, we understood what to change in librustzcash, and refined the interface to ZSA, etc…

This represents one of the smaller milestones out of the 9 that went into building ZSA. We still keep all the core, such as the ZKP circuits etc.

Hope that helps :slight_smile:


Where (if they exist) are the best explainer sites/ forum threads about ZSA’s for Dummies?

I’ve looked back into the ECC blog to find some original write-ups, but I wonder if anything has changed along the way (and now considering how far technically QEDIT’s efforts have progressed)

1 Like

ZecHub & Shielded Labs ZSA videos on the horizon:

& here is two ZSA talks from Zcon4


how many transactions per second are ZSA/steblecoins expected to handle?

1 Like

Would need to know a lower bound on the size of a zsa tx. Then you could get a theoretical maximum / per block (2MB) / per interval (75) and derive some kind of average.