zakura - Announcements

Release: Zakura 1.3.0

2026-08-31T00:00:00+00:00

</figure>

We have released Zakura 1.3.0</code></a></strong>, our largest update yet. This is the first release built on Common</a>, the accelerated cryptography stack we recently announced</a>, directly translating to improved transaction and block processing time for all users.</p>

This release also features a brand new consensus engine built for speed and security.</strong> Currently located within our experimental P2Pv2 stack, its architecture addresses security issues by targeting vulnerabilities at their root causes. It is also designed in anticipation of higher throughput, and supports better integration with lightwalletd</code>.</p>

Several features requested by explorers, indexers, infrastructure operators and users migrating from zcashd</code> have been integrated into this release. We recommend that all node operators update for better performance and security, and we recommend miners update for reduced orphan rates.</p>

Experimental Consensus Engine</h2> Earlier releases</a> of Zakura closed P2P vulnerabilities one at a time. Most of these issues were due to underlying architectural problems that would require a new proof-of-work consensus engine to truly resolve. So, we built it.</p> In our redesign, every byte communicated must be verifiable, useful, and within a node's work budget. This is the same kind of design philosophy underlying light clients. In fact, our new implementation is naturally light client first.</strong></p> Verified Header Chain</h3> Zakura's experimental consensus engine downloads and verifies headers and tracks competing consensus branches in a bounded, authenticated DAG, selecting the best eligible chain. It verifies each header's proof-of-work, difficulty and contextual rules before the node acts on it. Then, it authenticates every block body against the verified header chain.</p> The engine separates the block body downloading logic between catch-up and chain tip, without duplicating consensus logic. The catch-up downloader optimizes for raw throughput, while the chain tip downloader balances throughput with latency. Both of them use the same verified header chain.</p> This architecture addresses many P2P security vulnerabilities by design</em>:</p> Unverified headers and unauthenticated bodies cannot steer expensive work.</li> The engine is fork-aware and persists the header chain atomically across crashes.</li> All peer-supplied data is authenticated and tracked.</li> </ul> As an example, the redesign could allow two Zakura peers to gossip blocks after proof-of-work verification but before</em> every zk-SNARK proof finishes verifying, reducing orphan rates significantly.</p> The bounded header DAG makes block reorganization safer and the fork-choice rules explicit. This matters in the context of attacks like selfish mining, especially because Zcash's difficulty adjustment algorithm is applied every block. We plan to harden these rules in later releases; if adopted, ZIP-218</a>'s difficulty adjustment changes would reduce this risk.</p> Experimental Support</h3> The new engine is disabled by default for Mainnet. If you want to enable it, you must add</p> p2p_stack = "dual" </code></pre> to your Zakura configuration. It is enabled for Testnet by default.</p> Serving Light Clients (on P2Pv2)</h2> The verified-commitment-tree (VCT) fast sync in our P2Pv2 stack already allows a new node to reach the chain tip quickly. It achieves this by skipping historical node commitment trees. However, current lightwalletd</code> architectures expect all full nodes to maintain historic frontiers and full subtrees. This meant that lightwalletd</code> was unable to serve queries from P2Pv2-synced nodes. (As mentioned, this stack is still experimental and disabled by default.)</p> We consider this a design flaw of lightwalletd</code> itself. Beyond some historic distance, it should be sufficient to maintain frontiers of full subtrees or a fixed block interval, such as every 10,000 blocks.</p> Nevertheless, we updated Zakura so that it could produce these exact queries for historic data without significant disk space costs. This was achieved with a combination of offline checkpoints and online recomputation: the node ships a small checkpointed list of tree frontiers at historic blocks, and to answer a query, we replay the block bodies from the nearest frontier and rebuild the tree.</p> Thanks to our new Common cryptography stack, this replay is very quick, which means lightwalletd</code> operators should have seamless functionality from all</em> Zakura archive nodes.</p> Speaking of Common...</p> Running on Common</h2> Zakura Common</strong> speeds up the shielded cryptography a full node relies on. Verifying a shielded zk-SNARK is between 4x and 8x faster</a>, and Sinsemilla hashing, which builds the Orchard and Ironwood note commitment trees, is more than 21x faster.</p> Nodes touch this cryptography almost everywhere they handle shielded transactions, and so this speedup shows up across the board:</p> Safer mempool operation.</strong> Nodes can validate mempool transactions at lower latency, which makes exposing a node's mempool to the public much safer.</li> Verifying blocks and transactions.</strong> Every shielded proof the node checks, in each block it accepts and each transaction it relays, is verified faster.</li> Syncing the commitment tree.</strong> Building the Orchard note commitment tree during sync is about twice as fast, using our new weighted fixed-length Sinsemilla evaluator</a> and a one-time 3.75 MiB table. Ironwood's tree uses the same code and inherits the speedup.</li> Building blocks.</strong> Miners assembling a block template with shielded transactions spend less time on the cryptography, so getblocktemplate</code> returns sooner.</li> Relaying and propagating.</strong> Faster verification means transactions and blocks relay and propagate with less delay, helping to reduce orphan rates for miners.</li> </ul> We also cache Sapling bundle verification now. These proofs and signatures are verified once when they arrive over the mempool and not re-verified when they appear in a block. This extends the caching we shipped</a> in 1.2.0 to the last remaining shielded pool.</p> RPC Changes</h2> getchaintips</code> is answered natively.</strong> Operators used to send this call to the zcashd</code> compatibility sidecar, where it scanned the whole block index under a global lock and could stall every other RPC for seconds. Zakura reads only the forks it is tracking, so the cost depends on how many live forks there are, not on the height of the chain. It reports only the tips that are still live (the best chain, the non-finalized forks, recently invalidated branches, and the selected header chain when some block bodies are missing), never zcashd</code>'s valid-headers</code> or unknown</code> statuses, so the two nodes list different tips.</li> getpeerinfo</code> reports peer software.</strong> The response now includes each peer's advertised software identifier (subver</code>) and protocol version. This was requested to better support explorers.</li> Several long-term deprecated endpoints have been removed. See the changelog</a> for more details.</li> </ul> P2P Network Service Discovery</h2> Huge thanks to @distractedm1nd</a> for contributing P2P service discovery into Zakura! This lets applications advertise the extra services they provide over the P2P network, so a wallet can discover nodes that serve additional functionality, such as PIR or lightwalletd</code> interfaces.</p> We hope that future wallets can connect directly to the Zcash P2P network, instead of bundling every single service type into their software. Thus, we believe this is a step in the right direction.</p> Security</h2> A peer can no longer force a large allocation</strong> by declaring a near-maximal byte-vector length in a short message. The allocation is bounded before the message is rejected.</li> Malformed headers are rejected before hashing.</strong> Block and checkpoint verification now reject an invalid header version or an unrepresentable timestamp before computing the header's hash. This closes a gap for in-memory headers, such as block proposals, that never pass through the parser.</li> Dependency hygiene.</strong> Dependencies were updated to address published advisories, and many were removed outright to reduce supply-chain surface.</li> </ul> Other operator-facing changes</h2> Expired RPC TLS certificates are flagged at startup.</strong> zakurad</code> now logs a warning naming the certificate file and the date it fails on, instead of opening the listener silently and failing client handshakes later.</li> Bounded /metrics</code> on public listeners.</strong> Network Prometheus counters are no longer labeled by peer address, so their cardinality stays bounded on long-lived public listeners.</li> Faster block verification.</strong> Contextual block verification drops redundant UTXO copies and shares immutable UTXO maps, and transaction-verifier and mempool reads no longer queue behind the serialized state write buffer.</li> Misconfigured networks fail at load time.</strong> Custom-network parameters that could panic block validation at a later height, such as overflowing funding-stream numerators or non-P2SH funding and lockbox addresses, are now rejected when the configuration is read.</li> Removed the unsupported copy-state</code> debugging command.</strong></li> </ul> Crate Consumers</h2> If you build against Zakura's published crates, note two changes. The dependency graph now resolves the Zakura cryptography crates in place of their upstream equivalents, and zakura-rpc</code> removed a set of deprecated type aliases and constructors. RPC endpoints and wire formats are unchanged; the changelog</a> lists the exact replacements.</p> End of Support</h2> This release shortens the end-of-support window from 40 to 31 days. Mainnet zakurad</code> nodes running 1.3.0 halt at height 3,501,339</strong> (estimated 2026-09-30</strong>); upgrade warnings begin three days earlier.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.3.0</code> via Cargo. See the download page</a> for installation and verification instructions.</p>

