Hi everyone, Happy New Year! 
This is our first engineering update of 2026 and we are going to share all the fun things we worked on during our Hackmas last year. We will have more in-depth posts about each of these different projects coming soon…in the meantime, here’s a quick preview of each one:
Towards a Unified RPC Interface for the Z3 Stack
For Hackmas, @Alfredo focused on creating a single, unified RPC endpoint for the Zcash Z3 stack (Zebra, Zallet, and Zaino) to simplify interaction for applications like exchanges and end-user wallets. This new layer aims to expose a merged OpenRPC specification and provide a single endpoint that transparently routes calls to the appropriate backend. This project is currently in progress.
Mining Pipeline
@Marek set up a mining pipeline to produce a block with a shielded coinbase transaction. He tested the setup on Testnet first and is now waiting for such a block on Mainnet. Along with this work, he revamped our mining documentation and Dockerized the setup. He also added support for generating custom genesis blocks, which enables starting custom testnets from scratch with Zebra.
FROST Support in zcash-devtool
@Conrado worked on adding preliminary FROST support to the zcash-devtool CLI to streamline the process of using the scheme. The work involved standardizing the “transaction plan” file by adding PCZT format support to the zcash-sign tool, refactoring frost-tools to work better as a library, and adding security by having the frost-client show PCZT contents before signing. This update enables zcash-devtool to act as a coordinator for a FROST signing session, allowing developers and users to create and sign transactions with FROST directly without needing to interact with multiple tools.
What’s New Tool
@Gustavo developed What’s New as a tool to address the difficulty of tracking changes across the numerous Zcash Foundation repositories by standardizing change information from releases, changelogs, and commits into one format. The tool includes a CLI and core libraries that normalize the data, add category filtering to focus on important changes, and feature a confidence scoring mechanism to be transparent about output quality when inputs are inconsistent. Key takeaways were the need for strong normalization rules and the value of confidence scoring.
Zentity
@Gustavo also worked on the Zentity project, which is a test case for a privacy-preserving identity verification onboarding process designed to avoid storing Personally Identifiable Information (PII) while maintaining compatibility with verifiable credentials and standards like OAuth and OIDC. He stabilized the core flow, including liveness checks, ZK proof integration, and auth hardening, while also focusing heavily on deployment reliability and tightening security infrastructure like CI/CD and container hardening. Conclusions from the work highlight the critical need for stable liveness performance, clear documentation for privacy workflows, and explicit management of deployment details.
Zeeder
@DC developed zeeder, a high-performance, modern DNS seeder for the Zcash network, written in Rust, intended to replace legacy C++ and Go versions that are difficult to maintain. Its utility comes from its integration with the team’s zebra-network crate, which ensures automatic compliance with protocol updates, along with modern features like per-IP rate limiting, full Prometheus metrics for observability, and a lock-free address cache for high performance. Currently in Beta and ready for production testing, a key technical finding was the effectiveness of using tokio::sync::watch channels for near-zero latency service. You can find a full blog post about it here.
Pushing Zebra’s Initial Sync Performance Further
@Arya decided to investigate and test ways to improve Zebra’s initial sync speed, timing several full sync tests with various changes. The most interesting finding was that the state service was not always the main bottleneck, but that zebra-network and the syncer can typically be the critical performance constraint outside the spam attack. Various changes independently improved initial sync performance by 13-35%.
If anyone would like to know more about this work or get involved, please see forthcoming updates that will provide more detail.
Thanks for reading!
