All ECC teams focused on wallet performance

Couldn’t agree more. And it’s one person (vs. however many work on nighthawk, zingone with the wind, etc…). @hanh is the real MVP.


[This Movie Scene] Everytime I see @hanh single-handedly building and delivering products that become Flagships for the Zcash community.


I smell a retroactive grant…

Agreed. :+1:

With multiple node implementations - and with QEDIT getting involved in protocol development - we need a different approach to network upgrades. I expect that @Souptacular will have some good insights on this topic.

The first step is to do a proper retrospective on the NU5 upgrade.

I’ll add this to the agenda for today’s Arborist Call.


Yes, it does.

The ZIP 317 block template construction algorithm allows for 50 “unpaid actions” per block. We anticipate that this will be sufficient for transactions from wallets that have not updated to pay ZIP 317 fees to be able to be mined temporarily. However, they should update.


Update on zcashd 5.5.0 from ECC engineering: All known issues have been fixed, and the release candidate was cut yesterday. Testing and packaging should be complete early next week.


I’m really happy about the simplifications that have been made to zcashd as part of the ZIP 317 work. (Most of them are in zcashd v5.5.0; the remainder will be in v5.6.0.)

The logic we inherited from Bitcoin for fee and priority estimation in the internal zcashd wallet, and for block construction in getblocktemplate, was grossly overcomplicated. It also made assumptions unsuited to Zcash — for example the concept of “coin age priority” depends on knowing which coins are being spent and their values, so it can only apply to transparent coins. We had a hack to work around that particular problem: transactions with any shielded component were treated as maximum priority. But there was still a divergence in fee behaviour between legacy and z_* APIs, which meant that the design simplifications to use a fixed fee (before ZIP 317) were never fully adopted.

I’ve been wanting to simplify this since before Zcash launched, but there was no practical opportunity to do that given all the other demands on engineering bandwidth.

Coin age priority is now completely gone in v5.5.0. (Upstream Bitcoin Core had removed it earlier, but their PRs were entangled with other changes we didn’t want.) Priority estimation and the estimatepriority RPC call is gone. The concept of “free transactions” is gone, replaced with the “block unpaid action limit” in the ZIP 317 block template algorithm. Fee selection is greatly simplified, and the old fee estimation code is almost gone. (It’s no longer used by the internal wallet; in v5.6.0 the remaining code and the estimatefee RPC call will be removed.) We’ve removed 6 zcashd config options (sendfreetransactions, blockprioritysize, limitfreerelay, relaypriority, txconfirmtarget, mintxfee), and added only one (blockunpaidactionlimit) in exchange! Verbose, near-duplicate code in implementations of several of the z_* RPC calls has been merged together and rationalised. This is all a huge simplification and removal of technical debt, replacing behaviour that never made sense in the context of Zcash with behaviour that has been specifically designed for it.

I don’t know whether adoption of ZIP 317 will in practice halt the sandblasting, but it’s a serious effort toward doing so. It will certainly make it more expensive for the adversary; whether that’s sufficient depends on their resources and motivations. In the meantime we’ve significantly improved zcashd’s robustness, performance (mainly in previous 5.x releases), and technical debt.


May we have an update for the week ahead?
There are a lot of Zcash client operators and wallet users tapping the F5 button in anticipation of a fix for the fee issue and spamming attack!

1 Like

We have tagged a second release candidate addressing some minor issues discovered during our comprehensive testing of the first release candidate. Once we’ve completed testing on this second RC, we will publish the final 5.5.0 release.


Hello, again.

Testing and cleanup is complete, and today ECC released 5.5.0 — a bit later than hoped, but we are still on track to exit wallet performance emergency mode by the end of May.

This latest release contains infrastructure improvements that lay the groundwork for 5.6.0 and the completed transaction-fee-structure change (ZIP 317). Check out the blog post for more details.

As mentioned previously, the 5.5.0 release will not have an immediate, noticeable impact on normal user experience, but it’s an important milestone and narrows ECC’s focus on the remaining pieces that will restore good user experience in the impacted apps and allow users to quickly access and spend their funds.

