# Release: Zakura 1.6.0 Announcement for Zakura 1.6.0, released 2026-10-01. Some of the performance work described here shipped in Zakura 1.5.1 (2026-09-29), which had no announcement post of its own. All node operators should update. The headline claims: the full NU7 implementation is in a released version of Zakura, with Testnet activation scheduled at height 4,465,026 (estimated 6 October 2026; heights are authoritative); blocks verify 8x faster on average and 17x faster when full of transactions, as cumulative gains measured across recent releases rather than from 1.6.0 alone; committed blocks are gossiped immediately; and Zakura's conventional fee drops to 400 zatoshis per logical action. ## NU7 Zakura 1.6.0 includes the full implementation of the proposed NU7 network upgrade: 25-second block target spacing, the ZIP 218 per-block shielded action limits, and the Network Sustainability Mechanism, whose existing calculation schedules reissuance at height 7,305,222. NU7 activates on Zcash's public Testnet at block height 4,465,026 (estimated 6 October 2026) via the Zakura Common 2.2.0 libraries. NU7 remains unscheduled on Mainnet and on default Regtest; installing this release does not activate NU7 on Mainnet. The rollout, including the NU7 Staging Testnet where the upgrade already runs, is tracked on the NU7 Dashboard (https://zakura.com/nu7/; markdown: https://zakura.com/nu7.md). 1.5.1 prepared the surrounding schedule: funding stream recipient addresses rotate once every three address-change intervals from NU7 activation, following ZIP 218's longer halving interval; the ZIP 214 Revision 2 funding streams (Zcash Community Grants and the lockbox) end at the third halving as moved by ZIP 218; the ZIP 2008 Mainnet FPF/ZCG address rotation is prepared, with deployment awaiting final confirmation; and Testnet keeps its 7.5-minute minimum-difficulty waiting period after NU7 by requiring a gap of more than 18 target spacings. Testnet `getblocktemplate` no longer offers minimum-difficulty work early by moving the template timestamp into the future; long polling returns it one second after `maxtime`. Mainnet is unchanged. An 80-node Zakura stressnet with equal-hashpower miners spread evenly across 11 regions mined blocks full of shielded transactions (2MB) at 25-second spacing and measured a 3.43% orphan rate (https://zakura.com/engineering/25-second-block-time-update/). ## Block processing speedups The 8x average and 17x full-block verification speedups are cumulative across Zakura and the Zakura Common cryptography libraries (https://zakura.com/announcements/zakura-common/). Contributions by release: 1.4.0 accelerated block propagation (https://zakura.com/announcements/zakura-1-4-0/); 1.5.0 reduced block commit and mining template latency (https://zakura.com/announcements/zakura-1-5-0/); 1.5.1 moved Equihash proof verification and the optional CPU miner to Common's pure Rust implementation (zakura-equihash, with a faster solver, replacing the miner's C backend) and sped up Sapling batch proof verification through prepared verifying keys. Since 1.5.0, chain snapshots share unchanged output-index partitions, transparent address index partitions, and retained block records instead of cloning them, and cloning or rolling back non-finalized chains containing large transparent output scripts uses less memory. State tracing spans no longer format full blocks and UTXO maps (block height and hash are retained), and transaction verification does less work detecting duplicate inputs and nullifiers. ## Gossip Committed blocks are gossiped to peers as soon as they reach the best chain instead of up to 7 seconds after the previous block gossip, and the delay between transaction gossip batches drops from 7 seconds to 2. ## Fees Zakura's conventional fee is now 400 zatoshis per logical action, deliberately lower than the 5,000 zatoshis per action specified by ZIP 317. The new rate applies to mempool admission, `getblocktemplate` priority and weighting, and mempool eviction. Action counting and the two grace actions are unchanged from ZIP 317, and the legacy size-based relay fee is capped at 800 zatoshis so it cannot override the two-action minimum. This is relay and mining policy, not consensus: blocks containing cheaper transactions are valid for every implementation, and nodes running other implementations apply their own fee policies. The block template fee weight ratio cap rises from 10 to 13, so transactions paying 5,000 zatoshis per action receive their full 12.5 weight during template selection. ## Sync and network handling (experimental P2Pv2 stack) The experimental P2Pv2 stack is not the default networking stack. Across these releases: - Block sync reserves each body's advertised or committed size instead of the 2MB worst case. Suppliers publish committed sizes when serving headers from finalized state, requesters read size hints carried by retained header deliveries, and a later known size can fill a missing hint once. Fills are stored in a new state column family, moving the database format to 29.1.0 without a migration. A body matching its requested header hash may exceed its size hint when retention capacity is available; bodies that do not fit are retried after commit progress. - Header sync refills its bounded header window before the body backlog drains, publishes completed checkpoint-sized prefixes promptly, lets continuation requests grow when shared credits return, and keeps header validation charged to its capacity budget after a supplier disconnects. Checkpoint sync does less commit work for headers already retained by the header chain. - Streams declare message tables (allowed types, flags, and lengths), and readers check each frame against its stream's table and the request's remaining response budget before reading the payload. Rows with a cadence declare the sender's interval; readers observe cadence exhaustion without disconnecting peers, because transport stalls can buffer conformant messages. - Serving bounds unsent response counts per peer and across the node, and response slots stay held until the final transport write completes, so tiny responses cannot accumulate below the encoded-byte limit alone. Block serving preserves requested block order so response limits consider earlier hashes first. ## Other changes - Zakura Common is updated: 1.5.1 used 2.1.0 and 1.6.0 uses 2.2.0 (https://github.com/zakura-core/common); 2.2.0 carries the Testnet NU7 activation schedule. - Sentry error reporting is disabled in default node builds and release binaries. Opt in by building with `--features sentry` and setting `SENTRY_DSN` at runtime. - Published x86-64 binaries and Docker images are built with portable Pasta field arithmetic and run on CPUs without BMI2 and ADX. Local x86-64 builds select Pasta assembly from Rust target features; use `-C target-cpu=native` on a supported CPU to enable BMI2 and ADX. - Configured Testnets with `funding_streams = []` have no funding streams; overlapping funding stream ranges are rejected; public Mainnet and Testnet reject legacy `testnet_parameters` overrides instead of silently selecting different consensus rules. Remove those overrides before upgrading; custom Testnets remain configurable through the explicit `network = { ... }` form. ## Crate consumers The message-table work is a breaking change: `Stream::messages` replaces `payload_limits` and `message_types`, `ZakuraHandlerError::RejectedFrame` replaces `InvalidMessageType`, and `Cadence` gains `send_interval`. These move `zakura-network` to 9.0.0 and `zakura-rpc` to 12.0.0, and `zakura-consensus` moves to 10.0.0 so packaged dependents use the workspace's state and header types. The changelog (https://github.com/zakura-core/zakura/blob/v1.6.0/CHANGELOG.md) lists the exact API changes. ## End of support and updating Mainnet `zakurad` nodes running 1.6.0 halt at height 3,536,467 (estimated 2026-11-01); upgrade warnings begin three days earlier. The database format advances to 29.1.0, without a migration. Update with the [signed release binaries](https://github.com/zakura-core/zakura/releases/tag/v1.6.0) or the `zakura` crate 1.6.0. Installation and verification instructions are on the [download page](https://zakura.com/download/). --- Canonical HTML version: https://zakura.com/announcements/zakura-1-6-0/