March 21st
Hello! This is an unusual Zcash Z3 update from Sofia, Bulgaria. The ZkProof space is preparing for a special week: Zk Week. Many Zcash members are travelling to the ZF Dev Summit near the ZkWeek conferences, so work may have been slowed down a bit due to some team members preparing to spend some days away from home.
I invite you to access the quote on quote “dashboard” (in development) https://zecdev.github.io/zcash-z3/dashboard
Zebra
Project Roadmap board
Priority board
ZF has been mostly engaged with ZF dev summit but still progress is being made in their front. The following issues will close the ongoing sprint
- feature: Add additional fields to getrawtransaction verbose response
- Configure, run and monitor a zebra only custom testnet for testing
According to what it was discussed during ZF’s dev summit and their board, the Zebra team is marking “Ready for Zcashd deprecation” on mid-May 2025. What does this mean?
In short, it means that Zebra is exposing all the functionality that Zaino and Zallet would need according to the new architecture that the different Zcash dev teams agreed upon plus the requirements that so far have been collected from Exchanges, Miners and Block explorers. At this point other teams will be able to fully rely on Zebra for their projects and start working on full integration of Zebra into them, meaning, more development work needed will be able to be started.
Zebra is not only a modern Rust codebase. It is a project that makes heavy use of continuous integration. This means that when Zebradoers make changes in the Zebra code, a bunch of cloud machines start testing the code by spinning up some portion of code that solely dedicates to asserting whether some conditions continue to hold after those changes were made. Mindblowing huh?
“The current state of Zebra’s CI let’s me sleep very well. I know that if we modify some code we can notice if something broke or note, that means that we can cut a new release from our main code branch at any time” - Zebra Dev.
This is a key aspect of Zcash Z3 and it will continue to be. But don’t take it for granted. Continuous Integration also require a continuous commitment to testing your code with more code. We all need to commit to add tests for every piece of code we contribute to Zebra so it can stay fresh and keep advancing Zcash into the future.
Zaino (ZingoLabs)
- Status: almost back on track!
Zaino is starting to work on milestone three of their grant this includes work to make Zaino read directly from the remote ReadStateService from Zebra and also to make Zaino serve the lightwalletd replacement part of its functionality from that service. There’s a bucket of allocated time to unforeseen work or bug fixing.
Zingo devs are fully committed to deliver Zaino and shifting most of its development team to their “winning horse”. @zancas can correct me if I misrepresent this but I have the impression that 75% of their Dev team is shifting entirely on Zaino.
In-Memory backend wrap up
- status: pending review 
This has been falling through the cracks a bit, we still need to provide reviews to this PR https://github.com/zcash/librustzcash/pull/1634
Zallet full node wallet
- Status: delayed (but rapidly catching up)
ECC has notified a deviation of 2 months from the original schedule.
tracking work on this repository.
Part of ECC’s engineering team is preparing for attending ZF dev summit and ZkWeek but progress is still being made.
@str4d is starting to sync wallet using a full node via Zaino instead of a lightwalletd! And also reporting some issues to Zaino developers. Any differences in the implemented wallet RPCs are being tracked here
Wallet Export format
- Status: On-track
ZCG as acknowledged and approved the planning changes from Zingo and Blockchain Commons and teams continue to work on Milestones 2 and 3 at the same time. They are still looking for wallet files to test on! See message below.
TESTING TESTING!
I forward you a message from Wolf McNally from Blockchain Commons
I’d be happy to test against any drained wallets provided, and would obviously keep them in confidence unless explicit permission to release them publicly were granted. Also, I don’t even have to know the identity of the provider, as that’s immaterial to ensuring compatibility. Obviously in that case there would be no way to identify the submitter and therefore no way for the submitter to grant permission for release, so any anonymously-submitted wallets would have to remain permanently confidential. I’m also fine with pledging to sequester them on separate storage, and destroy all copies once the work is complete.
This is quickly becoming CRITICAL PATH, so anything you can do to help Wolf push forward: testing, advice, comments, and wallet files would be greatly appreciated.
Regtest? What is that?
- Status: First round of review comments addressed
As you may have seen in the forums, I created a ZIP draft according to the ZIP process to address this undefinition problem we’ve faced.
I addressed the first round of comments on this PR https://github.com/zcash/zips/pull/986
You can read, review and comment too!
Thanks for reading!
