Closes #1401 Assigns Typecode 0xC0, the first Typecode in the non-MUST-understand Metadata range, to a Viewing Key Birthday Height Metadata Item: a little-endian u32 giving the height of the first block that a user of the UFVK or UIVK should scan in order to detect funds. Specification summary: Permitted only in UFVKs and UIVKs. A Producer SHOULD set the Birthday Height no greater than the height of the earliest block that pays any address derivable from the key. Prohibited in Unified Addresses. A Consumer MUST ignore a 0xC0 item in a UA.

A wallet that imports a UFVK or UIVK has no way to learn, from the key itself, the height of the first block it needs to scan in order to detect funds. It must either obtain the birthday height through a separate channel or scan from a conservative default (such as the activation height of the oldest supported shielded protocol), which can be very slow.

ZIP 318 states its scheduling parameters as block counts, assuming 75-second blocks. ZIP 218 reduces the block target spacing to 25 seconds at NU7. Without a change, a migration scheduled after NU7 would run in a third of its intended time, with 1-hour anchor buckets and 10–20 days of transaction validity. ZIP 218 recommends scaling by NU7PoWTargetSpacingRatio any block-count constant that represents a duration. This PR applies that recommendation to ZIP 318. Changes Reference blocks. A new term for a block at the 75-second spacing.

Proposal 1395 is tracked from its source repository.

