Official Shielded Support for Zcash In Ledger HW Wallet

Dear Zcash community,

I present here our proposal to finalise the last steps towards public release of a Zcash Ledger App with Sapling support and 12 months of maintenance.


Official Shielded Support for Zcash in Ledger HW Wallet

Applicant name:


Pitch: A one-liner elevator pitch version of your proposal

Official Public release of Zcash Ledger app w/ Sapling support and 12 months of maintenance.

Total Request (USD):

$101800.00 USD

Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?


Please provide details:

Zondax developed a Ledger app with Sapling z-address support as part of a Zcash Foundation grant. However, the grant didn’t cover pending steps that are required by Ledger for the official release. This proposal aims to complete this integration.

We have received funding for the development of the application from ZF but it didn’t cover the work that is being described in this proposal.

Are you seeking or have you received funding from other sources for this proposed project?


Applicant background:

Experience and repositories

Zondax is a growing and distributed team with experience and projects for more than 50 blockchains. Zondax has been contributing to the Blockchain ecosystem since 2018-2019. The team has received and completed a large number of grants and currently maintains most Ledger apps for the ecosystem (+30). Our team includes experts in most blockchain aspects, cryptography and programming languages.

Most of our contributions to the blockchain ecosystem can be found in our GitHub organization:

We have experience in the review and release process by Ledger and have a streamlined workflow to simplify this. Zondax has successfully delivered over 30 Ledger Nano App projects and 4 Ledger Live integrations that are either publicly released or currently under security review.

Legal structure

Zondax AG

Dammstrasse 16

Zug 6300


UID CHE-491.796.576

License: Zondax source code will be delivered under Apache 2.0 License and/or MIT License (this is also required by Ledger). Deliverables will include source code, unit tests, continuous integration, and integration tests.

Description of Problem or Opportunity:

Zondax developed a Ledger app with Sapling z-address support as part of a Zcash Foundation grant. More recently Zondax upgraded the app, improving its application structure, refactoring it and adding support for new Ledger Devices (Ledger Nano S plus) and completed integration with a fork of the Zecwallet Lite Desktop wallet for demo and testing purposes.

We’ve been diligently working on this application for a while now, encountering various obstacles and external blockers along the way. We are currently at the final stages of preparing for the official public release, and we are seeking this grant to complete the remaining tasks that have emerged due to recent updates in both Ledger’s requirements and the latest changes in Zcash.

Proposed Solution: Describe the solution at a high level.

Our main goal is to help make the Zcash Ledger application with shielded support publicly available through an official release by Ledger. What we already have accomplished:

To accomplish this we need to add support to ZIP317 fees, have a security audit executed by a third party partner approved by Ledger SAS, and demonstrate we will maintain the application for at least 12 months.

Solution Format: What is the exact form of the final deliverable you’re creating?

Zondax source code will be delivered under Apache 2.0 License and/or MIT License (this is also required by Ledger). Deliverables will include source code, unit tests, continuous integration, and integration tests.

Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!

  • Agile methodology + streamlined coordination process with Ledger towards public release.

  • CI testing and continuous integration.

Phase 1 - Final steps towards public release

M1 - Adding support for ZIP317

We need to update the embedded app and our fork of Zecwallet Lite to support ZIP317 fees. ZIP 317 was adopted after we developed the embedded app and forked Zecwallet Lite. Without this work, Ledger won’t be able to test the new embedded app (because the shielded transactions will probably not get mined).

M2 Security Audit by one of Ledger’s approved audit partners.

We will coordinate an external security audit, and execute any relevant fixes. The external auditor will be selected from a list provided by Ledger SAS.

Phase 2 - Maintenance and Support

M3 - Technical support & maintenance of embedded Ledger App for 12 months

During this period we will maintain the Ledger App covering the following areas:

  • Ledger SDK or firmware upgrades that affect the application

  • Device support for Ledger Nano S Plus, Nano X and Stax

  • Security fixes related to Ledger SDK layers

  • Repository and issue monitoring and triage

  • Resource availability (ensure internal training in your chain, rotation of resources, etc.)

  • Analysis and early warnings in the case of known security issues that may affect the application

  • Early warnings and prioritization in the case of urgent issues or vulnerabilities

  • Periodic coordination with Ledger

Note* This does not include development of new features or upgrades to new protocols or the cost of additional security audits.

We will also take responsibility for maintaining our fork of Zecwallet for 12 months after we submit the application to Ledger. While our team would be interested in continuing to maintain the fork beyond this period, that is not within the scope of this grant. By maintaining the fork for 12 months, the team is committing to ensuring that the modified version of Zecwallet Lite Desktop continues to work properly and can be used with the Ledger Nano App during that time.

M4 Documentation of the integration to support other Zcash Desktop Wallet teams

