All ECC teams focused on wallet performance

Does this include fixing the issues with ledger?

When will the release be available from the repository?

If you’re on Debian/Ubuntu, you can build directly from source as documented here: Building Zcashd & Zcash-cli on Debian/Ubuntu — Zcash Documentation 5.2.0 documentation

Just makes sure you select the correct release branch:

 git clone
 cd zcash/
 git checkout v5.3.0
1 Like

Not that I’m aware of. Ledger doesn’t depend on ECC mobile SDK or improvements made to shielded transactions on zcashd as Ledger doesn’t support shielded transactions.

I have personally been affected by issues with Ledger since the NU5. I understand that this can be frustrating as I also couldn’t access ZEC stored with Ledger hardware wallet. My suggestion is to reach out to Ledger directly and explain your situation through

Reminder: Never share you seed/recovery phrase with anyone especially with those that claim to be from official supports team

If there’s any lesson to be learned from this experience, never store too much of your money in places you might lose access to.

1 Like

There was a patch applied to ledger desktop live about a month ago but I’m not sure if applies here

Do you mean it will take 12h to sync a year’s worth of data?

We are targeting Monday for the binaries to be available.


This is our minimum target for sync improvements. The way our DAGSync algorithm works, part of the capability is to make recently received funds spendable as soon as possible even before a full sync has occurred.

Thanks for the info. Were you able to resolve your issue with ledger?


No, not yet. I’m still waiting for their response but they have told me they’re working on it.

1 Like

I wish there was more information I could offer, ZerkaPGM#0875 posted on the Discord a few days ago about a ledger issue specifically about the code 0x6f01 which points to a technical issue e.g. damaged, check connections, try different computer. I couldn’t help him much either and ended up digging down a rabbit hole of an old issue of that fault that was speculated to have been caused possibly by too many apps accessing the device though was eventually recreated by passing empty input but this was patched years ago. I then stumbled on to these most recent patches which I assume apply to v5.x.x but idk.

Hey everyone, providing another update on the work ECC is doing here. Tl;dr is that faster sync for SDKs will be released in phases, zcashd 5.3.0 was released, and we’ve completed our analysis for ZIP 317.


  • Our #1 priority remains alleviating issues with slow sync times for wallets built on our mobile SDKs, primarily Edge, Unstoppable, and NightHawk.
  • A faster sync capability for our SDKs is being released in a couple of phases, the first of which lays the groundwork for DAGSync and adds support for Unified Addresses (UAs). The iOS version is currently in internal testing with Android following in about a week.
  • ECC released zcashd 5.3.0 to reduce concurrent memory utilization during scanning among other memory and performance related optimisations for full nodes.
  • We’ve completed our analysis for ZIP 317 which will make fees fair and equitable and consistent with chain usage. We are working on the necessary changes to zcashd at the moment and working with our ecosystem partners to gather additional feedback and discuss broader implementation efforts.
  • We’re continuing to work on recursion for Halo 2 which will form the basis for some additional performance and scalability optimizations in the medium-term.
  • We are currently working on additional optimizations for zcashd which will further reduce memory utilization and block propagation times.

Thanks again for your time and patience during this time. If there are any questions, please post them below and our team will answer them. You can also reach out to me directly.



Hi everyone, another ECC update on the work we’re doing. Tl;dr is we’ve identified and fixed the last known bugs that were blocking the first phase of SDK releases, we’re continuing to make good progress on DAGsync, and we’re prepping both zcashd and mobile wallets for ZIP 317.


  • Squashed the last known librustzcash bugs that were blocking wallet release and completed Android & IOS SDK integration.
  • Made good progress on the groundwork for DAGSync in the mobile SDKs.
  • Completed the implementation of zcashd optimizations expected to save memory and to reduce orphan rates for miners. We’re testing now and will included the updates in zcashd release 5.3.1.
  • Working on abstractions to support ZIP 317 (Proportional Transfer Fee Mechanism) in the mobile wallets.
  • Nearing completion on making zcashd have a single way of constructing transactions, rather than 4 different approaches. This will also support ZIP 317 changes.
  • Continuing to make progress on recursion for Halo 2, a fundamental building block for future scalability solutions

Thanks again for your time and patience during this time. If there are any questions, please post them below and our team will answer them. You can also reach out to me directly.



Exciting stuff!

What does the ECC team think about putting a EIP-1559 style non-discretionary, algorithmic fee mechanism in place as one of the next top priorities? In my mind, there’s some big things to work on - retiring old pools, posterity fund, POS, fee mechanisms. It seems like 1559/posterity fund (or perhaps Sustainability Fund since posterity is a fancier word less people might recognize and brings up images of “old” or “aged” while sustainability brings up images of “green” or “solar punk” in my mind :wink:) might be good to do in one fell swoop. The earlier we institute a posterity fund, the more ZEC will start accumulating in it for rainy days, and the also the sooner a future proof, non-discretionary fee mechanism is put in place, the less developers would have to later tinker with different fee mechanisms, sooner we could get an organic revenue source for posterity fund, etc.

As an aside, it would be very interesting to do a model of how much txn fees there would be under a 1559 style thing given current and past network loads - similar to how a comparison was done with current fees versus 317.

I remember @Souptacular said there was a certain economist who did some great modeling for 1559 for ETH - what was their name Hudson?


There’s a lot here (which is great!), so I’ll do inline replies.

