Release: Zakura 1.5.0

We have released Zakura 1.5.0. This release includes significant speedups to block processing times, stops getblocktemplate from returning transient errors when the chain tip moves, and upgrades the transport used by our experimental P2Pv2 stack.

We recommend that users update. Miners benefit the most from the template and latency work, and nodes still running 1.4.0 halt at the start of October regardless.

Lower Block Commit Latency

Committing a block sits on the propagation-critical path: a miner cannot build on a block its node has not committed. 1.4.0 removed final verification from that path, and 1.5.0 reduces the cost of the commit itself. Retained non-finalized headers are now checked in memory instead of being read from disk one at a time, blocks without transparent prevout spends skip an unused UTXO snapshot entirely, and transparent spends are validated against borrowed UTXO indexes instead of a clone of the complete UTXO set.

Header transitions, checkpoint finalization, and sync header processing on an unchanged chain also do less work, and the two unspent_utxo_snapshot duration metrics are gone along with the snapshots they measured.

Steadier Mining Templates

getblocktemplate no longer fails when the chain moves underneath it. Templates whose parent changed while they were being built, whether from a new block, an equal-height reorg, or a concurrent caller selecting the new tip first, are rebuilt instead of returning a template parent changed; retry error that made miners drop their current job. The fallback-recovery path rebuilds superseded templates the same way, so miners keep receiving work when the tip moves during proposal validation.

Template construction is also cheaper and better scheduled. Assembling a template no longer generates an extra shielded coinbase proof, reducing getblocktemplate latency for shielded mining addresses. Proof construction runs off the RPC workers under a shared concurrency limit, empty templates with precomputed coinbases skip the proof queue so a tip change can return work while another proof build runs, and idle internal mining solvers wake when new work arrives instead of sleeping for up to 20 seconds.

The Mempool Waits for Sync

Nodes that are far behind the chain tip cannot judge mempool transactions correctly. On Mainnet, the mempool now activates only when sync throughput looks near-tip and a local-clock estimate places the node within 100 blocks of the network tip, and it disables again, notifying subscribers, if that estimate ever exceeds the 1,000-block rollback window. Peers are penalized for failed transaction verification only while the node is near the tip and verified against the current tip height, and branch-ID and lock-time mismatches no longer penalize peers at all. Test networks bypass the clock estimate so sparse mining does not disable their mempools.

P2Pv2 Improvements

Our experimental P2Pv2 stack moved to Iroh 1.1 and noq 1.2 through our published compatibility crates, keeping the existing cryptographic dependencies and network defaults. Native peers now require protocol 2: mixed old-and-new dual-stack peers keep talking over legacy TCP, while native-only peers must share a transport cohort.

Endpoint behavior is stricter. Configured native UDP ports that are already occupied now fail startup instead of silently binding another port, endpoints bind only the configured address family, and automatic router port mapping is disabled. For nodes behind NAT there is a new opt-in, network.zakura.nat_traversal, disabled by default: enabling it allows candidate address exchange and UDP probes with native peers, and does not enable relays or external discovery.

The stack also received another reliability pass:

• Block sync settles every request exactly once. Expired, canceled, and reset requests immediately return their unsent heights and preserve any bodies already received, slow peers get time to answer initial probes without weakening the rescue deadline for measured peers, and ready blocks are requested promptly when a provider's latency estimate expires.
• Checkpoint sync recovers instead of restarting. Transient UTXO lookup and verification timeouts retry the affected blocks while parent commits finish, forged checkpoint-handoff heights are rejected, and sync keeps moving after the final checkpoint when fully verified blocks are already queued.
• Peer serving is fairer. Pruned nodes no longer advertise block bodies they no longer retain, auxiliary suppliers rotate after repairs and refusals so each waiting peer gets a turn, serving leases no longer prevent old forks from being pruned, and idle peers cannot hold every general serving slot between requests.
• Forks stay workable at the retention limit. Newly accepted forks remain available for extension, evicted blocks can be downloaded again, and shared transaction outputs survive fork removal so pending block verification can continue.

Other Improvements

• ZEC-valued RPC responses parse reliably. getblockchaininfo and other ZEC-valued responses no longer fail with loss of precision parsing ZEC value, which affected roughly one in seven value pool balances.
• Fork recovery accepts replacement blocks. Recovery no longer rejects them using block size estimates that belong to another branch.
• Custom networks fail early, not at runtime. Funding-stream address periods, halvings before Blossom, and Regtest halving heights are computed correctly on configured networks, and configurations that would panic later, such as non-positive halving intervals or Regtest setups with too few mandatory checkpoints, are rejected when the configuration is read.
• Network-policy changes are diagnostic. Header-chain startup audits stored data under the configured policy, warns, and updates the stored digest automatically after a successful audit.
• Trusted secondary nodes prepare for first-received mining. They now carry the primary's block receipt order and reset it when the primary process changes. Restarting the primary temporarily lowers the secondary's reported height to its finalized tip while recent blocks reload.

Crate Consumers

Zakura Common is now at 2.0.0, which replaces the upstream zcash_protocol, zcash_address, and zcash_transparent dependencies with the zakura-protocol, zakura-address, and zakura-transparent forks. Each crate's changelog lists its exact changes.

Zakura common's 2.0.0 upgrade additionally improves the Ironwood prover speed, and Sapling verifier times.

End of Support

Mainnet zakurad nodes running 1.5.0 halt at height 3,528,681 (estimated 2026-10-25); upgrade warnings begin three days earlier. Nodes still running 1.4.0 halt at height 3,504,731 (estimated 2026-10-03).

Updating

You can update using our signed release binaries or by upgrading the zakura crate to 1.5.0 via Cargo. See the download page for installation and verification instructions.