Zakura Common: High Performance Zcash Cryptography 2026-08-29T00:00:00+00:00 </figure> Our team is excited to release Zakura Common</strong></a>, a large collection of cryptography and protocol libraries for the Zcash ecosystem. These libraries are being developed to accelerate our full node Zakura, and to improve wallet performance for everyday users.</p> The optimizations in this release are among the most significant in Zcash's history. Our benchmark hardware reports:</p> Mobile proof generation is more than 14x faster.</strong> (Desktop is more than 5x faster.)</li> Sinsemilla hashing is more than 21x faster.</strong></li> Trial decryption is more than 1.5x faster.</strong></li> zk-SNARK verification is between 4x and 8x faster.</strong></li> </ul> In discussions about scaling Zcash we often mention goals like sub-second confirmation times. But all users today spend over three seconds just waiting for their wallets to create a transaction. Zakura Common's highly optimized cryptography allows a user to instead wait less than 200ms in many cases — practically imperceptible.</p> Wallets using this new stack will sync much faster. Full nodes running Zakura additionally benefit from reduced orphan rates and faster transaction propagation; our network can already handle the 25-second block times proposed for NU7, but with these optimizations we can go even further.</p> None of our improvements require a network upgrade and all of them are publicly available today, under the standard MIT / Apache 2.0 dual license. Zakura has completely switched to this new stack in its upcoming 1.3.0</code> release, and Tachyon</a> has too.</strong> We'll be writing about this in separate announcements.</p> Zakura Common 1.0</h2> The root of our work is contained in the Zakura Common</strong> monorepo, zakura-core/common</code></a></strong>, which contains modified forks of librustzcash</code> and several other crates as well.</p> In some cases, our performance improvements derive from well-known techniques in the broader cryptography and compiler worlds, but in others they stem from novel ideas our team has developed</a> just for Zcash.</p> These results aren't all from one big optimization.</strong> Each headline component did substantially improve. But Amdahl's law is real. Once you optimize one component, some other serial process becomes a bottleneck. Much of our effort was spent on constant factor improvements to things that would normally be considered asymptotically efficient.</p> zakura-core/wallet-libraries</code></h3> We are also developing a separate zakura-core/wallet-libraries</code></a></strong> repository that contains Rust crates useful for shielded wallets or other integrations. Zakura, being a full node, does not depend on these libraries.</p> These libraries integrate directly with our Zakura Common stack, and thus inherit many of the performance benefits we've discussed. Longer term, they will contain our PIR</a> work.</p> Next Steps</h2> Zakura Common speeds up full nodes and wallets significantly compared to the legacy librustzcash</code> stack. We're inviting wallets to switch to our cryptography libraries so that they can enjoy the performance benefits on today's Zcash network.</p> As mentioned, Zakura's 1.3.0</code> release is forthcoming and will switch to Zakura Common. We'll be blogging about that soon.</p> Release: Zakura 1.2.0, 87% faster full block processing 2026-08-14T00:00:00+00:00 We have released Zakura 1.2.0</code></a></strong>, a performance release. Since zcashd</code> reached end of support, the network has seen elevated orphan rates. This release removes the largest cause we found: nodes were performing redundant proof verification during block acceptance. On full Ironwood blocks with regular transactions, block processing time on our benchmark machines drops from 2.5 seconds to 0.32 seconds. For median block times, that is nearly a 5% reduction in wasted work.</p> We recommend that all node operators update. Mining pools benefit the most: the work removed here directly affects miner revenue.</p> This release also adds streaming block-range backfill to the indexer gRPC service (thanks to @maxdesalle</a>) and hardens the indexer RPC listeners.</p> Evidence something was wrong on the network</h2> We profiled orphan rates on Zebra 4.3.0</a> months ago. Mainnet orphan rates were around 0.1%, and our simulated, far more decentralized testnet was around 1%.</p> Since zcashd</code> reached end of support, there has been evidence of repeated performance regressions. Outlier block times increased, with far more 10+ minute blocks than statistically expected, and on July 31st the network's orphan rate reached nearly 1%, far above the old 0.1% to 0.2% baseline. Our first fixes patched peer connectivity after the upgrade and removed disconnects on slow blocks, which appears to have reduced the initial spikes of 10+ minute blocks. Even so, the baseline orphan rate settled around 0.3%, with spikes to 1% on days with many quarter-filled blocks. Zakura treats orphan rate as a core performance metric, so we kept investigating.</p> Re-running the same analysis now, Evan</a> saw orphan rates on Zakura of 3.2% with 75-second blocks and 42% with 20-second blocks.</p> Every proof was being verified twice: once when the transaction arrived over mempool gossip, and again when it arrived inside the block that included it. Measured on one machine with matched block sizes, a block's Halo2 batch weights summed to exactly the block's Orchard action count plus the mempool's. This slowed block processing, and with it the miner's switch to the new block.</p> Zebra used to avoid this duplication with a proof-check cache, and our distributed tests traced the regression to that cache's removal in Zebra 4.3.1 (Zebra #10494</a>) as part of a critical security fix</a>: the old cache stored the verdict valid(transaction, height, block time, spent outputs)</code> under a key that did not determine that proposition.</p> Caching proof verification results</h2> Zakura 1.2.0</code> caches the stateless proof verification itself rather than the verdict. Verifying a single Halo2 item against a verifying key is a pure function of its inputs, so a cache hit is bit-identical to the computation it replaces. Nothing else is skipped.</strong> On a cache hit, transaction verification still runs end to end at the block's own height, with the block's time and the block's spent outputs. The cache key commits to the full transaction, so a malleated transaction cannot reuse a cache hit.</p> The flow now looks like this:</p> Before: receive block -> verify every proof again -> finish block checks -> update template After: verify each proof once, in the mempool | receive block -> reuse the proof results -> run every block check -> update template </code></pre> The change is Zakura #597</a>. It moves the duplicated work out of the critical path between receiving a block and updating the miner's block template.</p> Benchmarking the update</h2> In our globally distributed full block experiments, this duplication was the single largest contributor to the orphan rates we were seeing. These runs use an internal testnet of 77 to 80 nodes with CPU miners and deliberately compressed block-time bands, so the absolute numbers describe that environment, not Mainnet. The runs also include fixes that keep CPU miners from finishing a solution on a stale block.</p> In the 25-second band, the orphan rate fell from roughly 30% to about 3.6%. In the 75-second band, we measured 1.57%.</p> That puts 25-second blocks back in a safe range. Both block propagation and CPU time can still improve, and more CPU improvements are coming next week.</p> Operators with dashboards can watch the cache directly through the new zakura.consensus.halo2.cache.hit</code>, miss</code>, insert</code>, and evict</code> counters and the zakura.consensus.halo2.cache.size</code> gauge.</p> Indexer block-range streaming</h2> Indexers backfilling history through the indexer gRPC service previously paid one unary request per block, and each GetBlock</code> read the block's raw bytes from storage, fully deserialized every transaction, then re-serialized the block back to the bytes it started from.</p> Zakura 1.2.0</code> adds GetBlockRange</code>, proposed and contributed by @maxdesalle</a>. It streams a height range of finalized blocks in ascending order and serves them from the stored raw bytes, without that round trip. The stream covers only blocks committed to the finalized state and ends cleanly at the finalized tip, matching the existing contract for finalized history. Serving block ranges requires building with the indexer</code> compile-time feature.</p> Security</h2> Indexer RPC listeners are hardened.</strong> Mutual TLS is now required for indexer RPC listeners on non-loopback addresses, indexer connections and streams are bounded, and blocks without a coinbase height are rejected before state preparation.</li> Protocol services enforce their frame caps.</strong> Zakura protocol services now enforce their declared frame caps for inbound and outbound application frames, rather than declaring them and accepting larger ones.</li> </ul> Other improvements</h2> Chain work is stored at its exact width.</strong> Block work and cumulative chain work are now kept at their full 256-bit width, so valid hard targets are representable instead of failing conversion. Fork choice and the committed chain history root are unchanged for Mainnet and Testnet, and no database migration is required.</li> Maximum block time activates per network.</strong> The maximum-block-time activation height is now a per-network parameter. Configured networks and Regtest activate the MTP-plus-90-minutes rule at height 2 instead of inheriting the public Testnet height, generated local networks activate it after their seed chain, and Regtest accepts a max_block_time_start_height</code> config field. Mainnet and public Testnet behavior is unchanged.</li> </ul> End-of-support halt</h2> Zakura 1.2.0</code> keeps the 40-day support window introduced in 1.1.1</code>. Mainnet nodes running this release halt at height 3,495,707</strong> (~2026-09-23). Upgrade warnings keep their three-day lead and begin ~2026-09-20.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.2.0</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Release: Zakura 1.1.1 2026-08-10T00:00:00+00:00 We have released Zakura 1.1.1</code></a></strong>, a security and performance release. Last week we published 1.1.0</code></a> but did not blog about it at the time; this post discusses all of the changes.</p> We recommend that all node operators update immediately. This release closes block-propagation attacks that could eclipse a node during sync, let a peer repeatedly gossip invalid blocks without being penalized, or leave a mining backend working from a stale chain tip. These fixes have been introduced in coordination with Zebra.</p> In addition, this release provides substantial speedups for indexer consumers (thanks to @maxdesalle</a>), improves nodes behind NATs network connectivity, and substantially extends the end-of-support window. Further, RPC changes now allow operators to more easily learn about EOS halt dates and supported block heights.</p> Security</h2> Far-ahead blocks no longer get an honest peer banned.</a></strong> A peer was previously banned for serving a block whose height exceeded the sync lookahead limit. The ban was assigned to the peer that answered the block request, even though the far-ahead height came from whichever peer supplied the hash in an earlier FindBlocks</code> response—usually a different peer. An attacker could exploit that mismatch to get honest peers banned and eclipse a node during sync. Such blocks are still dropped without restarting sync. Peers that serve blocks with no valid height or that fail consensus verification are still scored, without blaming peers for invalid ancestors. The Zakura team reported this issue.</li> Peer-controlled singleton responses no longer stall near-tip sync.</strong> Zakura previously discarded a one-block FindBlocks</code> response while protecting against a legacy zcashd</code> quirk that can append an unrelated hash. A peer could therefore suppress the node's only unknown block, producing a zero-length sync sample that falsely made the node appear close to tip and could let /ready</code> report success while it remained behind. The only unknown hash in a qualifying short response is now downloaded, allowing the node to keep advancing. Maakai123 reported this issue in Zebra #10603</a>.</li> Peers that gossip invalid blocks are scored and banned.</a></strong> Zakura inherited security bugs that allowed a peer to keep supplying invalid blocks over the same connection. Inbound cleanup now recognizes the router's rejections and bans the responsible peer. The Zakura team reported this issue.</li> Coinbase-height malleation can no longer poison the newest block.</a></strong> A V5 or later coinbase scriptSig</code> is authorizing data and is therefore excluded from the block hash. A peer could rewrite the height in an otherwise canonical block body and still answer a request for that hash. When the block built on Zakura's own chain tip but claimed a height other than one above the tip, the poisoned body was discarded as a benign old block—unattributed, unscored, and not requeued. That delayed the newest block until the next discovery round and left a mining backend issuing work on an obsolete tip. The height check now runs on both block-download paths, sync and block gossip. Each path scores the supplying peer for a ban and immediately re-requests the hash under its own bounded retry budget. This issue was reported by Sangsoo at Ottersec as part of a security audit commissioned by the Zakura team.</li> Logging is hardened against escape attacks.</strong> Zakura now handles untrusted log content more defensively across peer-message logging and operator filtering tools.</li> Dependency hygiene.</strong> The unmaintained structopt</code> (RUSTSEC-2022-0104) and rustls-pemfile</code> (RUSTSEC-2025-0134) dependencies and their advisory-flagged transitive trees are removed, and CI now verifies the doctl</code> and rustup-init</code> binaries it downloads against pinned checksums before executing them.</li> Misbehavior scores apply promptly.</strong> Batched peer misbehavior scores reach the address book every five seconds instead of every 30, so threshold bans become visible to the listener and peer set faster. We aim to make this instant with more testing.</li> </ul> RPC parity for pruned nodes</h2> getblockchaininfo</code> now reports pruneheight</code>,</strong> the lowest height at and above which every block body is retained. As in zcashd</code>, the field is only present when pruned</code> is true. Zakura prunes raw transaction data rather than whole blocks, so blocks below this height keep their headers, transaction IDs, and consensus state, and the genesis block is never pruned.</li> The pruned</code> flag now reports configuration, not history.</strong> A node configured with storage_mode.pruned</code> previously reported pruned: false</code> until it first deleted block data, which took at least 10,000 blocks on Mainnet. As in zcashd</code>, the field now reports whether blocks are subject to pruning.</li> New getdeprecationinfo</code> RPC.</strong> It reports Zakura's Mainnet end-of-support height and an estimated halt time with a 24-hour safety margin. When the chain tip is unavailable, the estimate starts from the latest network checkpoint.</li> </ul> Operators with dashboards keyed on the read-request metric label is_pruned</code> should note it is now pruning_info</code>, since the request also reports the prune height.</p> Peer connectivity</h2> The default connection budget is rebalanced.</strong> The inbound connection limit rises from 100 to 300 while the outbound limit drops from 300 to 150. This is important for ensuring good connectivity of the p2p network and allowing new nodes to enter.</li> Outbound replenishment is restored to the configured peer set size.</strong> The crawler's dial budget targeted a share of the outbound connection limit, in order to not saturate all nodes inbound limits. Now that we've fixed the inbound/outbound ratio, we now target the crawler to filling 80% of the outbound budget.</li> Restarted nodes find peers faster.</strong> The peer address disk cache grows from 75 to 300 addresses, and the first cache write is retried every 20 seconds instead of waiting the full 5-minute update interval, so a cold-started node caches its peers soon after finding them.</li> Native discovery is more careful about what it shares.</strong> zakurad</code> now shares a discovery record with other peers only after confirming that record's owner directly, and answers each peer's GetPeers</code> requests from a bounded per-peer record set that is stable for a ten-minute window—so repeated requests, however they vary their filters, no longer walk further through the local discovery book. Records learned second-hand still serve as local dial hints, so bootstrap reach is unchanged.</li> </ul> Correct answers from fast-synced nodes</h2> This release fixes RPC behavior that could mislead wallets talking to a node bootstrapped with verified-commitment-trees (VCT) fast sync:</p> z_gettreestate</code> and z_getsubtreesbyindex</code> no longer fabricate emptiness.</strong> For heights a fast-synced node has no data for, z_gettreestate</code> returned a JSON null</code> treestate and z_getsubtreesbyindex</code> an empty list. Clients following the lightwalletd contract read an absent treestate as the empty</em> tree, so a wallet could derive a birthday anchor asserting an empty commitment tree deep in the chain with no error raised. Both now return a typed archive-mode error, and verbose getblock</code>/getblockheader</code> preserve that explanation. Re-indexing the relevant data, along with a better LWD contract are planned for subsequent releases.</li> Databases from the original VCT fast sync are rejected at startup.</strong> A Mainnet database written by the original VCT fast sync (below database format version 28.0.1) is missing the historical Sprout anchors needed to verify JoinSplits that spend a historical Sprout root. The in-place repair that used to backfill them has been removed; discard the database and resync, or restore a snapshot taken with a current release.</li> The 71 MB embedded repair artifact is gone.</strong> The zakurad validate-vct-sprout-history</code> subcommand and the embedded artifact it audited no longer apply due to EOS heights, guaranteeing every affected user has a patched upgrade.</li> New historical-treestate audit tooling.</strong> The zakurad audit-historical-treestates</code> command opens an existing state database read-only and inventories the authenticated roots and anchor frontiers needed to reconstruct the Sapling, Orchard, and Ironwood note commitment trees omitted by VCT fast sync. --scan-block-bodies</code> checks that the whole absent range is retained. With --walk</code>, the command instead validates the bodies it replays, derives trees across the requested range, and checks every sampled result against the authenticated root already stored for that height; --verify-subtrees</code> compares replayed subtree roots with stored rows above the last checkpoint. This is audit and performance-measurement tooling, not an in-place database repair.</li> Read-only tools can inspect older databases.</strong> A read-only RocksDB secondary no longer tries to open column families that an older database does not have, so audit and inspection commands can examine it without first upgrading or modifying it.</li> </ul> The audit command does not yet restore historical-tree RPC serving. In the range where a VCT fast-synced database has no per-height trees, the RPCs continue to return the typed archive-mode errors described above. Reconstructing trees also requires retained block bodies, so a pruned database cannot derive trees below its retention height.</p> Other fixes</h2> Indexer gRPC subscriptions tolerate slow consumers.</strong> Tip and mempool subscriptions now apply backpressure with a 60-second send timeout instead of being dropped the moment their buffer fills, so a briefly slow consumer no longer triggers rapid re-subscribe cycles.</li> A queued-block index leak is fixed.</strong> Dequeuing one fork sibling un-indexed another block at the same height, preventing it from being pruned and leaking entries in the block queue and its known-UTXO cache.</li> Mined-block broadcasts no longer wait for disconnected peers.</strong></li> The P2P user agent is consistent.</strong> Every transport mode now advertises the zakurad</code> release version without an internal networking crate version.</li> Higher ZIP 317 block-production weight cap.</strong> The cap rises from 4 to 10, allowing high-fee transactions to receive up to ten times the conventional weight during block-template transaction selection. This changes miners' transaction ranking, not transaction or block consensus validity.</li> </ul> Building from source</h2> Zakura now builds with GCC 15/16 without the CXXFLAGS="-include cstdint"</code> workaround, via RocksDB 10.4.2 (rocksdb</code> 0.24). The bundled librocksdb-sys</code> now always runs bindgen</code>, so libclang</code> is required at build time</strong> (in addition to protoc</code> and a C++ compiler) even when linking a system RocksDB. Install libclang-dev</code> (Debian/Ubuntu), clang</code> (Arch), or the equivalent for your platform.</p> End-of-support halt</h2> The end-of-support window is extended from 18 to 40 days after the estimated release height. Mainnet nodes running this release halt at height 3,484,507</strong> (~2026-09-15) instead of ~2026-08-24. Upgrade warnings keep their three-day lead and begin ~2026-09-12.</p> Next EOS update will be in our v1.2.0 release, expected later this week.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.1.1</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Release: Zakura 1.0.5 2026-07-28T00:00:00+00:00 We have released Zakura 1.0.5</code></a></strong>, a stability and performance release. It significantly improves restoration of p2p connectivity after long blocks, fixes two failures that could prevent a fresh node from syncing, improves peer discovery, and significantly reduces CPU overhead in address-book and metrics processing.</p> We recommend that all node operators update.</p> This release also mitigates an issue discovered yesterday on Testnet that affects both Zakura and Zebra.</strong> We identified a bug that prevents nodes from reconnecting to honest peers after a large chain reorganization. After discussion with the Zcash Foundation, both of our teams agreed to fix the issue in parallel releases ahead of the NU6.3 network upgrade.</p> Peer discovery and recovery</h2> Zakura's default P2P stack now recovers more deliberately when its peer set becomes depleted:</p> Periodic crawls replenish outbound connections.</strong> When fewer than 27% of the configured outbound connection slots are active, Zakura queues enough connection attempts to reach that target while still respecting the configured hard limit.</li> Liveness stall detection waits longer.</strong> The threshold at which stall tracking begins—and peers can consequently be disconnected—rises from Zebra's 6 minutes to 20 minutes. We believe this will help reduce the frequency of very high-latency Mainnet blocks.</li> Peer discovery returns a larger sample.</strong> Refreshed GetAddr</code> responses now contain approximately half of the eligible address book instead of one quarter, still capped at 1,000 addresses and protected by the existing ten-minute response cache.</li> Bans remove every address for the affected IP.</strong> A peer can advertise multiple ports for one canonical IP. Banning that peer now removes every matching address-book entry so stale aliases cannot interfere with later connection management.</li> </ul> Fresh-sync reliability</h2> This release fixes two independent failures in the path from genesis to the network tip:</p> Verified-commitment-tree fast sync completes its handoff.</strong> At the exact handoff height, the header-authentication lane cannot produce a database row for the Sapling, Orchard, and Ironwood roots. The commit path now uses the reviewed roots embedded in the release at that height. Heights below the handoff still require authenticated database roots, and heights above it cannot use the embedded data.</li> Legacy genesis sync no longer livelocks under ordinary peer-set saturation.</strong> Zakura 1.0.4</code> attempted to route historical block downloads only to peers advertising the full chain. This had a live-lock, and is removed in v1.0.5</code>. We will re-introduce this with more fixes in a subsequent release.</li> </ul> Address book and performance</h2> We identified the address book and its related metrics as performance bottlenecks through several independent signals. Live profiles indicated that nodes with metrics disabled still spent 30% of their CPU time in metrics code. The address book also contained ordering errors and several O(N)</code> operations. We found timeouts and sleeps delaying time-sensitive work that appeared to exist only to avoid contention while these operations held locks.</p> The address-book get, update, and ban operations are now O(log(N))</code> or O(1)</code>.</strong> We now maintain direct address, priority, and per-IP indexes. Batched address changes also publish metrics once per batch instead of rebuilding the same summary after every accepted entry.</li> Fix metrics growth from disconnected peers.</strong> The zakura.net.connection.state</code> Prometheus gauge is now aggregated by command rather than carrying a per-peer addr</code> label. Previously, disconnected peers left zero-valued time series behind indefinitely, allowing /metrics</code> and Prometheus cardinality to grow throughout long syncs. Operators whose dashboards query this gauge by addr</code> should update those queries.</li> </ul> Other improvements</h2> Mined blocks are not advertised twice when gossip events race.</strong> A completed or newly submitted mined-block event now takes priority over the committed-tip fallback when both are ready.</li> Public mempool testing tools.</strong> We added a load-testing harness for Mainnet and Testnet that verifies transactions gossip correctly.</li> </ul> End-of-support halt</h2> Zakura 1.0.5</code> retains the 1.0.4</code> support window. It supports Ironwood (NU6.3) activation and reaches end of support roughly eleven days afterward, by which point the first post-Ironwood release will be available.</p> The first post-Ironwood release will have a substantially longer EOS.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.5</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Release: Zakura 1.0.4 2026-07-26T00:00:00+00:00 We have released Zakura 1.0.4</code></a></strong>, a performance and stability release. Typical blocks now verify about 20% faster. This release also fixes bugs in the experimental P2P v2 stack, including authentication of verified-commitment-tree (VCT) fast-sync data. We also harden the default P2P networking code like in our previous two releases.</p> We recommend that miners and RPC operators update to take advantage of these significant performance improvements.</p> Faster block execution</h2> Zakura verifies signatures and proofs in batches. Near the chain tip, a partially filled batch often waited for a 100 ms timer before its cryptographic work could begin. We now immediately process these batches at block boundaries, while retaining the existing size and time triggers and leaving mempool batching unchanged.</p> In a mainnet block-processing experiment, steady-state latency fell from 681 to 591 ms per block, saving about 90 ms. This roughly 20% improvement applies to live sync as well as catch-up, with no measurable regression when verifying blocks concurrently.</p> P2P v2 authentication and reliability</h2> This release contains the largest reliability pass on Zakura's experimental P2P v2 stack since launch:</p> VCT fast-sync data is now authenticated.</strong> During checkpoint sync in the P2P v2 stack, we use additional data committed in block N+1's header to authenticate the commitment-tree data needed to execute block N. We now authenticate that additional data in the P2P layer. This prevents a malicious peer from stalling P2P v2 checkpoint sync with incorrect data. Cached data written under the previous rules is refreshed automatically during the upgrade.</li> Connections recover after temporary failures.</strong> Healthy peers can reopen block sync, header sync, discovery, and legacy-gossip services after cooldowns instead of remaining unusable until they reconnect. Closing an old service session can also no longer disconnect a newer session on the same peer connection.</li> Peer discovery finds new v2 nodes faster.</strong> Zakura now advertises usable addresses, safely connects to peers learned through discovery, refreshes their records, and discards them when they expire.</li> Block sync recovers missing downloads.</strong> If a block falls out of the download queue while later blocks are still pending, Zakura requests it again instead of buffering later blocks indefinitely and stalling sync.</li> </ul> P2P and sync hardening</h2> The inherited P2P stack remains the default networking path for live consensus nodes. Zakura 1.0.4</code> further hardens it against malformed responses and difficult network conditions:</p> Malformed chain extensions no longer disrupt sync.</strong> Legacy chain sync rejects peers that echo the requested block locator inside their advertised extension.</li> Duplicate blocks no longer leave checkpoint sync with a permanent stall.</strong> A normal resubmission of an already queued block can no longer trigger a stale verifier reset after completed blocks have left the queue.</li> Historical sync avoids pruned peers.</strong> Block requests prefer peers that advertise the full chain, reducing delays from asking pruned peers for bodies they are unlikely to retain. We remain connected to pruned nodes during live sync. This was already handled in P2P v2 and is now also handled in legacy P2P.</li> Local zcashd</code> sidecars connect reliably under inbound load.</strong> A sidecar could previously time out while waiting behind a large queue of public connections. Zakura now accepts queued connections in bounded, faster bursts and begins configured sidecar handshakes immediately, while retaining rate limits for public peers.</li> </ul> Other improvements</h2> Faster Orchard and Ironwood block template refreshes.</strong> Like the Sapling prover in 1.0.2</code>, the Orchard and Ironwood proving keys used for shielded coinbase transactions are now prepared once per process and reused, instead of being recomputed for every getblocktemplate</code> refresh.</li> CI is substantially faster.</strong> In representative runs, a merge to main</code> uses roughly one-seventh as many runner-minutes and completes about three times faster. A pull request uses about 30% fewer runner-minutes and completes roughly three times faster. Final release builds run five times faster.</li> The experimental Elasticsearch exporter is removed.</strong> External service behavior no longer runs inside the finalized-state commit path. Operators who used the exporter should contact the Zakura maintainers so we can prioritize a safer indexing API around their requirements.</li> Unused binaries are removed.</strong> The block-template-to-proposal</code> and search-issue-refs</code> binaries and their runtime dependencies are gone. The supported zakura-checkpoints</code> tool remains.</li> Rust crate APIs now enforce authenticated VCT data.</strong> This is a breaking change for crate consumers: zakura-chain</code> moves to 3.0.0</code>, while zakura-network</code> and zakura-state</code> move to 5.0.0</code>. Removing the developer binaries moves zakura-utils</code> to 2.0.0</code>. These changes do not affect node operators.</li> </ul> End-of-support halt</h2> Zakura 1.0.4</code> retains the 1.0.3</code> support window. It supports Ironwood (NU6.3) activation and reaches end of support roughly eleven days afterward, by which point the first post-Ironwood release will be available.</p> The first post-Ironwood release will have a substantially longer EOS.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.4</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Release: Zakura 1.0.3 2026-07-22T00:00:00+00:00 We have released Zakura 1.0.3</code></a></strong>, a security and stability release. It marks the zcashd</code> compatibility mode</a> as stable for the Ironwood (NU6.3) network upgrade. It also addresses some security issues, continues to harden the inherited P2P stack, and fixes edge cases in mempool behavior.</p> All node operators should update both their Zakura and zcashd</code> compatibility binaries.</p> zcashd</code> compatibility mode</h2> As with our last release</a>, this release fixes several bugs in zcashd</code> compatibility mode</a>, thanks to battle-testing from partners. Most importantly, the managed zcashd</code> process could previously fail to follow the NU6.3 network upgrade on mainnet even though the underlying zakura</code> process did, leaving the zcashd</code> wallet stalled.</p> After extensive compatibility and network-upgrade testing, Zakura 1.0.3</code> pins valargroup/zcashd</code> 1.1.0</a> for both managed installations and the split-container Docker image, and we now consider the compatibility mode stable and ready for Ironwood.</p> P2P, mempool, and sync hardening</h2> We continue to harden the legacy P2P stack inherited from Zebra, which remains the default networking path for live consensus nodes:</p> Peer banning is now O(1).</strong> Adding and evicting retained bans previously became more expensive as the ban list filled, because each operation copied or shifted the existing list. Membership checks, insertions, and evictions now take constant time.</li> Equivalent IP representations can no longer bypass enforcement.</strong> IPv4 and IPv4-mapped IPv6 addresses are now treated as the same peer when applying bans, inbound rate limits, and per-IP connection limits.</li> Malformed block-discovery responses no longer disrupt sync.</strong> There were several ways a peer could reply with hashes that would disrupt the node's active sync attempt. These responses are now rejected.</li> </ul> This release also fixes two cases where the mempool and outbound gossip state could disagree:</p> Mempool gossip no longer silently drops legitimate transactions.</strong> When the mempool was at capacity, valid transactions could be silently dropped from outbound gossip and never announced to peers. The gossip flow no longer permanently omits them when it falls behind.</li> The mempool no longer gossips transactions whose parents were removed.</strong> When an expired transaction caused its descendants to be removed, only the directly expired transaction was previously reported to the gossip layer. All removed descendants are now cleared from pending gossip as well.</li> </ul> We also harden consensus state and syncing behavior:</p> Corrupt history-tree caches now fail closed.</strong> Malformed bytes, caches from the wrong network, and invalid caches that are empty or predate Heartwood now produce clean errors instead of crashing the node. The valid database format is unchanged.</li> Mainnet checkpoints are updated, and refreshing them is now automated.</strong> Zakura 1.0.3</code> extends checkpoint sync from height 3,358,006 to 3,418,406. Checkpoint and verified-commitment-tree frontier refreshes now run through an automated pipeline: an offline export produces a provenance record that CI verifies, refreshed data is checked against its expected digests before landing in reviewable draft pull requests, and pre-release checks confirm that checkpoints, frontiers, and provenance stay consistent.</li> </ul> Security (GHSA-x93j-mj2f-q338)</h2> In coordination with the Zcash Foundation, Zakura 1.0.3</code> extends the hardening for GHSA-x93j-mj2f-q338</a> that shipped in 1.0.2</code>. Rejected non-finalized block hashes are now drained before known-block checks, allowing an honest block body with the same hash to be retried immediately instead of waiting for another state request to process the rejection.</p> The issue allowed a remote, unauthenticated peer that won a block-propagation race to deliver a rejected block body sharing its header hash with a valid block. A stale rejection could then prevent the valid block's children from being accepted, stalling the node for roughly 2,000 blocks. The issue could not cause a crash, state corruption, consensus divergence, or acceptance of an invalid chain.</p> During this release cycle we built a hotfix release path, rehearsed it against private staging infrastructure, and hardened the checklist and process documentation that a security release follows.</p> Security (GHSA-2p4c-3q4q-p463)</h2> GHSA-2p4c-3q4q-p463</a> was reported to the Zcash Foundation by craftsoldier</a>. Zakura had already mitigated the reported issues in 1.0.2</code>.</strong></p> The report found that Zebra's mempool exposed nodes to a denial-of-service attack involving transactions as large as 2 MB, and that peers were not banned in many real-world error paths. An attacker could repeatedly submit transactions containing large numbers of invalid Orchard proofs. When batch verification failed, the verifier entered a slow path that checked each proof individually, causing substantial CPU load. Because the offending peer was not banned, the attacker could sustain this load and delay block processing.</p> Zakura proactively addressed these issues as part of the mempool-hardening work released in 1.0.2</code>. Among other changes, Zakura now bans peers that submit invalid Orchard proofs and rejects transactions larger than a configurable limit (250,000 bytes by default) from the mempool.</p> RPC and indexer reliability</h2> Zakura deployments can run a separate read-only database for RPC and indexing. This release closes several synchronization races in that path: subscriptions resume from the read-only database's known chain tips, streamed blocks use bounded backpressure instead of being dropped, and a lagging read-only instance can fetch the finalized blocks needed to bridge a gap. Catch-up handoffs, retries, and stream timeouts are also bounded, so RPC availability recovers cleanly after restarts or delays.</p> Verbose block-header metadata now stays bound to the block that was originally resolved, even if the best chain reorganizes during the request.</p> This release also cleans up user-facing text: getrawtransaction</code> now reports Transaction not found in mempool or best chain</code>, and remaining references to Zebra in logs, errors, RPC responses, CLI help, and operator tooling now say Zakura. We thank @dismad</a> for suggesting the clearer RPC wording and @ambimorph</a> for reporting the stale branding</a>.</p> Other improvements</h2> disable_pow</code> now applies to native header sync.</strong> Header sync now honors disable_pow = true</code> on configured testnets, matching the block-verification paths that already honored it.</li> The zakura-chain</code> public API is slimmer.</strong> Unused public errors, constants, and helper methods have been removed to keep the library API focused. This is a breaking change for crate consumers; it does not affect node operators.</li> Transaction digests are faster.</strong> Fixed ZIP-244 hashes for absent transaction bundles are now cached. In an Ironwood-only benchmark, computing the authorizing-data digest was 2.8% faster, and computing the transaction ID and authorizing-data digest together was 5.6% faster.</li> Tests are more deterministic.</strong> Acceptance tests now wait for observable readiness instead of fixed sleeps, removing avoidable test latency, and zakurad</code> test binaries no longer hit a log-capture race that could corrupt tracing span bookkeeping.</li> Header sync groundwork continues.</strong> We added a specification for a fork-aware header chain engine, preparing for the next stage of native header sync.</li> </ul> End-of-support halt</h2> Zakura 1.0.3</code> supports Ironwood (NU6.3) activation and reaches end of support roughly eleven days after it, by which point the first post-Ironwood release will be available.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.3</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Release: Zakura 1.0.2 2026-07-20T00:00:00+00:00 We have released Zakura 1.0.2</code></a></strong>, a stability and performance release. It makes the zcashd</code> compatibility mode</a> substantially more reliable, and fixes a number of other bugs. We recommend that all node operators update.</p> zcashd</code> compatibility mode</h2> zcashd</code> compatibility mode</a> runs a real zcashd</code> process with the Zakura node as its only peer, so software that still speaks the old RPC interface keeps working. Its most visible problem, zcashd</code> occasionally stalling behind the chain tip, turned out to have three distinct causes, and this release fixes all of them:</p> Block announcements are no longer dropped.</strong> An announcement to a momentarily busy zcashd</code> was silently skipped with no retry, and on nodes that mine locally, queued announcements were canceled before ever reaching the wire. Announcements are now queued and delivered as soon as zcashd</code> is ready.</li> Zakura no longer disconnects its own zcashd</code>.</strong> Under heavy load, Zakura's denial-of-service protection could randomly disconnect the operator's own zcashd</code>, and per-IP connection limits could stretch one disconnect into a multi-second blackout. The configured zcashd</code> is now never disconnected: its requests are still shed under load, and protection for every other peer is unchanged.</li> Supervision is more complete.</strong> Zakura now shuts down its managed zcashd</code> process when it exits, enables the complete legacy wallet RPC surface by default (with -allowdeprecated=none</code> as the opt-out), works when Zakura itself runs pruned, and reports an actionable error when zcashd</code> requests a block body that pruning has dropped.</li> </ul> Other improvements</h2> Mempool hardening.</strong> The mempool now favors protecting miners and RPC operators, with trade-offs chosen to preserve every real usage pattern we have seen. Transactions larger than a configurable limit (250,000 bytes by default) are now rejected, many kinds of rejection are faster and cheaper, and peer penalties follow the root cause of what actually went wrong, limiting what a malicious peer can do. We also avoid an edge case where peers can get banned at the NU6.3 upgrade boundary.</li> Faster block template refreshes.</strong> The bundled Sapling proving parameters are now parsed once per process and the prover is shared, instead of being re-parsed on every getblocktemplate</code> refresh, and mempool metrics are maintained incrementally rather than recomputed from a full mempool scan after every change.</li> Faster transparent signature checks.</strong> Signature-hash components that are shared across a transaction's inputs are now computed once and reused for every transparent signature check, instead of being recomputed per signature.</li> Pruned nodes no longer advertise blocks they cannot serve.</strong> Responses to legacy peers no longer include blocks whose bodies pruning has dropped.</li> Peer addresses stay out of logs by default.</strong> Peer activity logs and metrics keep using redacted, privacy-preserving peer IDs; operators who need raw addresses in their trace files can opt in with the new network.expose_peer_addresses</code> setting.</li> Sync fixes.</strong> Early-chain difficulty validation now applies the proof-of-work limit correctly at the averaging-window boundary, and header sync now schedules only forward ranges from the durable verified tip instead of backfilling backward.</li> </ul> Sprout history repair in experimental fast sync</h3> Fresh verified-commitment-tree (VCT) fast sync, part of Zakura's experimental P2P stack, did not persist the chain's historical Sprout note-commitment history. An affected node runs normally until a transaction spends against a historical Sprout anchor, which the node can then no longer validate against its local state. Only mainnet databases created by fast sync over the experimental transport are affected, and the experimental stack is off by default.</p> Zakura 1.0.2</code> fixes the bug and repairs affected databases automatically. At startup, Zakura restores the missing history from a reviewed copy of the mainnet Sprout history, distributed as exact-versioned crates.io packages, and validates it before writing any repaired state. The repair is crash-safe: an interruption restarts it rather than skipping it, and an affected database refuses to run until its repair completes.</p> You can also audit the result yourself: a new read-only command, zakurad validate-vct-sprout-history</code>, checks the historical Sprout anchors of any mainnet database, archive or pruned, against the reviewed history. And if you would rather not repair in place, redownloading a snapshot</a> or resyncing from genesis also produces a correct database.</p> End-of-support halt</h2> Zakura 1.0.2</code> supports Ironwood (NU6.3) activation and reaches end of support roughly ten days after it, by which point the first post-Ironwood release will be available. Nodes still on 1.0.1</code> reach end of support roughly one week after activation: they will begin warning about the required update a few days beforehand and then halt. We recommend updating now rather than during the activation window.</p> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.2</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Release: Zakura 1.0.1 2026-07-17T00:00:00+00:00 We have released Zakura 1.0.1</code></a></strong>, a security release. It fixes three issues that our team discovered in upstream Zebra</a> and that affect Zakura 1.0.0</code>. We recommend that all node operators update immediately.</p> Security fixes</h2> This release includes the following fixes. All three issues are denial-of-service vectors: an attacker could degrade or stall a node's block validation or mining. Our teams consider these kinds of issues high severity for miners.</strong> But none of them can lead to loss of user funds, crashes, state corruption, or consensus divergence.</p> Quadratic block processing time</strong> (GHSA-4g24-549m-hp75</a>). Transparent transactions in blocks were verified with an algorithm whose running time grows quadratically, which an adversary could exploit to stall block validation without mining a malicious block themselves. In our measurements, the stall could last nearly 52 seconds on fast hardware.</li> Remote validation poisoning</strong> (GHSA-g7c4-2w6c-cr3r</a>). Nodes did not track which peers sent them transactions that violate consensus rules, including transactions with invalid proofs. Orchard proofs, for example, are verified in batches, and proofs from all sources feed into a shared verification pipeline; a malicious peer could therefore poison batches with invalid proofs without being identified or penalized. A failed batch forces block processing onto an expensive fallback path, allowing sustained degradation of a node's block validation performance, on the order of tens of seconds.</li> Oversized block templates</strong> (GHSA-95m2-vx53-v2jw</a>). The getblocktemplate</code> RPC could produce block templates that violated the allowed block size, because parts of the serialized block, such as the header, were not counted toward it. An adversary could provoke this deliberately to stall mining on a targeted node, for example one producing blocks for a mining pool.</li> </ul> Coordinated disclosure</h3> Our team discovered these issues in Zebra prior to the initial release of Zakura, which inherited them. We performed our 1.0.0</code> release as planned and began coordinated disclosure with the Zcash Foundation</a> immediately afterward. Zebra fixes these issues in version 6.1.0</code></a>, released alongside Zakura 1.0.1</code>.</p> We thank the Zcash Foundation for responding promptly and coordinating these fixes with our team.</p> Our team also privately disclosed these vulnerabilities to Shielded Labs at the same time. However, due to time constraints and differing priorities, they are not part of this coordinated software release.</p> End-of-support halt</h2> Anticipating that these issues would need to be remediated immediately after launch, we shipped 1.0.0</code> with its EOS halt set just one week after release. 1.0.0</code> nodes will begin warning about the required update within days and will halt shortly afterward. Zakura 1.0.1</code> reaches end of support roughly one week after Ironwood (NU6.3) activates.</p> Other improvements</h2> This release also contains performance and stability improvements:</p> Initial sync now runs in bounded memory.</strong> During initial sync, blocks download faster than they can be verified, and the backlog was held as fully decoded blocks, which are several times larger than their wire encoding. Memory use therefore grew with the chain itself. The backlog is now kept in serialized form and decoded only as blocks enter verification, which turns the sync look-ahead budget (1.5 GiB by default) into a real memory bound. Memory use is also tracked through the sync pipeline and exported as metrics, so a syncing node's memory behavior can be watched on a dashboard rather than inferred from RSS.</li> Fewer ways for initial sync to stall.</strong> Header ranges that time out are now retried indefinitely, briefly avoiding the peers that failed them, and bookkeeping at checkpoint boundaries no longer leaves verification capacity sitting idle. Heights whose blocks add no Sapling commitments are no longer mistaken for gaps in sync coverage, and pruned nodes (which have dropped old block bodies) no longer invent metadata for blocks they no longer store.</li> Stricter with untrusted bytes.</strong> ZIP-244 transaction IDs, and therefore the block hash, don't commit to signatures, proofs, or transparent unlocking scripts, so a block body with the correct hash can still carry altered authorizing data. Block bodies from cache or from peers are now also checked against the authorizing-data root, and a body with the right hash but the wrong authorizing data is rejected as permanently invalid instead of retried. Oversized FindBlocks</code> responses from legacy peers are rejected before they touch state lookups, and invalidating a block now removes every fork built on it, not just one of them.</li> </ul> Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.1</code> via Cargo. See the download page</a> for installation and verification instructions.</p> Introducing Zakura 2026-07-15T00:00:00+00:00 </div> Zakura</a> is a new full node implementation for the Zcash</a> network, built for scale. It is free and open-source software. Today, we're releasing 1.0.0</code></a>.</strong></p> What's Zakura?</h2> Forked from Zebra</a>, Zakura is a consensus-compatible Zcash full node. Its initial release already supports Ironwood (NU6.3), which activates later this month; our teams are largely responsible for Ironwood's implementation and coordination.</p> Zakura is a collaboration between Valar Group</a> and Project Tachyon</a>. Our teams are building the next generation of Zcash's protocol, and Zakura will be ground zero for integrating it into the real network.</p> This first release brings major improvements over existing Zcash node software:</p> Performance</strong>: Blockchain sync is nearly 5× faster than Zebra.</li> Pruning and snapshots</strong>: Native block pruning with configurable retention cuts disk usage substantially. We also publish snapshots</a> (~11 GB pruned) that let you bootstrap a node 680× faster than syncing over the standard P2P network.</li> zcashd</code> compatibility</strong>: A compatibility mode</a> reproduces the legacy zcashd</code> RPC interface, so existing wallets and integrations keep working.</li> Experimental P2P layer</strong>: We are building a new P2P transport layer for Zakura nodes, currently off by default. The goals: sub-500ms</code> worst-case block propagation, mempool aggregation (used in Tachyon), and a future-proofed gossip protocol with strict DoS resistance built in.</li> </ul> Zakura block sync finishes in 4h 20m versus Zebra's 20h 46m in this run; snapshots reduce bootstrap time further, down to 37m 9s for archive and 1m 50s for pruned.</figcaption> </figure> Zakura syncs mainnet from the network far faster than Zebra in this trace, reaching the chain tip while Zebra is still in the sandblasting range.</figcaption> </figure> Why fork?</h2> Our dream is for Zcash to support the world's payments. Mastercard and Visa handle more than 50k transactions per second; that's our floor</strong>. With Zcash's existing cryptography, that volume would demand over 500MB/s of throughput from the node. The current stack won't get us there.</p> The cryptography our teams are developing closes much of that gap. Tachyon's recursive proofs bring the requirement down to 100MB/s, and Valar Group is developing PIR</a> solutions that let wallet software support unbounded TPS, up from the 1 TPS ceiling of today's stack.</p> But cryptography is only part of the solution. We need consensus node software capable of high-performance networking at this scale. That's why we're building Zakura.</p> Maintainers</h2> Zakura is maintained by Sean Bowe and Dev Ojha, veteran protocol engineers.</p> Sean Bowe</strong> is a cofounder of Zcash and the cryptographic engineer leading Project Tachyon. Hired in 2015 at Electric Coin Co., the company that launched Zcash the following year, he has been responsible for the network's zk-SNARK cryptography implementations at launch and in every network upgrade in the decade since, coauthoring several academic papers to support that work.</li> Dev Ojha</strong> is a legendary cryptographic engineer who cofounded Osmosis and now leads Valar Group, bringing frontier PIR-based cryptography (among other things) to Zcash. His team is largely responsible for the major engineering and performance work in this initial Zakura release.</li> </ul> Both Project Tachyon and Valar Group are funded by private ZEC donations.</p>

`Updating</h2>You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.3.0</code> via Cargo. See the download page</a> for installation and verification instructions.</p>`

End-of-support halt</h2>
Zakura `1.2.0</code> keeps the 40-day support window introduced in 1.1.1</code>. Mainnet nodes running this release halt at height 3,495,707</strong> (~2026-09-23). Upgrade warnings keep their three-day lead and begin ~2026-09-20.</p>`

`Updating</h2>You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.2.0</code> via Cargo. See the download page</a> for installation and verification instructions.</p>`

Updating</h2>
You can update using our signed release binaries</a> or by upgrading the `zakura</code> crate to 1.1.1</code> via Cargo. See the` `download page</a> for installation and verification instructions.</p>`

`Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.5</code> via Cargo. See the download page</a> for installation and verification instructions.</p>`

`Updating</h2> You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.4</code> via Cargo. See the download page</a> for installation and verification instructions.</p>`

End-of-support halt</h2>
Zakura `1.0.3</code> supports Ironwood (NU6.3) activation and reaches end of support roughly eleven days after it, by which point the first post-Ironwood release will be available.</p>`

`Updating</h2>You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.3</code> via Cargo. See the download page</a> for installation and verification instructions.</p>`

`Updating</h2>You can update using our signed release binaries</a> or by upgrading the zakura</code> crate to 1.0.2</code> via Cargo. See the download page</a> for installation and verification instructions.</p>`

Updating</h2>
You can update using our signed release binaries</a> or by upgrading the `zakura</code> crate to 1.0.1</code> via Cargo. See the` `download page</a> for installation and verification instructions.</p>`

zakura - Announcements

Release: Zakura 1.3.0

Zakura Common: High Performance Zcash Cryptography

Release: Zakura 1.2.0, 87% faster full block processing

Release: Zakura 1.1.1

Release: Zakura 1.0.5

Release: Zakura 1.0.4

Release: Zakura 1.0.3

Release: Zakura 1.0.2

Release: Zakura 1.0.1

Introducing Zakura