# Release: Zakura 1.0.4

Announcement dated 2026-07-26 for Zakura 1.0.4, a performance and stability
release.

What the announcement says:

- Miners and RPC operators are encouraged to update to take advantage of the
  release's significant performance improvements.
- Typical blocks now verify about 20% faster. Zakura immediately processes
  partial signature and proof batches at block boundaries instead of commonly
  waiting for the 100 ms batch timer. In a mainnet experiment, steady-state
  block latency fell by about 90 ms. The improvement applies to live sync and
  catch-up, with no measured concurrent-verification regression.
- During checkpoint sync in the P2P v2 stack, Zakura uses additional data
  committed inside block N+1's header to authenticate the commitment-tree data
  needed to execute block N. That additional data is now authenticated in the
  P2P layer. This prevents incorrect data from stalling checkpoint sync. Cached
  data written under the previous rules is refreshed automatically during the
  upgrade.
- The experimental P2P v2 stack receives a broad reliability pass. Services
  reopen after cooldowns, peer discovery finds new v2 nodes faster,
  header reanchoring preserves valid work, missing downloads are requested
  again instead of stalling sync, and stale session cleanup cannot close newer
  sessions.
- Continuing the hardening work from the previous two releases, the default
  P2P stack rejects malformed chain extensions and no longer lets a benign
  duplicate block submission leave checkpoint sync with a permanent stall.
  Historical sync avoids asking pruned peers for block bodies they are unlikely
  to retain, while pruned peers remain eligible during live sync. P2P v2
  already made this distinction; version 1.0.4 adds it to legacy P2P.
- Configured local `zcashd` sidecars are admitted promptly even behind a large
  public inbound backlog, while public-peer rate limits remain in place.
- Orchard and Ironwood block template refreshes are faster. The proving keys
  used for shielded coinbase transactions are prepared once per process and
  reused, extending the optimization Zakura 1.0.2 introduced for Sapling.
- CI is substantially faster. In representative runs, merges to main use
  roughly one-seventh as many runner-minutes and complete about three times
  faster. Pull requests use about 30% fewer runner-minutes and complete roughly
  three times faster. Final release builds run five times faster.
- The experimental embedded Elasticsearch exporter is removed from the
  finalized-state commit path. Users of the feature should contact the
  maintainers about requirements for a safer indexing API.
- The unused `block-template-to-proposal` and `search-issue-refs` developer
  binaries and their runtime dependencies are removed. `zakura-checkpoints`
  remains.
- Rust crate versions: VCT authentication deliberately changes public APIs.
  `zakura-chain` moves to 3.0.0, `zakura-network` and `zakura-state` move to
  5.0.0, and removal of the developer binaries moves `zakura-utils` to 2.0.0.
  These major versions do not change how operators run `zakurad`.
- End of support: Zakura 1.0.4 retains the 1.0.3 support window, spans Ironwood
  (NU6.3) activation, and reaches end of support roughly eleven days afterward,
  by which point the first post-Ironwood release will be available.
- The first post-Ironwood release will have a substantially longer
  end-of-support window.
- Update using signed release binaries or the `zakura` crate 1.0.4.
  Installation and verification instructions are at
  https://zakura.com/download/.

---

Canonical HTML version: https://zakura.com/announcements/zakura-1-0-4/