# Release: Zakura 1.7.0

Announcement for Zakura 1.7.0, released 2026-10-22. Every Mainnet node
must update to 1.7.0.

The headline claims: Zakura 1.7.0 activates NU7 on Zcash's Mainnet at
block height 3,543,405 (assigned by ZIP 259; expected around 00:50 UTC
on 6 November 2026, which is the evening of 5 November in US time
zones, with the height authoritative and the time a wall-clock
estimate); earlier Zakura releases halt before activation
(1.6.0 halts at height 3,536,467, estimated 1 November 2026); and the
experimental P2Pv2 stack moves from the Iroh library to `zakura-quic`,
Zakura's own QUIC transport built on upstream `quinn-proto`.

## NU7 on Mainnet

NU7 brings 25-second target block spacing, the ZIP 218 per-block
shielded action limits, and the Network Sustainability Mechanism to
Mainnet. Issuance is unaffected, and height-based protocol rules such
as funding streams are adjusted to the new block interval. Zakura's
team led the development and specification of ZIP 218 and performed
extensive stress testing ahead of the upgrade
(https://zakura.com/engineering/25-second-block-time-update/). NU7
activated on Zcash's public Testnet at height 4,465,026 in
early October 2026 with Zakura 1.6.0
(https://zakura.com/announcements/zakura-1-6-0/). The Zakura Common
libraries, updated to 4.0.0 (https://zakura.com/announcements/zakura-common/),
carry the Mainnet activation schedule. Rollout status is tracked on the
NU7 Dashboard (https://zakura.com/nu7/; markdown:
https://zakura.com/nu7.md).

Because NU7 triples the block rate, block-counted schedules move:
ZIP 218 places the third halving at height 6,132,390, the existing NSM
calculation schedules reissuance at height 8,939,664, and the ZIP 2008
funding stream recipient rotation proceeds from the activation height.

Activation smoothing: for the first 40 blocks after a network upgrade
activates, the mempool starts no peer cooldown for transactions built
for the previous upgrade, because peers whose tips lag the activation
relay those transactions. The embedded zcashd compatibility sidecar
(https://zakura.com/zcashd/) automatically updates to a zcashd build that
supports NU7. Deployments that run zcashd as a separate process from
Zakura must update zcashd manually to the v1.3.0 release
(https://github.com/valargroup/zcashd/releases/tag/v1.3.0). Older
sidecars stop following the chain when NU7 activates. The interactive
installer (`curl -fsSL https://zakura.com/install.sh | bash`, documented
on https://zakura.com/download/) can set up Zakura and zcashd together.

## QUIC transport replacement

The experimental P2Pv2 stack (https://zakura.com/engineering/p2pv2/)
replaces the Iroh library with `zakura-quic`, built on upstream
`quinn-proto`. Node IDs, key files, and bootstrap entries are
unchanged. The new `[network.zakura.quic]` config section exposes
socket buffers, congestion control, flow-control windows, timers, and
admission limits, and a new `quic_conn` JSONL trace table records each
native connection's RTT, congestion window, packet loss, and MTU.

Admission hardening: connection attempts over the per-IP and
pending-handshake limits are refused before the TLS handshake; an
attempt from an unverified address gets a QUIC Retry (source
validation) once 8 handshakes are in progress, and must validate before
consuming the last per-IP slot; a QUIC handshake must finish within 10
seconds. QUIC NAT traversal is removed, and `nat_traversal = true` now
fails at startup.

The native protocol moves from `p2p-v2/2` to `p2p-v2/3`, so 1.7.0
reaches earlier releases only over the legacy Zcash protocol. Dialing
offers every supported `p2p-v2/N` version in the TLS handshake, and
relayed discovery records carry a signed extension area, so later
releases can extend records and control messages without another
protocol break. Dependency security updates in the same area:
`quinn-proto` 0.11.19 and `rustls` 0.23.45 (RUSTSEC-2026-0285), and the
TLS validation for managed zcashd downloads distrusts the eight
compromised eMudhra intermediate CA keys.

## Resource budgets (experimental P2Pv2 stack)

The design is described in the resource-budgets article
(https://zakura.com/engineering/p2pv2-resource-budgets/). In 1.7.0:

- Native connections are capped by a `[network.zakura]
  peer_memory_budget_bytes` setting, 8 GiB by default, because each
  connection's QUIC windows can hold 64 MiB the node cannot reclaim.
  The default `max_connections` drops from 256 to 92, closed
  connections drain in a separate small allowance, and an oversized
  configured value is lowered at startup with a warning. The budget is
  checked only when P2Pv2 is enabled.
- Block-sync serving advertises at most 2,816 in-flight requests per
  peer by default, the inbound queue is capped at 8 frames (about 20 MB
  of queued raw bodies per connection), decoded bodies above the last
  checkpoint hold at most 512 MiB, and the download refill target stops
  at the node's own in-flight capacity, so status-only peers cannot
  inflate it.
- Header sync moves to stream version 9: subscriptions with renewable
  credit replace per-page GetHeaders requests, and only headers that
  state applied are acknowledged. Version 8 is retired with no
  compatibility path, so native header sync works only between
  version 9 nodes (every other stream still serves older native peers).
  Peers whose headers fail contextual difficulty or time validation are
  disconnected and refused readmission for a cooldown (60 seconds by
  default), and per-Status reactor work is bounded under floods.
  Separately, CPU-profiling-based optimizations removed superfluous
  copying and reallocations on the header sync path, improving sync
  speed over the native protocol by about 12%.
- Discovery moves to stream version 2 (capability bit 9): each message
  has its own frame type and size limit, node records carry at most 8
  services, peer samples and service summaries are served through the
  regulated serving path, record signatures are verified outside the
  address book lock with a bounded CPU share, and each relay can add at
  most 256 third-party records to the address book.

## Mempool and mining

- A full mempool evicts the transactions paying the lowest fee per unit
  of ZIP-401 cost, instead of random transactions. A new transaction
  must pay at least one marginal fee per 10,000 cost more than every
  transaction it evicts, or it is rejected without changing the
  mempool. Victim selection uses an ordered index; local benchmarks
  with 8,000 transactions measured roughly 8,200-11,000x faster
  eviction selection than the previous heap selector (victim planning
  only, excluding downloads, verification, and commit).
- Each connected group of unconfirmed transactions is limited to three
  members (dependency depth of two edges), which permits
  parent-child-grandchild chains.
- The mempool bans a peer only for transaction failures that cannot
  depend on the node's chain tip. Tip-dependent failures, such as v4
  signature and Sapling failures, start a cooldown instead: the
  mempool ignores transactions from the peer's IP for 10 minutes,
  doubling up to 2 hours. zcashd-compat sidecars are never penalized.
- Block distribution: new-block announcements are paced instead of
  going to every peer at once, and peers with lower measured latency
  are announced to first. Announcing to all peers simultaneously can
  make too many of them download the block from the miner at the same
  time; pacing lets other nodes begin redistributing the block sooner.
- Chain tips with equal accumulated work now tie-break by arrival
  instead of by block hash: the node stays on the tip it received
  first, and the `preciousblock` RPC can override the choice.
- New RPCs: `submitsolution` submits a prepared block by `workid` and
  solved header; `getstandardfee` returns the recommended fee per
  logical action in zatoshis (currently 400, Zakura's deliberately
  reduced ZIP 317 marginal fee); `preciousblock` (admin) prefers a
  chain tip over other tips with equal work.
- Mined-block latency: repeated `getblocktemplate` polls of unchanged
  template content reuse the already verified candidate, and legacy and
  dual-P2P peers can pull an admitted block while its contextual commit
  continues. Zakura does not push full blocks.

## Dependency and code reduction

- Transparent scripts are verified with the Rust `zcash_script`
  interpreter; zcashd's C++ script interpreter is no longer built.
- The JSON-RPC server is in-tree, replacing `jsonrpsee`. The wire
  format, HTTP responses, and zcashd error codes are unchanged. Batch
  requests are limited to 1,000 entries; larger batches get a single
  -32010 error and none of their entries run.
- Removed: Sentry reporting, OpenTelemetry trace export, journald
  logging, the terminal progress display, built-in tracing-span
  flamegraphs, the tokio-console integration, and gRPC server
  reflection on the indexer endpoint. Logs and local panic diagnostics
  remain.
- In-tree replacements and removals retire `bincode`, `reqwest`,
  `tempfile`, `humantime`, `der`, `strum`, `crossbeam-channel`,
  `color-eyre`, `tracing-error`, `schemars`, the Abscissa framework,
  and others. Release binaries are about 5% smaller from compiling with
  fewer codegen units alone; compiling serialization entry points once
  saves about another 1.5 MB. The RocksDB dependency is Zakura's
  `zakura-rocksdb` fork, which compiles the bundled RocksDB C++ as a
  unity build to shorten clean builds (RocksDB itself and the on-disk
  format are unchanged).

## Other changes

- Pruned checkpoint-sync databases stop maintaining transparent address
  and spender indexes, retaining validation and mining support.
  Dropping the index maintenance substantially speeds initial sync for
  pruned nodes (nodes that keep the indexes are unaffected): a three-run
  comparison measured about 35% higher sync throughput with dual
  (legacy plus native) networking and about 49% with Zakura-only
  networking. Existing pruned state upgrades in place without a resync,
  and address balance, UTXO, transaction history, and transparent
  spender queries return an explicit unavailable error when their
  indexes are omitted. The database format advances to 30.0.0, and
  older binaries cannot open upgraded databases.
- Sapling miner reward construction and the bundled Sapling proving
  parameters are removed. Sapling-only mining addresses get an explicit
  `getblocktemplate` error; unified mining addresses use their Orchard
  receiver after NU6.3 or their transparent receiver. Sapling
  transaction and shielded coinbase validation is unchanged.
- Config strictness: durations no longer accept week, month, or year
  units (write days or smaller); a config section written as a TOML
  array, such as `rpc = []`, is rejected with its field path; unknown
  keys next to `network.params` are rejected;
  `zakura.block_sync.max_blocks_per_response` is deprecated and
  ignored.

## Crate consumers

Several published crates take major version bumps in this release,
including `zakura-network`, `zakura-state`, and `zakura-node-services`.
The changelog
(https://github.com/zakura-core/zakura/blob/v1.7.0/CHANGELOG.md) lists
the exact API changes; do not guess crate version numbers from this
summary.

## End of support and updating

Mainnet `zakurad` nodes running 1.7.0 halt at height 3,640,098,
estimated 4 December 2026 (enforcement follows height, not time; the
date is a wall-clock projection across the NU7 spacing change). Earlier
releases deliberately halted before the expected NU7 activation; this
release follows the activation, so its support window extends about
four weeks past it. Upgrade warnings begin three days before the halt.
Update with the signed release binaries
(https://github.com/zakura-core/zakura/releases/tag/v1.7.0) or the
`zakura` crate 1.7.0. Installation and verification instructions are on
the download page (https://zakura.com/download/).

---

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