Updates draft ZIP 2009 (#1388) to propose marginal_fee = 400 zatoshis per logical action (minimum conventional fee 800 zatoshis) and weight_ratio_cap = 13, instead of 1,000 and 10. 800 zatoshis is about 0.64 cents at $800/ZEC, still about 2x the 2022 dollar cost; it only falls below the 2022 cost if ZEC drops below $375. A cap of 13 is the smallest integer above the 12.5x ratio between the old and new conventional fees, so transactions from wallets still paying the old fee are not clamped.

The recipient of the FS_FPF_ZCG_H3 funding stream (FPF) notified the ZIP Editors that there is a need to receive the funding stream into a new address.

From @arya2's remark on #1394 (https://github.com/zcash/zips/pull/1394#discussion_r4264725460): when applying an Update ZIP, the ZIP Editors add the References entries that the applied text cites, if they are to the protocol specification or to ZIPs. Update ZIPs keep specifying references to third-party documents, whose form ZIP 0 cannot predict. The same paragraph makes applying the changes add the Change History entry, per the ZIP 2008 comments in that review. Prepared with Claude Opus 5.5.

A line-by-line review of the NU7 ZIPs against the protocol specification and the deployed Zebra code found the gaps below. The accompanying PR fixes most of them. Items under Open are remaining work: partly fixed, not fixed, or awaiting an editor decision. ZIP 200: Network Upgrade Mechanism Fixed The memory-pool rules were keyed on the chain tip height, one block after the activation block they guard. ZIP 239 and deployed nodes use the next block's height.

Changed The block ingestor no longer exits when getbestblockhash fails. A single failed call (for example HTTP 429 "Too many connections" from a loaded zebrad or zakura backend) used to call Log.Fatal, dropping every in-flight client stream; replicas sharing one backend then exited and reconnected together, adding to the overload. It now logs a warning and retries with a capped exponential backoff (1s to 30s), raises the log to Error after 5 minutes of continuous failures, and logs once when the RPC recovers. Malformed replies stay fatal.

The Halo2 zero-knowledge proving system

Proposal 1391 is tracked from its source repository.

Adds a draft ZIP proposing a reduction of ZIP 317's marginal_fee from 5,000 to 1,000 zatoshis per logical action. The conventional fee for a minimal 2-action transaction goes from 10,000 to 2,000 zatoshis; no other ZIP 317 parameter or formula changes. This is a wallet convention and node relay policy change, so it requires no consensus change and no network upgrade.

This draft ZIP proposes reducing ZIP 317's marginal_fee from 5,000 to 1,000 zatoshis per logical action, lowering the minimum conventional fee from 10,000 to 2,000 zatoshis, and raising weight_ratio_cap from 4 to 10 to maintain the range of inclusion-influencing fees. It is a wallet and relay-policy change with no consensus change, requiring coordinated deployment of node relay policy before wallet adoption at a proposed Mainnet height of 3590000.

ZIP 2008 updates ZIPs 207 and 214 to permit P2PKH funding stream recipients, aligning with changes already applied from ZIP 218. This revision applies Draft ZIP updates ahead of the standard process, for consistency in the next network upgrade.

ZIP 2008 proposes an update to rotate the FS_FPF_ZCG_H3 address, as part of a larger effort tracked in issue #1373.

ZIP 2003 is updated to align its consensus change with the NU6.3 protocol specification, correcting an outdated reference. The update may later point to protocol version v2026.7.1 if a related pull request (#1358) is merged first, but the change is not dependent on that.

This issue proposes a variant of ZIP-234 that preserves Zcash's halving schedule while introducing a network sustainability mechanism, aiming to reduce the issuance spike associated with end-of-halving dynamics.

ZIP 237 is updated with exact initial NSM balances: 36,858,445,520 zatoshi (Mainnet) and 55,768,414,957 zatoshi (Testnet), sourced from Zakura’s merged implementation, replacing placeholder TODOs and correcting approximate values.

Proposal 883 is tracked from its source repository.

This ZIP-230 pull request updates v6 transactions and references issue #686, suggesting ZSAs may be removed except for a placeholder field for forward-compatibility.

A successor to the protocol specified in ZIP 204, replacing the Bitcoin-inherited TCP message-passing architecture with a transport-neutral stream layer realized by QUIC, anticipating a Nym mixnet transport used in parallel (QUIC for latency-critical relay and sync, Nym for anonymity-critical traffic such as transaction origination). Adds zips/draft-arya-jvff-p2p-quic-transport.rst (new draft ZIP, 1714 lines).

ZIP 248 defines a forward-compatible, extensible transaction format for Zcash to reduce disruption from network upgrades. Past format changes forced wallets, including transparent-only ones, to update parsers even when unused, sometimes locking funds. The proposal addresses the need for a format that allows non-affected clients to avoid mandatory updates while retaining compatibility with consensus changes where required.

ZIP 248 proposes flat effect digests with a compact/noncompact wire split for v6 transaction identifiers, as an alternative to structured digests (#1253). The design separates each bundle's effecting data at the framing level, hashing portions as flat BLAKE2b-256 with fixed personalizations and domain-separation prefixes. Key benefits include any wallet computing txids for unknown bundle types without an oracle, light-client trustless partial verification, and low per-bundle spec cost.

This PR proposes ZIP 248 defining a forward-compatible, extensible transaction format using structured per-bundle digest trees for transaction identifiers and authorizing data commitments. It specifies bundle-specific digest algorithms that separate compact data for light wallets from non-compact data, enabling trustless partial verification and requiring external supply of bundle_effects_digest for unknown bundle types. It also details parsing rules, consensus rule restructuring, and value pool delta computation.

This pull request updates ZIP 218 for the Ironwood network upgrade. It gives Orchard and Ironwood the same per-pool limit of 330 actions, counts both against a shared global shielded budget, and sets the Sprout JoinSplit limit to zero at NU7. Terminology and related sync/throughput/fee analyses are also updated.

A GitHub issue on the zcash/zips repository reports an inconsistency between ZIP 236 and ZIP 237. ZIP 236 requires coinbase transactions to claim all available miner subsidy plus fees, while ZIP 237 claims ZIP 236 requires the coinbase to claim its full total input value. The issue states these definitions are inconsistent and that ZIP 236 must be changed.

This draft ZIP specifies the wallet-side mechanism for Zcash light-client wallets to submit transactions directly to full nodes over P2P using Dandelion++ stem-phase forwarding, avoiding IP-metadata leaks from centralized compact-block servers. It details peer discovery, handshake, unadvertised tx submission, fallback to SendTransaction, and includes opt-in reference implementations for Android and iOS SDKs. No consensus change is involved, and chain synchronization remains via compact-block servers.

A draft ZIP proposes a network-layer Dandelion++ specification for Zcash full nodes to obscure transaction-origin IP correlation. It defines stem-peer selection with 10-minute epochs, unicast stem forwarding using existing inv messages, a 30-second stem timeout, fail-closed fluff promotion, and stem-phase mempool filtering. The wallet-side submission component is deferred to a companion draft, and a Zebra reference implementation is available with e2e verification on a 3-node regtest network.

Summary Proposes a network-layer specification for Dandelion++ stem/fluff transaction propagation in Zcash full nodes. Problem: Zcash transactions are currently flood-broadcast immediately, allowing passive network observers to correlate originating IP addresses with transactions even for shielded txs whose *content* is cryptographically protected.

Summary Proposes the wallet-side counterpart to draft-zodl-dandelion (#1329): how a light-client wallet submits a transaction directly to a Zcash full node over P2P (under Dandelion++ stem-phase forwarding) instead of through a compact-block server. Problem: when a wallet calls SendTransaction, the compact-block server (lightwalletd/Zaino) sees the wallet's IP and the transaction at the same instant. For shielded transactions this leaks exactly the metadata that shielding is designed to protect.

Proposal 1378 is tracked from its source repository.

The Address Change period should remain the same in real time The end dates of funding streams in ZIP 214 should remain at the 3rd halving.

Rust-language assets for Zcash

A Process ZIP proposal updates Zcash Community Grants Committee conflict-of-interest rules, replacing organization-specific limits with a general rule barring more than one member with a material organizational association to the same entity. Former employment or ordinary collaboration does not create a continuing association; candidates must disclose relevant associations, and each member signs an annual conflict-of-interest declaration. The proposal does not change committee size, election method, funding allocation, or KYC requirements.

ZIP 259 asks for reference implementations and test vectors for the NSM reserve. A contributor proposes to build a node-agnostic reference model generating shared test vectors for Zakura and Zebra, plus a Testnet chain replay, to validate reserve calculations against the same expected values.

A draft for NU7 deployment adds a Valar Group draft, specifies ZIP 218 (a fee-only halving-preserving NSM reserve), v4 transaction deprecation, and documents coinholder and ZCAP poll questions and outcomes.

ZIP 218 proposes a 25-second block target spacing for Zcash. This tracking issue documents the proposal and lists merged PRs related to the effort, indicating active development toward the change.

Proposal 1369 is tracked from its source repository.

Proposal 839 is tracked from its source repository.

This pull request adds ZIP 237, an alternative to ZIP 234 that preserves the original halving schedule while adapting the text from ZIP 234 with minimal changes. The proposal directs further discussion to issue #1353.

ZIP 228 contains an internal contradiction: the expiry consensus rule at L132 (≤) and the definition at L190 (maximum height) disagree, and neither handles the 0 sentinel meaning 'no expiry'. The author proposes a guarded comparison to fix both issues, noting this is not urgent because current code requires nAGExpiryHeight=0.

A GitHub issue asks whether ZIP 318's block-count constants, such as EXPIRY_MODULUS (34,560 blocks, documented as ~30 days at 75-second spacing), would rescale if ZIP 218 reduces the block target to 25 seconds. The issue notes that ZIP 218 does not mention ZIP 318 or these constants, and that downstream wallets (chainapsis/vizor-wallet, zingolabs/zingolib) have copied the constants, so clarification is needed before NU7.

Withdrawn. The corrected values are all in #1364, so the ZIP editors can apply the change directly.

Two errors in the Custom Assets examples of ZIP 321, found while running a parser against the spec's examples. 1. req-asset.1 in the two-recipient valid example is not valid base64url The value is 99 characters long; a 75-byte value encodes to 100. A strict unpadded base64url decoder rejects it because of non-zero padding bits, and a lenient one reads 74 bytes and an amount of 198,800. The text says the second payment requests 250,000 minimal units.