Zcash has released version 1.0.0 of Zakura, a new full node client that sits at the front of a broader effort to rebuild the network for high-throughput private payments. The pitch from the teams behind it is blunt: keep full verifiability and strong privacy guarantees, but move performance toward the level of global card networks such as Visa and Mastercard.
According to the project, those networks process more than 50,000 transactions per second, and that figure is treated as a baseline rather than an aspirational ceiling. Zcash, by comparison, currently handles roughly one private transaction per second, making Zakura the first major building block in that upgrade path.
What Zakura is and who maintains it
Zakura is a full node, meaning software that stores a complete copy of the blockchain ledger and independently checks whether each transaction follows network rules. In this case, that ledger is Zcash.
The client is maintained by Sean Bowe, a founding figure in Zcash zero-knowledge cryptography, and Dev Ojha, co-founder of Osmosis and now head of Valar Group. The report says both teams are funded by private ZEC donations, not by a company or foundation.
Zakura is built as a fork of Zebra, the Zcash Foundation’s node software. In practice, that means it starts from the Foundation’s official codebase and rebuilds from there. The importance of this sits in consensus rules: every node follows the same shared rulebook to decide which blocks and transactions are valid. If one node applies a different set of rules, it forks away and stops tracking the same chain as the rest of the network.
Pruning, snapshots and zcashd compatibility
One of the immediate changes in Zakura is pruning. The node can delete old blockchain data it no longer needs, sharply reducing disk usage. The team has published a ready-made copy of the chain at about 11 GB after old data is stripped out, so new nodes do not need to download the entire history block by block from peers.
That setup cuts the time needed to go from zero to a running node to under two minutes, which the team says is 680 times faster.
Zakura also includes a compatibility mode that reproduces the interface of the original zcashd client, whose end of life is set for July 18. That matters for wallets and exchange integrations that were built around zcashd, because they can keep operating without an immediate rewrite.
Why the network is aiming at 50,000 TPS
The team frames the challenge as a math problem. To keep up with more than 50,000 transactions per second under Zcash’s current cryptographic design, a node would need to receive and verify more than 500 MB of data every second. Each private transaction carries a proof, and those proofs are large.
The report compares that load to receiving a full DVD worth of data every 10 seconds, continuously. No Zcash software today comes close to that level.
In a blog post quoted in the article, the team said, “Our dream is to support global payments. Mastercard and Visa process more than 50,000 transactions per second; that is our floor.” The same post adds that the current stack cannot meet that requirement, but cryptographic work now under development could close most of the gap.
Tachyon and the consensus bottleneck
Bowe’s Tachyon project is meant to tackle the heaviest part of that burden through recursive proofs. The idea is that one proof can attest to the validity of thousands of other proofs, which cuts down the amount of data the consensus layer has to inspect directly.
Under that design, a node verifies one proof instead of thousands. The team says this changes consensus data requirements from 100 MB per second to 500 MB per second, a level it believes can be reached with careful engineering.
The point is not abstract. If node-side verification remains too expensive, payment-scale throughput never reaches the network, regardless of improvements elsewhere.
Wallets face a different ceiling
Wallet software runs into another problem. Because Zcash hides transaction recipients, a wallet cannot ask a server which transactions belong to it without exposing itself. Instead, it has to pull everything down and test entries one by one.
That is why wallet software currently tops out at about one transaction per second.
Valar Group is working on private information retrieval, or PIR, to remove that bottleneck. The goal is to let a wallet fetch the data it needs from a server without revealing which records it requested. That effort addresses synchronization and query efficiency on the wallet side, separate from consensus-layer scaling.
Fast block propagation is part of the design
Zakura also sits in the part of the stack responsible for fast block propagation, meaning the ability to broadcast newly mined blocks across the network as quickly as possible.
The software has to move fresh blocks between nodes fast enough for heavier proof traffic and higher wallet activity to be practical. It includes an experimental system designed to deliver each block to every node within half a second, though that feature is off by default for now.
Ironwood activation is expected in late July
Those ideas are about to meet a near-term network milestone. The article says testing is coming in late July, when Ironwood, formally NU6.3, is set to activate at mainnet block 3,428,143 at around 8 a.m. Eastern on July 28. Zakura supports that upgrade from launch.
Bowe said on July 10 that all major organizations had committed to activate at that height. The date was pushed back by one week from the original plan because exchanges and wallet providers asked for more preparation time.
Why Ironwood exists
Ironwood traces back to a vulnerability that nearly hit Zcash hard in June. The shielded pool is the network’s private side, where amounts and participants are hidden and zero-knowledge proofs serve as the mathematical evidence that transactions are valid.
On May 29, Shielded Labs researcher Taylor Hornby found a soundness flaw in the proof circuit for Orchard, the latest shielded pool. The bug could have allowed an attacker to mint fake ZEC on-chain without leaving a trace, and it had existed since Orchard was activated in May 2022.
Developers responded by disabling Orchard in an emergency process completed on June 2. On June 3, they restored it through the NU6.2 hard fork at block 3,364,600 using a fixed circuit.
That patch did not erase the uncertainty created during the roughly four years the flaw had been open. Zero-knowledge proofs reveal nothing beyond whether verification succeeds, so the chain carries no record showing the contents of Orchard transfers. As a result, nobody can prove that fake ZEC was never created during that period.
How Ironwood is meant to contain the risk
Ironwood is built to address that leftover risk at the boundary of the pool. The mechanism described in the report is a “turnstile” at the edge of the shielded pool. Amounts moving into and out of the pool are public even if transfers inside the pool stay private, which gives the protocol a way to constrain what can enter and leave.
With Orchard closed to new deposits, the turnstile becomes the only exit. If counterfeit coins exist inside the pool, the design is meant to trap them there rather than let them flow into circulating supply.
In simpler terms, honest balances can leave over time, while fake balances may be prevented from fully exiting. The article says the setup is intended to contain any attempt to create excess supply at the boundary and restore confidence in the reliability of the token’s supply figures.