# Release: Zakura 1.0.3 Announcement dated 2026-07-22: Zakura 1.0.3, a security and stability release. Zakura is a Zcash full node. What the announcement says: - Zakura 1.0.3 officially marks zcashd compatibility mode as stable for the Ironwood (NU6.3) network upgrade thanks to extensive testing and feedback, addresses some security issues, continues hardening the inherited P2P stack, and fixes edge cases in mempool behavior. All users should update both their Zakura and zcashd compatibility binaries. Release: https://github.com/zakura-core/zakura/releases/tag/v1.0.3 - zcashd compatibility mode: as with the 1.0.2 release, several bugs were fixed thanks to battle-testing from partners. Most importantly, the zcashd wrapper was not following the NU6.3 network upgrade on Mainnet even though the underlying zakura process was, which could lead to the zcashd wallet stalling; this has been addressed. After extensive compatibility and network-upgrade testing, Zakura 1.0.3 pins valargroup/zcashd 1.1.0 for both managed installations and the split-container image, and the team now considers zcashd compatibility mode stable and ready for the NU6.3 network upgrade. Compatibility mode is described at https://zakura.com/zcashd/. - P2P and sync hardening: retained peer-ban membership, insertion, and eviction are now O(1) instead of growing more expensive as the ban list fills, and IPv4 and IPv4-mapped IPv6 representations are treated as the same peer for bans, inbound rate limits, and per-IP connection limits. Malformed block-discovery responses are also rejected earlier: there were several ways a peer could communicate hashes that would disrupt the node's active sync attempt, and those responses are now discarded. - Mempool hardening: when the mempool was at capacity, gossip could silently drop legitimate transactions. The gossip flow has been adapted so valid transactions are not permanently omitted when the consumer falls behind. When an expired transaction causes its descendants to be removed, all removed descendants are now cleared from pending gossip, preventing missing-parent transactions from being advertised. - Security (GHSA-x93j-mj2f-q338): in coordination with the Zcash Foundation, Zakura 1.0.3 adds additional hardening for GHSA-x93j-mj2f-q338 beyond what shipped in 1.0.2: rejected non-finalized block hashes are drained before known-block checks, allowing an honest same-hash block body to be retried immediately instead of waiting for another state request to process the rejection. A remote, unauthenticated peer that won a block-propagation race could deliver a rejected block body with the same header hash as a valid block. A stale rejection could then prevent children of the valid block from being accepted and stall the node for roughly 2,000 blocks. The issue could not cause a crash, state corruption, consensus divergence, or acceptance of an invalid chain. - Security (GHSA-2p4c-3q4q-p463): craftsoldier reported to the Zcash Foundation issues that Zakura had already mitigated in 1.0.2. The report found that Zebra's mempool exposed nodes to a denial-of-service attack involving transactions as large as 2 MB and failed to ban peers in many real-world error paths. An attacker could repeatedly submit transactions containing large numbers of invalid Orchard proofs. When batch verification failed, the verifier checked each proof individually, creating substantial CPU load. Because the offending peer was not banned, the attacker could sustain the load and delay block processing. Zakura's 1.0.2 mempool hardening addressed these issues by banning peers that submit invalid Orchard proofs and imposing a configurable transaction-size limit for mempool admission, set to 250 KB by default. Advisory: https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-2p4c-3q4q-p463 - RPC and indexer reliability: read-secondary subscriptions resume from known chain tips, use bounded backpressure instead of dropping blocks, fetch finalized blocks to bridge gaps, and use bounded catch-up handoffs, retries, and stream timeouts. Verbose block-header metadata stays bound to the block originally resolved across reorganizations. The getrawtransaction missing-ID error now says "Transaction not found in mempool or best chain," and remaining user-facing Zebra references now say Zakura. The announcement thanks @dismad for suggesting the RPC wording and @ambimorph for reporting the stale branding in https://github.com/zakura-core/zakura/issues/327. - Consensus-state and release hardening: malformed or wrong-network history-tree snapshots and invalid empty or pre-Heartwood caches now fail closed with typed errors. Zakura 1.0.3 also extends Mainnet checkpoint sync from height 3,358,006 to 3,418,406, and checkpoint and verified-commitment-tree frontier refreshes now run through an automated pipeline: an offline export mode produces a provenance record that CI verifies, refreshed data is imported from digest-verified publisher bundles into reviewable draft pull requests, and pre-release checks confirm that checkpoints, frontiers, and provenance remain coupled. Security hotfixes also have a dedicated release path, rehearsed against private staging infrastructure, with a hardened checklist and process documentation. - Performance and development: cached ZIP-244 empty-bundle hashes made authorizing-data digest calculation 2.8% faster and combined transaction-ID plus authorizing-data digest calculation 5.6% faster in the Ironwood-only benchmark. Acceptance tests use readiness signals instead of fixed sleeps, and a log-capture race that could corrupt tracing span bookkeeping in zakurad test binaries is fixed. A specification for a fork-aware header chain engine was added, laying groundwork for the next stage of native header sync. - Other improvements: native header sync honors disable_pow on configured Testnets, and unused public zakura-chain errors, constants, and helpers are removed, a breaking change for crate consumers that does not affect node operators. - End of support: Zakura 1.0.3 supports Ironwood activation and is currently configured to reach end of support roughly eleven days afterward, by which point the next post-Ironwood release will be available. - Updating: signed release binaries or the `zakura` crate 1.0.3 via Cargo; installation and verification instructions are at https://zakura.com/download/. --- Canonical HTML version: https://zakura.com/announcements/zakura-1-0-3/