ZCash wallet sync performance

:woozy_face: that’s not very good at all.

Your expectation of the wallet instantaneously knowing the balance after being turned back on is not feasible without some kind of outside authority. There’s no way the wallet could know it received or sent any funds in the time it was off without doing a scan. The mere fact that you can have more than one instance of the wallet means there’s no way to ever guarantee that the wallet funds haven’t been spent.

According to this quote from @nuttycom, the wallet should detect the note very quickly because it scans in reverse order. Therefore it has to scan 1h instead of 7 days before it finds the note.

I guess a really old unspent note won’t appear for 7 days…?


For the current wallet SDK, updating the balance in 1 minute after 1 week should probably be considered very quick.


Currently, blocks are averaging fewer than one sapling transaction.

Given these circumstances, one minute per week is undoubtedly inadequate. Should there be an influx of users due to the Brave integration, it is unlikely that this standard will be deemed acceptable.


Love the optimism, but highly doubting any large usage with that integration.

1 Like

The number of transactions on-chain are back to their pre-spam levels. That is to say, there are hardly any. Unless they pick up, the previous librustzcash synchronization would work fine.
But if they increase to the spam level, SbS will not be good enough. The more I investigate, the less I understand the rationale behind SbS.

@nuttycom Could you comment on this post? ZCash wallet sync performance - #65 by refinance



The only metric we should be measuring and care about is Time Till Full Sync. The SbS UX hack is just a band aid.

1 Like

Hey folks, thanks for the feedback, especially the specific details and the video by refinance. As I said earlier in this thread, Zashi is not yet ready for public consumption. It is in beta, and we’re working hard every day on it, with the help of the Secret Zashi Beta Testers Club, to identify and improve user experience issues like these. It definitely seems like there are some performance optimizations and other UX improvements we could make here. We’ll keep you updated as we diagnose these issues and make improvements!

Note that the other wallets that use ECC’s Wallet SDK are released: Nighthawk, Edge, and Unstoppable. If you see similar issues in any of those wallets, please report it to them and we’ll support them doing whatever they need to do to fix it.

Okay, before I go back to working on Zashi and our other work, I just want to clarify that the specific user story that Spend Before Sync is targeted at is a bit different from the various stories above in this thread. The user story—which we believe is very common and very important—is “Open your wallet and spend some ZEC that was already in there and already synced.”.

You’ve got some ZEC in your wallet. Now you want to open your wallet and spend some of your ZEC. Ideally, you should be able to do so right away. An example of this is what I do every day: stand in line at the coffeeshop, and when I get to the front of the line and it is time to pay for my coffee, I open up my wallet and click “send” to pay the coffeeshop. The goal of Spend Before Sync is that you can spend that money — the money that was already in your wallet — without having to wait for sync. Does that make sense?

So the use case here — open your wallet and spend some ZEC that was already in there and already synced — is different from the use case of “New incoming ZEC becomes spendable quickly”. That latter use case is also important, but it is not the one that Spend Before Sync is targeted at. The difference is whether you’re trying to spend ZEC that you already had in your wallet and was already synced (the coffeeshop scenario that I test out every day), versus whether you are trying to spend ZEC that is newly incoming to your wallet (i.e. if someone is paying you, and you want to spend your newly received ZEC as soon as you can).

If anyone wants to help us improve Zashi, you are invited to the Secret Zashi Beta Testers Club, where we talk about use cases and known UX issues.


I’m still struggling to understand why we need yet another wallet when supposedly proof of stake is the next big thing? Why not put all of the dev fund resources towards that goal, which looks from the roadmaps like it has been a goal for years???

1 Like

@zooko, thank you for taking the time to reply to this thread.

If Zashi is not meant to be performance tested, I will gladly use one of the released wallets based on the SDK 2.0: Nighthawk.

A week ago, I synchronized Nighthawk. Then I closed it and let it rest until today.
This morning, I opened it and I wanted to spend some of my ZEC. This is the scenario that you describe, isn’t it?

It took 3 min 15 seconds to get it to a working state.

IMO, it is not “without having to wait for sync”.

As a comparison, I restored the seed phrase in ywallet and let it rescan from birth height (3 weeks ago). The process took 40 seconds.

Also, the transactions from Zecfaucet.com are missing in Nighthawk but I think this is because it does not support Orchard.


Why didn’t you make a transaction while syncing, it would be nice to see that in a video after you have gone a week without syncing, according to the description of Spending before syncing, that should be the proof.

Note: syncing a week in YWallet takes less time than waiting for buying a coffee at a coffee shop/restaurant.


The wallet displays syncing… It didn’t look like it was possible to make a transaction. I will try next week.

All Zcash wallets initiate a sync process upon opening, as long as there are blocks to sync.

The difference with Spend Before Sync is that you can (as they describe it) spend while the wallet is syncing, if and only if there is balance to spend.

I will also run a test in a week with NHW, I tried it with Zashi (beta) and the transaction did not execute until the sync was finished.

Video - Spend Before Sync - Zashi (Beta):

Just for the record, you can also spend before it finishes sync… Actually, you can spend while it is synching, due to the magic of modern phones.

1 Like

The Nighthawk wallet requires the completion of synchronization before allowing any spending. As demonstrated in the video, the available balance for spending remains at 0 ZEC until the synchronization process is fully completed.

So far, neither Zashi nor Nightwallet wallets have demonstrated Spend before Sync.

@zooko I am afraid that SbS is not working as intended.

Unless SbS stands for Sync before Spend :wink:


Have you reported this issue to the Nighthawk devs?

Zashi Beta Test - Spending before synchronizing

A week ago I synced the wallet and at the culmination of the sync the available balance was 0.0004 ZEC, a week later I open the wallet again to make a spend while syncing and three things happen:

  1. The available balance is not maintained, the wallet synchronizes and/or processes data to then show the balance that I left available a week ago.
  2. When I try to send the transaction it gives error because although I have an available balance (synchronized a week ago), since Send the available balance is zero.
  3. I try again while the synchronization is about to finish, while I write the data from Send it appears that my available balance is 0.0004 ZEC, I send and the transaction is successful.

Was the transaction done before syncing, or was the wallet already up to date and that’s why the transaction was done?

I bet more on the second option, the balance was updated and the transaction was successful after the synchronization was completed.

V.0.2.0 (491)

1 Like

@zooko Dear Zooko,

I want to clarify a few points regarding the SbS functionality issues.

We are discussing a significant problem here. The key feature, which is central to the project, is not functioning properly.

It seems when SbS has problems in Zashi, the reason provided is Zashi’s Beta status. Therefore, you suggested that I test SbS in the Nighthawk wallet. However, when SbS also fails to function properly in the Nighthawk wallet, the blame is shifted to the Nighthawk wallet developers.

This situation raises concerns about your accountability.

Specifically, it seems that as the project leader of SbS (and the CEO of the ECC) you should be assuming responsibility for these SbS issues. But instead, you are sending the users on a wild goose chase.