Add Orchard to Zecwallet Mobile and Desktop Apps

Applicant background

Zecwallet Fullnode and Zecwallet Lite are 2 of the popular full node and liteclient wallets for Zcash that have full support for Zcash , including shielded address (sapling support). They are fast syncing and work reliably well.

Description of Problem or Opportunity:
The Zcash protocol recently activated NU5, which has the Orchard pool. Orchard is a big step forward for Zcash, and should have support within Zecwallet.

The Orchard pool is designed as a separate shielded pool from Sapling, and so requires a significant amount of wallet work to support sending transactions to and from the Orchard pool.

Proposed Solution:
Zecwallet will implement full support for the Orchard shielded pool in its various wallets and SDKs. This includes full support for sending and receiving shielded Orchard funds in a way that works across all wallets.

Additionally, we’ll implemented experimental support for using Zebra, the Zcash Foundation’s full node client as a backend for Lite wallets using LightwalletD.

Solution Format:

  • Zecwallet Fullnode

    • Add support for Unified Addresses
    • Add support for zcashd v5.0.0 mnemonic wallets
    • Add sending and recieving funds from Orchard
  • Zecwallet CLI client and SDK

    • Lite client support for Orchard
    • Full Orchard pool support to send and recieve funds from the Orchard shielded pool
    • Add Unified addresses
    • Blazesync for Orchard, so that orchard blocks are synced at full speed.
  • Zecwallet Lite mobile and Desktop Apps

    • UA address support in UI
    • Send / Recieve orchard funds
    • Ability to shield funds to Orchard pool from transparent addresses
    • Send and receive v4 or v5 transactions, depending on the reciever
  • LightwalletD

    • Full support for Orchard actions
    • experimental support for using Zebra as a backend, deployed in production

Technical Approach:
Zecwallet uses its own SDK (called zecwallet-light-cli), which is compatible with the ECC SDK, but features the “blazesync” sync algorithm that syncs the Zcash blockchain significantly faster. The main part of this grant is adding Orchard support to the Zecwallet lite SDK, including extending blazesync to the orchard pool, adding support for unified addresses and ability to decode v4 and v5 transactions

This SDK is then used across the mobile and desktop apps.

The UI will also be extended to support Orchard features like the unified addresses and the separate Orchard pool.

There are no significant dependencies. All work can be done by the Zecwallet team.

There are no substantial technical or project risks here.

Unintended Consequences:
One of the big challenges of this work is that UI complexity will increase because of the additional shielded pool, and will make UX worse for a while.

This could lead to user confusion and make Zecwallet and Zcash harder to use. Although the use of Unified Addresses will mitigate this substantially, for a transition period (while all Zcash users move over to the orchard pool from sapling), there will be increased complexity and confusion in the product.

Evaluation plan
Success criteria is:

  1. Zecwallet desktop and mobile apps have support for
  • Unified addresses
  • Send and Receive funds from the orchard pool.
  1. These features are deployed to 100% of mobile and desktop users of Zecwallet.

$ 114400

  • 1 person working full time for 13 weeks (@ $200 / hr) = 200 * 8 * 5 * 13 = $104000
  • 1 person working part time (10%) for 13 weeks (@ $200 / hr) = 200 * 4 * 13 = $10400
    Total = $114,400

All cloud services (hosting for LightwalletD) and hardware costs are included in the budget


Glad that you continue to work on Zecwallet.

I still feel however that it would be better for Zecwallet publication authority to be distributed among many trusted Zcash community members instead of with just one party. We certainly did not want what has happened in the last few months to repeat in the future.

I also want to point out that there is a community effort to continue the work on Zecwallet which started after Aditya informed the community that he will stop working on it post-NU5.


I am very grateful that Zecwallet came when it did, and it has been instrumental in onboarding many many mobile users to Zcash. It will always feature prominently in the early history of Zcash.

But… it feels to me that @adityapk00 's heart isn’t in it any more, based on recent announcements about moving on to other things. I think there is a risk that we fund this for $100k plus and then have another announcement that it will be abandoned.

Also, in my opinion the app is starting to look quite dated and I’ve experienced quite a few bugs with it and have moved on to Ywallet at this stage. I think Ywallet also looks dated from a UI perspective but it has been more reliable.

I’d be more in favor of the community effort to continue Zecwallet, I’d love to see @adityapk00 as a part time advisor to that initiative.

Also I think $1600 per day for a dev on this app is way too much, I may think differently about this is if this was a more modern, slick, reliable app but that’s not the case.

A no for me.


I vote for the proposal if @zancas & team is involved, as they are actively spending time on this.


Hello everyone!

First off, we at Zingolabs want to emphasize that we’re glad that end users of Zecwallet have a functioning app! However, because the following is likely directly related to Aditya’s proposal, and because of the speed at which this topic is moving, we wanted to make a record of our thoughts as well as some facts at the present time.

We also plan to submit a grant proposal within the coming days, and we are now working on closely related code. We understand that, due to a policy of a week-long waiting period for public comment, Aditya’s review will not be granted funding until, minimally, the ZCG’s next meeting in two weeks time. By that time we hope to have both submitted our grant, and let at least the minimum of one week for public comment and discussion elapse so that the committee and the community at large can have informed discussion.

We were motivated to take on the project of using the abandoned Zecwallet suite to build new applications of the Zcash technology, even before @adityapk00’s May16 retirement announcement, in part because we’re users, and in part to update the codebase, which had not been updated since v1.7.7 in October aside from a license update.

The code that we wrote and merged before the NU5 activation created a functioning zecwallet-lite version which we announced here. What this means is that while zecwallet-lite users experienced a 7-day-loss-of-service, we had a published fix.

