# Release: Zakura 1.1.1

Announcement dated 2026-08-10 for Zakura 1.1.1, a security and performance
release. Zakura 1.1.0 was published the previous week without an announcement
(changelog:
https://github.com/zakura-core/zakura/blob/main/CHANGELOG.md#110---2026-08-05);
this post covers the changes from both releases.

What the announcement says:

- All node operators should update immediately.
- The 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 were
  introduced in coordination with Zebra. The release also speeds up indexer
  consumers (thanks to @maxdesalle), improves connectivity for nodes behind
  NAT, substantially extends the end-of-support window, and adds RPC data
  that lets operators learn end-of-support halt dates and supported block
  heights more easily.
- A peer is no longer banned for correctly serving a requested block whose
  height exceeds the sync lookahead limit. The far-ahead height came from the
  peer that supplied the hash in an earlier `FindBlocks` response, usually not
  the peer that later answered the block request. An attacker could exploit
  the attribution mismatch to get honest peers banned and eclipse a node
  during sync. Far-ahead blocks are still dropped without restarting sync;
  blocks with no valid height or that fail consensus verification still score
  the responsible peer. The Zakura team reported this issue. Advisory:
  https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-qhr3-cvch-5fh2.
- Peer-controlled singleton responses no longer stall near-tip sync. Zakura
  previously discarded a one-block `FindBlocks` response while protecting
  against a legacy `zcashd` 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` report success while it remained behind. The only unknown
  hash in a qualifying short response is now downloaded. Maakai123 reported
  the issue in Zebra #10603:
  https://github.com/ZcashFoundation/zebra/issues/10603.
- Peers that gossip invalid blocks are now scored and banned. Gossiped blocks
  pass through the block-verifier router, but inbound cleanup previously
  recognized only semantic-verifier errors. Other production-path rejections
  left the advertising peer unscored, allowing it to keep supplying invalid
  blocks over the same connection. Cleanup now recognizes router rejections
  and scores the responsible peer for a ban. The Zakura team reported this
  issue. Advisory:
  https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8hh2-hrf2-cqf4.
- Coinbase-height malleation can no longer poison the newest block. A V5 or
  later coinbase `scriptSig` is authorizing data and is excluded from the
  block hash, so a peer could rewrite its height in an otherwise canonical
  body while still answering the requested hash. A poisoned body building on
  Zakura's chain tip was previously discarded as a benign old block without
  attribution, scoring, or requeueing. That delayed the newest block until
  the next discovery round and left mining backends issuing work on an
  obsolete tip. Sync and block gossip now check the height, score the peer for
  a ban, and immediately re-request the hash under separate bounded retry
  budgets. Sangsoo at Ottersec reported this issue during a security audit
  commissioned by the Zakura team. Advisory:
  https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-g95h-hw6g-pvgv.
- Other security hardening: logging and operator filtering tools handle
  untrusted content more defensively; the unmaintained `structopt` and
  `rustls-pemfile` dependency trees are removed; and CI verifies downloaded
  `doctl` and `rustup-init` binaries against pinned checksums.
- 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. The team aims to make this instant with more testing.
- The new `zakurad audit-historical-treestates` 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` checks that
  the whole absent range is retained. With `--walk`, it validates the bodies
  it replays, derives trees across the requested range, and checks every
  sampled result against the authenticated root stored for that height;
  `--verify-subtrees` compares replayed subtree roots with stored rows above
  the last checkpoint. This is audit and performance-measurement tooling, not
  an in-place database repair.
- Read-only RocksDB tools no longer try to open column families an older
  database does not have, so audit and inspection commands can examine older
  databases without upgrading or modifying them first.
- The historical-treestate audit command does not restore historical-tree RPC
  serving. In the absent range, `z_gettreestate`, `z_getsubtreesbyindex`, and
  related verbose block fields continue to return typed archive-mode errors.
  Reconstruction requires retained block bodies, so a pruned database cannot
  derive trees below its retention height.
- The ZIP 317 block-production weight ratio 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 affects miners'
  transaction ranking, not consensus validity.
- `getblockchaininfo` now reports `pruneheight`, the lowest height at and
  above which every block body is retained. As in `zcashd`, the field is only
  present when `pruned` 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.
- The `pruned` field now reports whether blocks are subject to pruning, not
  whether any block has been deleted yet. Previously a node configured with
  `storage_mode.pruned` reported `pruned: false` until it first deleted block
  data.
- A new `getdeprecationinfo` RPC reports Zakura's Mainnet end-of-support
  height and an estimated halt time with a 24-hour safety margin.
- The read-request metric label `is_pruned` is renamed to `pruning_info`;
  dashboards and alerts keyed on the old label need updating.
- The default inbound connection limit rises from 100 to 300 and the default
  outbound limit drops from 300 to 150, improving P2P connectivity and making
  room for new nodes to enter the network.
- The crawler previously targeted a share of the outbound connection limit to
  avoid saturating nodes' inbound limits. With the inbound/outbound ratio
  fixed, it now targets 80% of the outbound budget.
- The peer address disk cache grows from 75 to 300 addresses, and the first
  cache write is retried every 20 seconds, so restarted and cold-started
  nodes find dialable peers faster.
- Native discovery shares a peer's record only after confirming its owner
  directly, and answers `GetPeers` requests from a bounded per-peer record
  set that is stable for ten minutes, so repeated requests cannot enumerate
  the local discovery book. Second-hand records still serve as local dial
  hints.
- `z_gettreestate` no longer returns a JSON `null` treestate, and
  `z_getsubtreesbyindex` no longer returns an empty list, for heights a
  verified-commitment-trees (VCT) fast-synced node has no data for; both now
  return a typed archive-mode error. Previously a wallet following the
  lightwalletd contract could derive a birthday anchor asserting an empty
  commitment tree deep in the chain with no error raised. Re-indexing the
  relevant data and improving the lightwalletd contract are planned for later
  releases.
- A Mainnet database written by the original VCT fast sync (below database
  format version 28.0.1) is rejected at startup instead of repaired in
  place; such a database must be discarded and resynced, or replaced with a
  snapshot taken by a current release. The `zakurad
  validate-vct-sprout-history` subcommand and the 71 MB embedded repair
  artifact are removed because end-of-support heights guarantee every affected
  user has upgraded to a patched release.
- Indexer gRPC tip and mempool subscriptions apply backpressure with a
  60-second send timeout instead of being dropped when their buffer fills.
- A queued-block index leak is fixed, mined-block broadcasts no longer wait
  for disconnected peers, and every transport mode advertises the `zakurad`
  release version in its P2P user agent.
- Zakura now builds with GCC 15/16 without workarounds via RocksDB 10.4.2,
  and `libclang` is required at build time in addition to `protoc` and a C++
  compiler.
- End of support: the window is extended from 18 to 40 days after the
  estimated release height. Mainnet nodes running 1.1.1 halt at height
  3,484,507 (~2026-09-15); upgrade warnings begin ~2026-09-12. The next
  end-of-support update is expected in Zakura 1.2.0 later this week.
- Update using signed release binaries or the `zakura` crate 1.1.1.
  Installation and verification instructions are at
  https://zakura.com/download/.

---

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