Zcashd 5.6.0, lightwalletd, and SDK updates will be released at the same time, at the end of May, which will signal the end of emergency mode. Here’s the updated release schedule:


Awesome! Great stuff from the ECC team.


A proposal related to this:


Hi, again. Time for another update. :wave:

ECC’s engineering teams continue to prioritize the features and functionality necessary to exit “Emergency Mode.”

Criteria for exiting Emergency Mode are that the ECC CEO, Head of Engineering, and Head of Growth all agree that we have accomplished the following.

  1. Users of Edge, Unstoppable, and Nighthawk can spend their current funds (funds that are already synced when they open their wallet).
  2. Users of those wallets can receive and become able to spend new incoming funds at a rate of a month’s worth of transactions in 1 hour.
  3. Users have confidence that the sync is making progress and will eventually complete.
  4. None of those wallets are impacted by frequent crashes or inconsistent behavior (such as failing to display some already synced transactions).

With the release of zcashd 5.5.0 last month, our focus has turned to zcashd 5.6.0, along with updates to both lightwalletd and the mobile SDK. This combination of releases will enable improved lightwallet sync performance and a fund availability feature, allowing users to spend funds before a full sync has completed.

We have actively engaged with our wallet development partners to ensure they have access to integrate and test these new features as quickly as possible. This will help ensure end users can take advantage of the performance improvements as quickly as possible after release. We still expect to deliver the all updates below by the end of May, but it may take some time after this point for each of the wallet providers to update their code and enable the new functionality for their users.

Release schedule:


We are looking forward to the release of the updated dependencies: ECC Mobile SDK, librustzcash and Lightwalletd adapter software.

The Nighthawk Wallet team is on track to deliver items per our roadmap set for the 2023 year. The upgrades to our infrastructure are underway with migration to a completely automated deployment system. This work will support novel methods being introduced to sync light wallets at a greater efficiency and service the broader Zcash ecosystem using services.

We continue working together with ECC developers, offering potential solutions and suggestions to help fill gaps and to enable our team to merge skills and maximize efforts towards delivering an easy-to-use, Shielded-by-default ZEC experience.


The roadmap looks good! Great to see you prioritize chain sync issue. The Unstoppable wallet team is looking forward to the updates and will try to apply them as soon as they are out.

In case you need us for anything as development progresses we are available 24/7 over Telegram.

Love and peace!


Does the ECC have V&V test engineers and their efforts also factored into the wallet deliverables?

does ECC restructuring change end of may timeline i guess?

Slightly… we are still aiming to get a release candidate for zcashd out this week, with the lightwalletd and SDK changes shortly thereafter. The goal is to stay as close to the original plan as possible, but recognizing we lost a few days with the restructuring and shifting of work.


We at Edge have full intent to support the updated SDKs that improve performance and stability. As maintainers of the react-native-zcash repo/library with RN bindings, we will keep the repo updated for Edge and other react native focused projects incorporating Zcash. We look forward to the updates bringing zcash usability to the masses.


To follow up Nick’s post from yesterday, ECC’s restructuring operations created a small impact on the overall delivery schedule for the remaining “Emergency Mode” functionality. The release timeline below includes those updates.

In addition to what is listed, we also completed a quiet SDK update release, which included block download and scanning parallelization features. This is part of our continuing Emergency Mode efforts to address functionality and feature challenges within the software. The end result of releasing this functionality is a much improved linear scan capability ahead of the zcashd 5.6.0 release, which will enable the DAGSync algorithm and fund availability.

We are also actively engaged with our third-party wallet development partners as we reach critical milestones. This ensures a two-way communication channel while minimizing the wait for end users to see new features realized in their favorite wallet product.

With the updated timeline below, we are expecting a release candidate for zcashd 5.6.0 in the week of June 5, with the stable release a week later. The updated lightwalletd and SDK versions will follow the same timeframe, coming during the week of June 12.