IMO, we need to work with organizations that grow the ecosystem and refusing to work with Ledger for whatever principle is counterproductive. No user will bother understanding why we don’t partner with Ledger. They will say : “What is this coin that is not even supported by the most popular Hardware Wallet? They cannot be serious.”
7 Likes
Just to clarify that I did not in any way say blocklist Ledger forever. Also, my previous post was edited before hanh posted his reply. Ledger needs to show that they are a reliable partner before ZCG invests any significant amount of ZEC for Ledger apps.
1 Like
I understand that. I just disagree with it. Besides, the plan seems to not involve any funding from ZCG.
1 Like
Well precisely. It’s not because the protocol documentation wasn’t clear about the issue they had.
I know what issue that was, and I have a very good idea of exactly how much effort it should have taken for competent programmers to implement the fix (we were prepared to help them at any time). That it didn’t get fixed for so long was not an engineering problem. It was a “we don’t care” problem.
I’m in that Signal group. I must be careful not to reveal information from it that I haven’t been given explicit permission to reveal. However, it would be reasonable to infer something from the fact that being in that group has not altered the opinion I expressed in my previous post in the thread.
Did you do so? Unless I missed something, it looks like they didn’t respond.
6 Likes
I believe you’re in the Telegram group, not the Signal group I mentioned. Though perhaps there’s another Signal group I’m not aware of.
I did, but they haven’t posted yet. We’re still working out the details of the proposal, but I’ll encourage them write a post here soon.
1 Like
Even if you can afford multiple hardware wallets, the current situation is still not great; the fact that the Keystone wallet moved ZEC into their “cypherpunk” firmware which only has ZEC, BTC, and XMR support means that you can’t use the same device to manage whatever other currencies you might hold.
8 Likes
Sorry, but this is wrong, Zec is currently supported on both multi coin and cypherpunk firmwares.
See Keystone
1 Like
WTF?!? I bought and used the multicoin firmware from the day one of ZEC integration, then I passed some weeks later to the cypherpunk firmware, but I didn’t realize that they moved the app and not copy it such as the Bitcoin one! 
Sorry for my wrong statement and thanks for correction.
4 Likes
Hi Zcash Community,
My name is Charles Guillemet, CTO at Ledger. As a strong advocate for privacy, I want to give the Zcash community the recognition and attention it truly deserves.
Ledger devices have supported Zcash for years, thanks to third-party app development on our open platform. However, one key element has been missing: easy access to Zcash’s shielded transactions within the Ledger ecosystem.
We’ve heard your requests and understand the current limitations. To address this, Ledger is taking the initiative to upgrade the Zcash app and Ledger Live support, bringing full support for shielded transactions directly into Ledger Live.
Soon, you’ll be able to:
- Sign shielded ZEC transactions with the security of your Ledger device.
- Manage shielded ZEC seamlessly within Ledger Live.
This update will offer the best in class way to manage your shielded Zcash, giving Zcash users the highest level of security and privacy. It will also eliminate the need for third-party wallets to access this essential functionality. We believe this will be a significant step forward for Zcash users in the Ledger community and a meaningful boost to Zcash adoption overall.
We’re preparing a detailed proposal and will share it with you soon.
Your feedback and support are invaluable as we work to bring the full privacy features of Zcash to your Ledger device, natively and effortlessly within Ledger Live.
More updates coming soon
24 Likes
Excellent news 
4 Likes
Great. But has Ledger fully solved the issue of transparent $ZEC stuck on Ledger device?
4 Likes
Thank you @CharlesGuillemet
Those of us supporting Zcash believe in the pure ethos of crypto - enabling the individual. Privacy is upstream of freedom, safety & a host of other individual rights.
With AI coming on the scene & Zcash being the Apollo project for private money is at a pivotal moment. The tech side continues to pull forward wizardry from the math gods. UI that keeps the users safe while allowing shielding is what we desperately needed.
What you’ve made a priority will be a key in tripling our shielded pools. Can’t thank you enough.
5 Likes
I just spoke to Ledger and they confirmed that a fix for the issue where ZEC transactions with Sapling inputs get stuck should be ready next week. After that, they’ll need some time for testing and expect to release it by mid-July. This will resolve the issue for some users.
However, a similar fix will also be needed to address the issue affecting ZEC transactions with Orchard inputs. I don’t have a timeline for that yet, but I’ll continue following up with Ledger and will update the community as soon as I have more information.
13 Likes
That’s totally awesome.
I really hope it will work with third party apps like Zashi. If it does, and also supports hardware wallet passphrases (which Keystone doesn’t currently support for Zcash), it will steal a lot of Keystone’s thunder.
1 Like
I’m really perplexed why this should have been a problem for so long, or why Ledger are still saying they will only ship a partial fix, with no timeline on a complete (i.e. adequate) fix. To fix what I understand to be the relevant issues, the wallet doesn’t have to do anything other than parse transactions and compute their txids properly.
Note that payments to a transparent address from shielded funds are not an unusual case. That’s what a properly functioning shielded-storage wallet always does when sending to a transparent (non-TEX) address. No other wallet has a problem with this; it should be considered a failure of basic functionality needed to be a Zcash wallet.
Let me try to explain the issue. A transparent input is represented as a pointer to the corresponding output (UTXO), i.e. a transaction id and output index. You can’t even verify that a transaction balances without looking up all of the UTXOs in the transactions where they were created. (Obviously you could just assume that it does because it was accepted by consensus, but that doesn’t work for mempool transactions, for example.)
For shielded inputs, you don’t need to do this. In fact you can’t know which transaction a given shielded input came from. So you just don’t do this lookup. You have all the information needed in the current transaction you’re looking at, in the valueBalanceSapling and valueBalanceOrchard fields. It’s less work, not more, assuming you can parse the transaction at all.
If we were talking about something more obscure like Sprout inputs, I could maybe understand it? That case is slightly (not much) more work, because you have to account for the vpub_old and vpub_new fields in each JoinSplit description, rather than just a single balance field for each protocol.
I seem to remember that another part of the issue (which might already have been fixed, I don’t know) involved miscalculating the txid of the transaction that produced a transparent UTXO, when it is spent by a transaction of a different version and/or consensus branch ID. I don’t understand why this isn’t completely straightforward. ZIPs 243 and 244 are clear: which algorithm is used to calculate a txid is determined by the version of that transaction. (How could it possibly be otherwise? The transaction that will spend the input has not been created yet.) Everyone else gets it right.
Sprout will go away if ZIP 2003 is adopted in NU7. However, at the same time ZSAs will be added. Will Ledger break again for transactions that have issuance or burns, or that have some other relationship between the tx that created a UTXO and the one that spends it? Will it also break for NU6.1? Have they really fixed the bugs or just worked around them for a few of the more common cases? Who knows?
Honestly I don’t know what to say about a wallet developer that still, in June 2025, can’t provide a timeline to implement basic functionality to function correctly with an upgrade (NU5) that activated three years ago in May 2022.
17 Likes
All fair points, but when it comes to hardware wallets, currently we’re between this and Keystone. The latter with a broken (as far as Zcash is concerned) implementation of SSS making it pretty much useless for anyone taking the security of their passphrase securely. Go Ledger!
Thanks for your response, @daira. This was helpful information. After you posted it, I forwarded it to Ledger. They just got back to me and said they’ll implement a full fix for both Sapling and Orchard. The update will be released in mid to late July.
12 Likes
Thanks for following up with them! Im glad they increased the scope of the fix. Any chance they will consider making sure Sprout is supported as well?