We want to ensure that other desktop Wallets (eg. YWallet, Zingo ) have the opportunity to add Ledger compatibility. We will provide a javascript integration library, and once we have an official release we will concentrate on documenting the process via blogs to allow other developers to understand the integration process. This will facilitate further integrations in the ecosystem. Deliverables:

  • At least x2 blog post explaining step by step the integration process

  • 1 x javascript/typescript integration library

  • Support via slack channel for up to 60h

Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?

This proposal aims to reduce our dependencies on external organizations. Additionally, by adhering to Ledger’s recommendations and conducting an external audit, we expect to expedite our review and release processes. While we still rely on Ledger for the release, we are confident we can complete this project.

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?

We already possess extensive experience in developing apps for Ledger. In the past, one of the obstacles we encountered in achieving an official release was our dependence on an external party to merge changes on the web wallet side. Fortunately, we no longer face this hindrance as we will be using our own fork of Zec wallet, eliminating this dependency.

While we still rely on Ledger for the release, we expect to significantly reduce our risks by leveraging our existing relationship with them and by taking over the full integration process.

Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.

The community has been expecting this for already long time, it will bring numerous benefits.

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?

Official public release of the Ledger App Public release of the Ledger App (Nano S+, Nano X, Stax) , SDK and firmware upgrades of the app during the maintenance period.

Hardware/Software total budget:

$0.00 USD

Please provide justification for the total hardware/software budget:

Only time and materials for the development have been considered. Zondax has already provided its employees with licenses, software and hardware.

Services total budget (cloud, hosting, etc.):

$0.00 USD

Please provide justification for the total services budget:

Zondax AG runs its own infrastructure in a Datacenter in Zurich. The costs of the infra is already considered in the project/hourly rate.

Compensation total budget:

$101800.00 USD

Please provide justification for the total compensation budget:

Services include implementation, development, integration, infrastructure costs, external audit costs and coordination. Zondax AG will receive all payments and pays its employees on a monthly basis.

Do you require startup funding?


Milestone 1 - estimated completion date:


Milestone 1 - USD value of payout upon completion of deliverables:


Deliverable 1.1

Update of Zecwallet Lite and Zcash Ledger App to support ZIP317 fees.

Milestone 2 - estimated completion date:


Milestone 2 - USD value of payout upon completion of deliverables:


Deliverable 2.1

Zcash Ledger app with Sapling support including the necessary fixes resulting from the audit

Milestone 3 - USD value of payout upon completion of deliverables:


Milestone 3 - estimated completion date:


Deliverable 3.1

12 months of maintenance of Zcash Ledger App

Milestone 4 - USD value of payout upon completion of deliverables:


Milestone 4 - estimated completion date:


Deliverable 4.1

x2 blog post explaining step by step the integration process

Deliverable 4.2

1 x javascript/typescript integration library

Deliverable 4.3

Support via slack channel for up to 60h

Total proposed USD value of grant:

$101800.00 USD

How was the project timeline determined?

Timeline has been determined based on previous experience with development, effort estimation and experience of the team. Given that we do not know the initial start date of the proposal, timeline is approximated. We will be able to work on some of these Milestones in parallel (support for integration of other wallets can start as soon as the app has been submitted to Ledger) M1 is expected to be completed in 2-3 weeks M2 is expected to be completed in 3 weeks M3 consists of 12 months of maintenance work M4 will take between 6-8 weeks.

Application submission date:



Better than nothing, of course no orchard support. We will see it in 2028. Maybe

I apologize that Orchard is not included, as many in the community would like. However, there is a specific reason for this, and it is not of a technical nature. Orchard comes with a BOSL license that conflicts with Ledger’s standard license requirements. Adding Orchard to the application would further delay the public release. Our goal is to address these license conflicts in the coming months to unblock Orchard’s development.


The problems of BOSL License strikes again :smiley:


hey, no Ledger Nano S Plus support?

1 Like

Yes Nano S Plus is included! That’s a typo, sorry, there is no Nano Plus → It’s Nano S Plus, also mentioned in some cases as Nano S+

1 Like

And Nano S (the previous model) is supported?

If ECC were to change the license, would you support it? Is that the only blocker?


Unfortunately not, shielded transactions require certain pieces of code that make the app size bigger and it does not fit in the previous model of Nano S.

Hi @joshs, assuming Ledger SAS confirms that they have no issues accepting the BOSL license when submitting the app for public release (which will eventually be integrated into Ledger Live), then we would be eager to quickly extend support to Orchard, ensuring that the community can also take advantage of it.

Given the project’s extended duration without a successful public release, we’ve opted to maintain a restricted focus on Sapling to minimize the introduction of any additional elements that could potentially cause further delays.


I’m worried about the choice of wallet. ZecWalletLite seems quite abandoned. We currently have several threads with users with funds stuck on ZWL. It’s not sure whether all of its features depend on a custom lightwalletd infrastructure which you will have to maintain as well.

