I may indeed complain more than anyone in this forum, so what? I never said the opposite, what’s with your honesty question? And why again make this about me, you have some kind of obsession?
I’m not here to play, I’m here to report what I observe as relevant.
I’m not arguing with that fact, and I’m grateful that it is being worked on.
I was just stating it’s a big hole until it is released, and is causing some privacy harms in the meantime until it does get released.
Btw do you know of a rough ETA when you think it will be released?
Thank you again.
I’m not part of the team, I’m just plugged into what is happening. I will need to defer to the devs for timelines.
I want this stuff fixed too, especially T-address rotation.
We are resource-constrained.
Anything requiring the core team is on the back burner, with Zallet and zcashd deprecation being the priority. That includes taddr rotation - not the rotation itself, but a solution to handle shielding so that it doesn’t compromise privacy when utxos are received to multiple taddrs and the user attempts to shield them all / shield them at the same time.
The best means for Zashi users to express feedback, make requests, or ask questions is to provide them directly, rather than downstream in a thread where they might not be seen. We greatly value them.
Thanks for the response Josh, you are doing a great job.
I’ll find a link to the discord and ask this question there too:
I appreciate that the answer may be still that the team is too resource-constrained.
But if the T-address rotation part itself is done - isn’t even releasing that ability alone still better than the current status quo in the meantime even without a dummy proof final shielding solution?
Right now both educated and noneducated users alike must keep reusing the same address (unless that use a separate app) so that’s a worst case scenario…so short of installing a different app, the privacy damage is being done on an ongoing basis right now no matter what, can it be worse than that?
Even if it’s not the final form releasing the feature even allowing T-addresses to be generated would allow users who know to Shield it before creating a new T-address could at least make it so they have the option take advantage of the much better privacy if they know to (without having to resort to installing a different app like they would now to get a fresh T-address). The users who don’t know to do that would basically just be in the same privacy boat as the current status quo anyways.
Maybe I’m missing something there and it could potentially create incompatibility issues down the road, but if not it seems even in a non-final form where the safety guardrails haven’t been finalized it still would allow for the option of immediate privacy improvement regardless.
I encourage you to read Unified Addresses Composition - #45 by nuttycom to understand why we have not yet implemented transparent address rotation. The TLDR summary (even though you should read that whole post) is that at present, there is no way to implement a wallet receiving funds at multiple different transparent addresses while maintaining the unlinkability of those addresses from the perspective of a lightwalletd-compromising adversary. At least, there’s no way to implement it in a privacy-preserving fashion that doesn’t have significant usability downsides (think on the order of it taking half a day to detect received transparent funds.)
Rather than implement something insecure (as other wallets have chosen to do) we have opted not to implement transparent address rotation. At least with the current behavior of Zashi, the user knows that they’re linking their behavior if they reuse a transparent address. We won’t implement a feature that gives users a false sense of security.
We know how to implement the feature that is needed, but this requires a change to the light wallet protocol and for those changes to be propagated throughout the ecosystem. That’s work that’s currently in progress.
Is there a very rough time line you can give where this will be implemented?
If it is going to be still a good time away, I feel like an all caps popup warning when creating a new T-address or a forced delay after shielding everything in an address would still be a good stop gap, or like have the feature behind an advanced mode setting flag. It seems like it can be made clear enough with an obnoxious warning. I think it is debatable that more privacy damage will be caused by leaving how it is now in the meantime. Though I do see maybe queering multiple address balances and stuff presents an issue complicates any stopgap solution too much to be acceptable, idk.
I won’t push further on it in this thread after this post as ive covered all my thoughts on that.
I do still fear we will get a permanent half-baked Ledger implementation though if they start working on it before this aspect and passphrases are able to be added to Zashi.
Which btw, if passphrases were to get added maybe that would allow for a backdoor way for more advanced users to generate blank T-addresses (though I guess it would suffer from the same issues in your linked post, so maybe that can’t happen till after the T-address update)
So, this is something that would have to be discussed with the front-end team. I’ve already done all of the work necessary in the back end to enable the “bad UX” solution, but I did just think of a slight improvement - the way that it would work is that only the “current” taddr (the most recently generated one) for the wallet would be queried for funds “live”, and every other address that the user has generated in the past would be checked for funds at a random time once a day. I could see this being an advanced mode that the user could select.
I’ll discuss this with the front-end folks.
The context here was supporting the spending of funds sent to Ledger from a Sprout address. That’s not at all the same as supporting Sprout in other respects, and only involves correctly handling the vpub_new and vpub_old fields in JoinSplit descriptions. OTOH, I don’t think that’s something that the Ledger devs should spend time on if it doesn’t just fall out of what they are implementing anyway (which it might). I would do it but I’m a perfectionist.
Update: Keystone hardware wallet does support passphrases now for Zcash!
Source: https://x.com/KeystoneWallet/status/1954890560449499428
Noiiiice… Is Shamir (SSSS) working to create a wallet, or only to restore one? I won’t be able to do any crypto stuff this month, but I’m curious about other users experiences with SSSS and passphrases using Keystone, thanks!!
The rat race continues. Deeply disappointed. 
@CharlesGuillemet Two months have passed, have you any updates to share with us? Is the detailed proposal ready to be published? Thanks!
What is the current state of Shielded Transactions with Ledger wallets, e.g. Ledger Nano X and Ledger Nano S Plus?
Is there an up-to-date summary of where things are at and what’s missing?
Ledger shielded functionality does exist but the wallet tooled to use it (zecwallet lite) is not good and you should probably avoid it.With announced deprecation and the open sourcing of the nano models, it’s unclear as to the future of good, long-term support.
Hi everyone, please find below Ledger’s proposal to integrate shielded support in Ledger stack 
Below is Ledger’s proposal to integrate shielded support and provide long-term maintenance and support. Based on our discussions with ZCG, the shielded integration will be funded as a retroactive grant, paid after successful delivery, which is expected by 2026-02-28. After completion, Ledger intends to submit a separate grant request for ongoing maintenance and support.
Project Summary:
This project delivers the development of a new Ledger Zcash Device app supporting transparent, Sapling, and Orchard transactions. It also replaces the current Ledger Live integration to fully support these features. It will enable Ledger users to securely manage, send, and receive both transparent and shielded ZEC directly from Ledger Live.
Project Description
The main goal of this project is to develop a new Ledger Zcash application that supports transparent, Sapling, and Orchard transactions and to integrate it natively into Ledger Live (desktop and mobile). This will fully replace the current Ledger Live integration, which only supports transparent transactions, and offer users a seamless and secure experience for shielded ZEC management.
Ledger Live integration:
Ledger Device app development and security audits:
Maintenance and support:
Ledger users currently lack access to Zcash’s privacy features, as no official Ledger Live integration supports shielded (Sapling or Orchard) transactions. While past efforts provided partial solutions, such as a forked version of Zecwallet Lite, these are not intuitive or production-ready for a broad user base.
Additionally, the current Ledger Live Zcash integration, which only handles transparent transactions, is no longer aligned with Zcash network upgrades (post-NU6) and is planned for deprecation.
By developing a new Zcash Ledger application with transparent, Sapling, and Orchard support, and integrating it natively into Ledger Live, we will allow users to securely manage shielded ZEC from Ledger Live.
This project will:
The primary deliverables of this project will be:
Updated Zcash Ledger App: A fully redeveloped Ledger hardware application supporting the latest Zcash protocol, including transparent, Sapling, and Orchard transactions, and ZIP-317 fees.
Ledger Live Integration: An updated integration in Ledger Live (desktop and mobile), offering complete management of shielded and transparent ZEC, including sending, receiving, memos, and advanced controls.
Public Release and Documentation: The updated app and integration will be distributed through official Ledger channels, with clear user documentation.
Dependencies:
Technical Approach:
Upstream Merge Opportunities:
We will directly contribute to Ledger’s official repositories such as GitHub - LedgerHQ/app-zcash: Zcash application for Ledger devices and GitHub - LedgerHQ/ledger-live: Mono-repository for packages related to Ledger Live and its JavaScript ecosystem. .
Where applicable, we will coordinate upstream contributions or improvements to Zcash light client components (e.g., lightwalletd / zaino) to ensure proper integration with Ledger Live. We also plan to make improvements or corrections to WebZ.js, particularly to enhance its stability and ensure a clean separation between transaction construction and signing, which are critical for Ledger Live desktop integration.
Hardware/Software Costs (USD): $0
Justification: Existing hardware, software licenses, and infrastructure are covered by Ledger.
Service Costs (USD): $0
Justification: No additional external services required beyond the scope of compensation.
Estimated Compensation Costs (USD):
$400,000
Justification:
$300,000 for development, integration, QA, and security audits (Ledger Device app + Ledger Live)
$100,000 for 12 months of maintenance, updates, security monitoring, and community support
Total Budget (USD): $400,000
Previous Funding: No
Other Funding Sources: No
Implementation Risks:
Potential Side Effects:
Success Metrics:
Shielded Integration (Retroactive Grant)
Total Estimated Cost (Retroactive Grant to ZCG upon successful delivery): $300,000
Ongoing Maintenance and Support Agreement (Starting 2026-04-01)
Expected Completion Date: 2027-03-31 (12 months maintenance: Feb 2026 → Mar 2027)
Deliverables:
12 months of maintenance, upgrades, issue triage, and community support
Estimated Amount (USD): $100,000
Project Lead:
Name: Victor Forgeoux
Role: Product Manager - Coin integration
Background: >3 years of managing device applications for coin integration as Product Manager at Ledger.
Responsibilities: Define the specifications and coordinate cross-functional teams (engineering, security).
Additional Team Members:
what happens after the 12 month maintanance? they stop to support the app unless they receive further funding?
I personally would really appreciate shielded transactions on ledger,yet I think its not our job to pay them to do their job and than have to pay them to keep supporting it.
Can you please explain which depedencies on lighwalletd / zaino? Lightwalletd is going away, why not focus just on zainod?
Does the cost of this grant include funding for the third party audit? What is the average cost of such an audit and how long does a typical audit take?
This grant estimates a completion date of 6 months from now, if there are delays with zcashd deprecation and or NU 6.1 and NU 7.0, will that extend the estimates? Historically Ledger grants have taken 3x as long as the initial estimates.
With this time estimation, please consider to add also the implementation of ZSA support during the year of maintainance or if delivery date will be delayed.
Thank you @CharlesGuillemet ! I appreciate the detailed proposal and fully support this effort. This will be very helpful for shielded adoption and the overall growth of Zcash. Let’s make this timeline happen.