More, when release 1.7.13 of zecwallet-lite-cli occurred it was derived from our solution (see Aditya’s fork), two hours after our fix was mentioned. We’re aware that this might have been the expedient solution or was the “right thing to do” from the perspective of getting a working app in front of the users ASAP. That having been said, there was never any attempt to communicate with any of us on any channel, at any time, about this fix.

We won’t say why that fix was not made available to users for 7 days, or how these changes were adapted for their codebase, but we want to note that Aditya proposes to dedicate 10% of his time to this project.

After these events, @Zancas proposed to Aditya that he delegate app publication authority to us. Following this exchange we all agreed it sounded like Aditya was uninterested in collaborating with us, though he encouraged us to develop on our own forks.

We think this is far less than ideal, because we believe we have a clear interest and detailed strategy for maintaining, and profoundly improving on this platform to which he has been a core contributor. We feel the facts we have outlined here shows that there would very likely have been no outage if we had held the keys on May 30th.

We will be submitting a grant proposal, based on our work and the attributed work of others, and our preferred mode is collaboration.

We love open source, and it’s great that we can build on top of the substantial codebase that @adityapk00 built, which in turn was built on top of the codebase that @str4d built on top of the codebase that the ECC built… and we look forward to continuing this work.


Just to clarify your misconception, there is no policy to delay funding for grants. The ZCG usually allows grant applicants to gather more supporters for two weeks or more in case there is no significant activity on the grant before the ZCG decides on the funding.

We do have a 7-day period between when the grant application is made and the vote is made.


We do have a 7-day period between when the grant application is made and the vote is made.

Ah, yes, this is what we were thinking of. Thank you for the clarification.


@adityapk00, On June 15, the @ZcashGrants committee held an off-cycle meeting to vote on this proposal due to their being a high level urgency around Zecwallet implementing full support for the Orchard shielded pool in its various wallets and SDKs. The committee unanimously voted to approve this grant.


This is fantastic news! Thank you ZCG and the broader Zcash community for your confidence in Zecwallet!

We will begin work immediately!



Looking forward to collaborating, here’s code that implements import/export and production of orchard keys, for your reference:




I’m excited for @adityapk00 continuing. I’ve been following in some of his footsteps recently and realizing what a substantial contribution he has made. I also would like to see more community involvement, distributed support, a plan to pass the keys to a wider group of “trusted” contributors. I’m also sympathetic to the sentiment that ZWL (and YWallet) could look hotter and be a bit more … stable, less buggy.

While my suggestion that the entire Zcash ecosystem (including zcashd and zebra) could be in a multi-package repo was not well received for fairly obvious reasons, I still think there is a case for bringing together more of the Zcash UI Universe into a single trunk so it’s easier to work on different parts with a consistent view of the code, a consistent development environment, easier sharing, have atomic changes across packages, more easily integrate downstream dependents … I envision a future where building new wallets on the ZWL foundations is a lot easier. In particular, i would like to see web browser return as a first-class target alongside electron, android, iOS. If it was trivial to “npm install zwl” and use the installed client in a browser, a world of possibilities would open up. Browser extensions and non-custodial web wallets come to mind. With a reusable client, i know we could make several beautiful wallets using frameworks like material-ui and ionic. The “UI” part could basically be a skin to the underlying lightwallet foundations that “normal devs” could work on.

These are big topics that are mostly orthogonal to the OP here and I’m probably too long-winded already. I’ll probably get around to creating a top-level post on the ZUU idea (Zcash UI Universe, ZecWallet). I guess the takeaway for this thread is 1) Dont forget about WEB 2) Do we want to think about unifying some of the ZW trunks into a single trunk for the reasons stated above?

I started to play with the idea of a metarepo with a devcontainer here:

Anyways, i look forward to Orchard in ZWL and continued collaboration with zingolabs and others!


when is it planned to release the official zec wallet with all the network capabilities and support for all addresses? zecwallet proved to be weak and not reliable on the distribution of nft :neutral_face:

zingolabs is working on it’s own version as mentioned here:


We have a new beta release (v1.8.0-beta1) of Zecwallet fullnode with Orchard support.

New in this release:

  • Add unified addresses
  • Support for sending and receiving funds into the orchard pool via UA
  • Assorted bug fixes

Limitations of current beta:

  • zcashd needs to be started manually (It is included in the distribution)
  • User needs to manually run zcashd-wallet-tool to backup their secret phrase before they can use it.

As always, please file bugs or feature requests. We’ll work on adding lite client support next.


Running a separate zcashd with new beta frontend works! Thank you. Here are somethings that came up:


should say: UA or Z or T address


Hitting the receive tab reveals UA addresses, but they cut off the ends in the display


Sending UA → UA (Full privacy mode) works, but when going back to the dashboard, you see (change) as an address. This may be as required, not sure.


Zecwallet Fullnode v1.8.0 with Full Orchard support is now available.

  • Full support for Orchard pool (send / receive)
  • Support UAs for sending / receiving
  • Allow moving between pools using configurable privacy.

Thank you to everyone that beta tested and filed bugs and provided feedback.

The Lightwallet beta with Orchard support should be available soon for testing.


How long should it be stuck on the loading screen for a new node?

If you just started this node, it can take several hours or days to sync the Zcash blockchain. Please wait for the sync to finish (since this is a Full Node) before you can use the wallet.

I’d recommend running zcashd in it’s own window so you can track progress.


Fantastic, a big moment!

Note: The .deb installer doesn’t seem to be built for Debian Bullseye (the required dependencies are only up until buster). (now fixed in later release)