Can you elaborate more about why you wish to persue development on that wallet instead of its better maintained cousin, Zingo?


I’m sorry I will have to decline then. I only have a nano S and I don’t want to buy a new device just for zcash. Besides, hanh’s code supports nano S. Why don’t we use that?

Short version, if I remember correctly:

  • Ledger does not want an app registered by an individual, such as Ywallet (reasonable imho)
  • ECC/ZF do not want the responsibility of the Ledger app (reasonable imho)
  • Zondax does not want to maintain / be in charge of an app they have not created (reasonable imho)

If there’s someone to blame imho, it’s Ledger. They let users get ZEC funds stuck, with no warning of any sort or anything. So now ECC/ZF has tried to make something happen (thanks!), and Zondax will work on that thing (thanks!).

I do not see this as a long term solution. At this point I’d recommend a DivestOS (re-lock bootloader!) with only Ywallet installed, which can be achieved reasonably cheaply. It can also be improved by switching to GrapheneOS/Pixel phone, only working offline and signing with QR code, etc.

1 Like

Who would you recommend this to?

I understand ZF not wanting to do support but why don’t they hire someone to do that then? Instead of going for an inferior solution with zondax. I mean, that’s the point of having a foundation…

I’d recommend DiverstOS, or ideally (but more expensive hardware) GrapheneOS, as a Zcash wallet to any “advanced” user at this point.

Ledger and Trezor are great, but they also have important issues. Trezor does not really protect the passphrase from offline attacks (very well protected on an encrypted and locked Android device). As far as Ledger is concerned, it is not clear if they can be trusted, and their latest firmware is problematic to say the least. Now, both devices are locked ecosystems where each respective company has to approve apps before they can be installed on their devices. And also both devices have an important flaw: buying one immediately puts you in the list of crypto owners (who remembers the lovely Ledger hack of all of their clients…), and that’s even if you can afford such device (not going to find a lot of those in developping countries). Long term thinking = Hardened Android.

Android has a larger attack area but that’s mostly when they are powered-on and unlocked. If you keep one shutdown and encrypted, even older devices remain secure. We would struggle less and move more quickly as an ecosystem if we would develop more hardened apps for Android instead of waiting for company approvals or even struggling with their limited computing and memory capacity. Ywallet has shown the way on this, but we need to work together to develop protocols such as for offline signing (qr codes, etc).

1 Like

oh, I got scared! for a moment I thought you were suggesting this for any user :joy:

There’s is plenty of peer-reviewed literature of PoCs describing how to use offline devices as HW wallets. I don’t think that’s under discussion here. Also those papers don’t address the problem of the offline cellphones not being devices which have a threat model that considers a use to the high-risk level of a hardware wallet.

Here’s the paper from 2021 that describes the Android security model

that’s why hardware wallets are important, because they are built for that purpose only.

I do agree on the lack of openness of Trezor and Ledger being a problem. All crypto projects should form an alliance to build Open Hardware and Open Source hardware wallets. Trezor and Ledger are probably backed by corporate money and they are legally bound to ultimately defend the interest of their investors, not the users’.


Well, ideally I believe this is where we should be headed for a wider public, yes. Although I believe I understand it reasonably well already, I’ll have to review the Android security model in more detail, but I am certain more focus should be put on Android apps - as in more security features for those (offline signing, sending txs through Tor integrated in the app like Trezor does, etc). In my opinion the security of phones is underestimated, particularly when they are put in their “safest” configurations, such as Lockdown on iOS or installed with security/privacy Android versions such as GrapheneOS or DivestOS.

This can be though about in many ways favorable to secure Android wallets. Notice how xkcd 538 wrench attacks are increasing? What about journalists funded by crypto being searched, what happens if they have a crypto hardware wallet? What about nomads going through airport xray machines with database of signatures of various items, such as those wallets? Don’t believe this USD$10,000 limit to declare the cash we carry will not eventually apply to and/or bring suspicion to hw wallet owners? Let’s think ahead a bit more. Sure, you could add an account on a Ledger or Trezor using a separate password providing plausible deniability, but with such device you still clearly own crypto and can ever more easily become a target.

With Android it’s impossible to know just because of the hardware, and apps can easily be hidden in various ways. Hardware crypto wallets are just not going to be an optimal safety for many important scenarios. That is not to say we should start ignoring those wallets, rather that we should give more attention to the safety features of Android apps. The fact that only Ywallet is providing the latest update of their wallet on GitHub/F-Droid is rather disappointing, to say the least. Because indeed, not having Google Play is one way to reduce both attack surface as well as surveillance.

1 Like

FYI, there is also this version:


FYI, there is also this version:

They won’t listen to you because you’re one of the few that knows wtf you’re talking about. It’s pretty obvious you’re being blackballed by Zcash Foundation, ECC, et al.

1 Like