Hi @zkPete sure, let me give you an overview and general update to the community where things are.
Address Derivation Challenges and Solutions
Over the past month, we have been assisting Ledger with testing, primarily addressing issues related to the wallet (zec wallet) rather than the Ledger app itself. Ledger has specifically requested that we ensure the following scenario is thoroughly covered:
- Current scenario: If someone sent some ZEC from a shielded address (z-address), to a t-address generated from a Ledger account in Ledger Live, Ledger users can’t spend the funds.
- Objective of the Zcash Shielded app : With the Zcash Shielded app, a Ledger user should be able to spend the funds that he received on his t-address from a z-address.
This scenario specifically involves users who received z-to-t transactions using the old Zcash Ledger app that does not support shielded transactions. Our adaptation of Zecwallet appears to support this use case, as we have successfully tested it multiple times. However, the issue lies in how zecwallet and Ledger Live derive new accounts:
- In zecwallet: The account value changes based on user requests.
- In Ledger Live: The account value changes with each new account, and the address value changes with each new transaction per account.
We have tried a test modifying zec wallet to derive new addresses like
xx/xx/account/xx/address
account 0 - address 0
account 0 - address 1
account 0 - address 2
account 0 - address 3
account 0 - address 4
account 0 - address 5
account 1 - address 0
account 1 - address 1
account 1 - address 2
account 1 - address 3
account 1 - address 4
account 1 - address 5
account 2 - address 0
and so on…
We managed to locate the same address that Ledger Live derived. However, it’s not straightforward to find any Ledger Live-derived address because a new address is generated for each transaction. This makes the process of identifying specific addresses very complex.
To facilitate this particular use case, we added a textbox in zecwallet. This feature allows users to:
- Enter a Custom Derivation Path: Users can input the exact path they want to use.
- Generate Multiple Addresses Sequentially: Users can add multiple addresses in a row, such as 10 or 20 new addresses at once.
This change was well-received 
; however, Ledger’s testing team reported significant delays during scanning, with some scans taking up to five hours. Unfortunately, this is a limitation we cannot address, and in such cases, rescanning from birthday is the only solution.
In other testing scenarios, the issues were server-related. To address this, we advised Ledger to switch to a different Zcash server.
Overall, the main issue Ledger is encountering is that zecwallet is not inherently user-friendly. While we have successfully adapted it to work with the new Ledger app, it can still be buggy at times and may require restarts or resynchronizations.
Nano X issues
Ongoing issues with the Nano X unfortunately persist, and as a result, it has been decided to release the app initially without support for this device. However, testing with newer devices like the Flex and Stax has been successful.
New Security Delta Audit
A new Security Delta Audit was requested due to the numerous changes made to the Ledger app since the initial audit. We received the delta audit report yesterday, which identified only minor fixes and clean-up tasks. A new pull request (PR) addressing these issues will be submitted to Ledger this week for a new deployment and final testing. Once this audit is validated, and assuming they can successfully run the flow with ZecWallet, the app will be ready for release.
Overall, we are hopeful that there will be no further blockers this time. As long as the flow can be successfully validated, Ledger should be ready to proceed with publishing.