We haven’t explicitly put this item on the roadmap, but I think it’s a prime candidate for ECC’s efforts on our Late 2023 roadmap goal. The current work on ZIP-317 which is being spearheaded by @NighthawkWallet w/ some support from ECC is a step towards improving fees so that they are proportional to the costs imposed on the network. However, that ZIP just sets a hard coded “fee schedule”, which means it may be too high or too low, depending on usage and demand for transactions. Some kind of dynamically adjusting fees are necessary to maximize usage of the network, and some examples would be a Bitcoin-style fee market or an algorithmic thing similar to EIP-1559. I’m in favor of the latter for several reasons, especially because I think it’s easier for users to understand, simpler for wallet logic, and better for privacy vs a BTC-style fee market.

Yes, these are all “goals of interest” for me. However, I don’t think ECC could design and implement those all in the 2023 milestone, while I also think we can/should do some prior to others. Also, at ECC we need to anticipate the effort and coordination it might take to integrate other changes to the protocol from across different teams (for example Qedit’s ZSA work). So any discussion of “the roadmap” needs to anticipate multiple teams showing up with their preferred roadmaps and timelines.

While the features you mention are all inter-related and might make a good “package”, my opinion is it’s better to ship features as soon as feasible in smaller upgrades for multiple reasons. One is to make each upgrade (relatively) simpler than a “big bundle upgrade” for safety and engineering reasons. The other is to get features out as quickly as possible to learn from how they perform in the market. PoS is probably the biggest / thorniest one there that I doubt would be done by end of 2023. In the ECC’s recently published 30-year vision notice we are aiming for a PoS transition by 2025, should the Zcash users accept that kind of transition.

I like your suggestion of rebranding Posterity Fund! It’s a name I just picked, and I agree it sounds a bit “old fashioned”. (I personally thought old-fashioned retro was kind of cool, but I’m totally not a marketer. :laughing:) “Sustainability” sounds both more contemporary but also seems easier to understand to me.


Fees have been relatively miniscule compared to issuance. Here’s a chart with 24-hr fees (in ZEC) and the running total:

It looks like the total fees over all time thus far is between 3500 and 4000 ZEC.

Another interesting analysis is what would fees be if the network started with an EIP-1559-like change, if you assume the exact same transaction load. I believe it may be similar or lower, since when blocks are less than half full (or some similar rule) the network fee falls. In real life, though, if fees approach 0 it might change how people would use txns, so it’s not safe to assume that the transaction load would be the same.

Finally, while all these changes seem important, at ECC we’re focused in the immediate term on getting shielded wallet performance & usability back to a better state with the current load, and then a prime candidate for the 2023 target which may be important than the stuff in this post is making shielded wallet perf & UX work much better for even higher txns loads. We’ll have to figure out how to balance that goal against some of the ideas we’re discussing here.


Thanks for your very thorough and thoughtful answer, Nate!


This is really interesting, thank you for the update!!!


Hey everyone, Ian here from ECC. It’s been a few weeks since my last post, so I wanted to provide everyone an update on the work ECC is doing to mitigate performance issues related to the ECC wallet SDKs.

This remains our top priority and focus as a company. We continue to have a cross-functional team working on these issues.

ECC updates:

  • We’ve integrated diverging rust libraries to ensure all new performance improvements and bug fixes are deployed consistently across the iOS and Android mobile SDKs as well as zcashd. This will help ensure users, which rely on our mobile SDK or zcashd wallet, will receive upcoming performance improvements with better quality assurances, and more promptly.

  • We’re modifying the wallet SDK architecture to enable performance improvements to scanning and syncing moving forward. This will enable a variety of upcoming improvements to the robustness of syncing a mobile wallet, including recovering when interrupted, improving the syncing protocol to greatly reduce sync time, and lowering mobile device storage requirements while syncing.

  • We’ve completed the implementation of zcashd optimizations expected to save memory and to reduce orphan rates for miners. This ensures the main network nodes operate robustly under the increased load which supports all Zcash wallet users.

  • Working on abstractions to support ZIP 317 (Proportional Transfer Fee Mechanism) in the mobile wallets. This upcoming change to the fee system will reduce the amount of low-value transactions which make up the bulk of the current load, which will further alleviate syncing issues for shielded wallet users.

  • Continuing to work on recursion for Halo 2. While this does not address the current performance issues, it sets the stage for longer term consensus protocol improvements to scalability down the road.

Thank you all for your time and patience. As mentioned previously, if there are any questions, please post them below and our team will answer them. You can also reach out to me directly.





Is there a way to default to or instruct about good privacy hygiene for shielding transactions and unshielding transactions within the mobile wallets?

Shielded to Shielded is optimal for privacy, and that is what we are working toward. But in the interim transition, there will be many shielding and unshielding transactions, and we may as well help those users as best we can.

A master tab with a short policy primer about privacy hygiene, shielded transactions, shielding and unshielding transactions, and why it’s important to follow some simple rules like:

  1. Let them know that difference between shielding transactions, unshielding transactions, and why z to z is the optimal transaction for privacy.

  2. If they need to do an unshielding z to t because the party they are interacting with will only accept from a t address, leave a significant amount of time between shielding and unshielding transactions, and think of your shielding address like a bank account where you keep money for an amount of time that you may want to unshield later

  3. need to make sure that you unshield to a different t address from the t address of your shielding transaction.

  4. need to make sure that the amounts of unshielding transactions are randomly different from prior shielding transactions.

And/or can we add features to the mobile wallets like:

  1. enabled to create new t addresses for every unshielding transaction by default.

  2. enabled to warn a user if a prior shielding transaction is (less the shielding transaction fee) for the same or similar amount as the unshielding transaction? And give them a prompt for that unshields for them in multiple transactions to multiple t addresses over a short period of time in random amounts.

I may be way off in my specific suggestions, but my general point is how can wallet design help newbie users from making rookie mistakes as they conduct shielding transactions and unshielding transactions?

Samourai Wallet does a good job of protecting the low information user from themselves, I hope we are learning what we can from that design.