From ebb385f4966175e6e19319d02a366de4fca93e9d Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 13 Apr 2026 19:05:11 +0000 Subject: [PATCH 1/4] Add mdbook scaffolding: book.toml, src/SUMMARY.md, introduction, and initial .md ZIPs Agent-Logs-Url: https://github.com/shielded-nate/zips/sessions/afec0b27-bc72-4348-a984-ec23fce9d717 Co-authored-by: shielded-nate <185561036+shielded-nate@users.noreply.github.com> --- .gitignore | 3 + book.toml | 9 ++ src/SUMMARY.md | 11 ++ src/introduction.md | 46 +++++++++ src/zip-0233.md | 242 ++++++++++++++++++++++++++++++++++++++++++++ src/zip-0234.md | 221 ++++++++++++++++++++++++++++++++++++++++ src/zip-0253.md | 88 ++++++++++++++++ 7 files changed, 620 insertions(+) create mode 100644 book.toml create mode 100644 src/SUMMARY.md create mode 100644 src/introduction.md create mode 100644 src/zip-0233.md create mode 100644 src/zip-0234.md create mode 100644 src/zip-0253.md diff --git a/.gitignore b/.gitignore index aa5d76d21..bbc035099 100644 --- a/.gitignore +++ b/.gitignore @@ -31,3 +31,6 @@ protocol/saplinghtml/ protocol/heartwood.pdf protocol/protocol.ver *~ + +# mdbook build output +book/ diff --git a/book.toml b/book.toml new file mode 100644 index 000000000..076524ceb --- /dev/null +++ b/book.toml @@ -0,0 +1,9 @@ +[book] +title = "Zcash Improvement Proposals" +authors = ["Zcash Contributors"] +language = "en" +multilingual = false +src = "src" + +[build] +build-dir = "book" diff --git a/src/SUMMARY.md b/src/SUMMARY.md new file mode 100644 index 000000000..1912b3f73 --- /dev/null +++ b/src/SUMMARY.md @@ -0,0 +1,11 @@ +# Summary + +[Introduction](introduction.md) + +--- + +# Consensus + +- [ZIP 233: Establish the Zcash Sustainability Fund](zip-0233.md) +- [ZIP 234: Smooth Out The Block Subsidy Issuance](zip-0234.md) +- [ZIP 253: Deployment of the NU6 Network Upgrade](zip-0253.md) diff --git a/src/introduction.md b/src/introduction.md new file mode 100644 index 000000000..df72b7bdc --- /dev/null +++ b/src/introduction.md @@ -0,0 +1,46 @@ +# Zcash Improvement Proposals + +## What are ZIPs? + +Zcash Improvement Proposals (ZIPs) are the way to: + +- propose new features for the [Zcash cryptocurrency](https://z.cash/) and their rationale, +- specify the implementation details of the feature, +- collect community input on the proposal, and +- document design decisions. + +## Contributing + +The authors of a ZIP are responsible for building consensus within the community +and documenting / addressing dissenting opinions. + +Anyone can write a ZIP! We encourage community contributions and decentralization +of work on the Zcash protocol. If you'd like to bounce ideas off people before formally +writing a ZIP, we encourage it! Visit the +[ZcashCommunity Discord chat](https://discord.gg/kdjfvps) to talk about your idea. + +Participation in the Zcash project is subject to a +[Code of Conduct](https://github.com/zcash/zcash/blob/master/code_of_conduct.md). + +The Zcash protocol is documented in its +[Protocol Specification](https://zips.z.cash/protocol/protocol.pdf). + +To start contributing, first read [ZIP 0](zip-0000.md) which documents the ZIP process. +Then clone [this repo](https://github.com/zcash/zips) from GitHub, and start adding +your draft ZIP, formatted either as reStructuredText or as Markdown, into the `zips/` +directory. + +For example, if using reStructuredText, use a filename matching `zips/draft-*.rst`. +Use `make` to check that you are using correct +[reStructuredText](https://docutils.sourceforge.io/rst.html) or +[Markdown](https://pandoc.org/MANUAL.html#pandocs-markdown) syntax, +and double-check the generated `rendered/draft-*.html` file before filing a Pull Request. +See [here](https://github.com/zcash/zips/blob/main/protocol/README.rst) for the project +dependencies. + +## License + +Unless otherwise stated in this repository's individual files, the contents of this +repository are released under the terms of the MIT license. See +[COPYING](https://github.com/zcash/zips/blob/main/COPYING.rst) for more information or +see . diff --git a/src/zip-0233.md b/src/zip-0233.md new file mode 100644 index 000000000..c68bb8cb4 --- /dev/null +++ b/src/zip-0233.md @@ -0,0 +1,242 @@ +``` +ZIP: 233 +Title: Establish the Zcash Sustainability Fund on the Protocol Level +Owners: Jason McGee + Mark Henderson + Tomek Piotrowski + Mariusz Pilarek +Original-Authors: Nathan Wilcox +Credits: +Status: Draft +Category: Consensus / Ecosystem +Created: 2023-08-16 +License: BSD-2-Clause +``` + +# Terminology + +The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", "OPTIONAL", +and "REQUIRED" in this document are to be interpreted as described in RFC 2119. +[1] + +The term "network upgrade" in this document is to be interpreted as described +in ZIP 200. [2] + +"Block Subsidy” - the algorithmic issuance of ZEC on block creation – part of +the consensus rules. Split between the miner and the Dev Fund. Also known as +Block Reward. + +"Issuance" - The method by which unmined or unissued ZEC is converted to ZEC +available to users of the network + +"We" - the ZIP authors, owners listed in the above front matter + +"`MAX_MONEY`" is the ZEC supply cap. For simplicity, this ZIP defines it to be +`21,000,000 ZEC`, although this is slightly larger than the actual supply cap +of the original ZEC issuance mechanism. + +# Abstract + +This ZIP describes the motivation, the necessary changes for, and the +implementation specifications for the Zcash Sustainability Fund (ZSF). The ZSF +is a proposed alteration to the block rewards system and accounting of unmined +ZEC that allows for other sources of funding besides unissued ZEC. This new +mechanism for deposits -- that new applications or protocol designs can use to +strengthen the long-term sustainability of the network -- will likely be an +important step for future economic upgrades, such as a transition to Proof of +Stake or Zcash Shielded Assets, and other potential protocol fees and user +applications. + +The changes in this ZIP are ultimately minimal, only requiring for the node to +track state in the form of a `ZSF_BALANCE`, and for a new transaction field to +be added, called `ZSF_DEPOSIT`. While wallet developer would be encouraged to +add the `ZSF_DEPOSIT` field to their UIs, no changes or new behavior are +absolutely required for developers or ZEC holders. + +This ZIP does not change the current ZEC block subsidy issuance schedule. Any +additional amounts paid into the sustainability fund are reserved for use in +future ZIPs. + +# Motivation + +The Zcash network's operation and development relies fundamentally on the block +reward system inherited from Bitcoin. This system currently looks like this: + +- At Every New Block: + - Miner and funding streams are rewarded a constant amount via unissued ZEC + (this constant amount halves at specified heights) + - Miner is rewarded via Transaction fees `(inputs - outputs)` + +The Zcash Sustainability Fund is a proposed replacement to that payout +mechanism, with the relevant parts in *bold* below: + +- **Unmined ZEC is now accounted for as `ZSF_BALANCE`** +- **Transaction includes optional contributions to ZSF via a `ZSF_DEPOSIT` field** +- Thus, at Every New Block: + - Miner and funding streams rewarded the same constant amount, **but from + `ZSF_BALANCE`** (this constant amount still halves at specified heights) + - Miner is rewarded via Transaction fees `(inputs - outputs)`, **where + `outputs` includes the `ZSF_DEPOSIT` amount** + +For example, an end-user wallet application could have an option to contribute +a portion of a transaction to the ZSF, which would be included in a +`ZSF_DEPOSIT` field in the transaction, to be taken into account by the Zcash +nodes. + +This quite simple alteration has -- in our opinion -- a multitude of benefits: + +1. **Long Term Consensus Sustainability:** This mechanism supports long-term + consensus sustainability by addressing concerns about the sustainability of + the network design shared by Bitcoin-like systems through the establishment + of deposits into the Sustainability Fund to augment block rewards, ensuring + long-term sustainability as the issuance rate of Zcash drops and newly + issued ZEC decreases over time. +2. **Benefits to ZEC Holders:** Deposits to the ZSF slow down the payout of + ZEC, temporarily reducing its available supply, benefiting current holders + of unencumbered active ZEC in proportion to their holdings without requiring + them to opt into any scheme, introducing extra risk, active oversight, or + accounting complexity. +3. **Recovery of "Soft-Burned" Funds:** In some instances, such as miners not + claiming all available rewards, some ZEC goes unaccounted for, though not + formally burned. This proposal would recover it through the `ZSF_BALANCE` + mechanism described below. + +# Specification + +In practice, The Zcash Sustainability Fund is a single global balance +maintained by the node state and contributed to via a single transaction field. +This provides the economic and security support described in the motivation +section, while also importantly keeping the fund payouts extremely simple to +describe and implement. + +The two modifications are: +1. The re-accounting of unmined ZEC as a node state field called `ZSF_BALANCE` +2. The addition of a transaction field called `ZSF_DEPOSIT` + +## `ZSF_BALANCE` + +The ZEC issuance mechanism is re-defined to remove funds from `ZSF_BALANCE`, +which is initially set to `MAX_MONEY` at the genesis block. + +Consensus nodes are then required to track new per-block state: + +- `ZSF_BALANCE[height] : u64 [zatoshi]` + +The state is a single 64 bit integer (representing units of `zatoshi`) at any +given block height, $\mathsf{height}$, representing the Sustainability Fund +balance at that height. The `ZSF_BALANCE` can be calculated using the following +formula: + +$\mathsf{ZsfBalanceAfter}(\mathsf{height}) = \mathsf{MAX\_MONEY} + \sum_{h = 0}^{\mathsf{height}} (\mathsf{ZsfDeposit}(h) + \mathsf{Unclaimed}(h) - \mathsf{BlockSubsidy}(h))$ + +where $\mathsf{Unclaimed}(\mathsf{height})$ is the portion of the block subsidy +and miner fees that are unclaimed for the block at the given height. + +The block at height $\mathsf{height}$ commits to +$\mathsf{ZsfBalanceAfter}(\mathsf{height})$ as part of a new block commitment +in the block header, at the end of the `hashBlockCommitments` chain in +[ZIP-244](https://zips.z.cash/zip-0244#block-header-changes). + +TODO ZIP editors: consider introducing a chain state commitment hash tree. +(When we get closer to the network upgrade, we will have a better idea what +commitments that network upgrade needs.) + +## Deposits into the Sustainability Fund + +Sustainability fund deposits can be made via the new `zsfDeposit` field. This +can be done by: +- ZEC fund holders, in non-coinbase transactions; +- Zcash miners, in coinbase transactions. + +In transaction versions without this new field: +- unclaimed miner fees and rewards in **coinbase transactions** are re-defined + as deposits into the sustainability fund, and +- there are no sustainability fund deposits from non-coinbase transactions. + +Note: older transaction versions can continue to be supported after a network +upgrade. For example, NU5 supports both v4 and v5 transaction formats, for both +coinbase and non-coinbase transactions. + +### `zsfDeposit` fields in transactions + +Each transaction can dedicate some of its excess funds to the ZSF, and the +remainder becomes the miner fee, with any excess miner fee/reward going to the +ZSF + +This is achieved by adding a new field to the common transaction fields +[#zip-0225-transaction-format]: + +- `zsfDeposit : u64 [zatoshi]` + +The `ZSF_BALANCE[H]` for a block at height `H` can be calculated given a value +of `ZSF_BALANCE[H-1]` and the set of transactions contained in that block. +First, the `ZSF_DEPOSIT[H]` is calculated based solely on `ZSF_BALANCE[H-1]`. +This is subtracted from the previous block's balance to be distributed as part +of the block reward. Second, the sum of all the `ZSF_DEPOSIT` fields of all +transactions in the block is added to the balance. + + +### Non-Coinbase Transactions + +If the `ZSF_DEPOSIT` field is not present in an older transaction version, it +is defined to be zero for non-coinbase transactions. + +#### Consensus Rule Changes + +- Transparent inputs to a transaction insert value into a transparent + transaction value pool associated with the transaction. Transparent outputs + **and sustainability fund deposits** remove value from this pool. + +### Coinbase Transactions + +Any excess miner fee/reward is sent to the ZSF. + +In new blocks, this deposit is tracked via the `ZSF_DEPOSIT` field in coinbase +transactions. + +If the `ZSF_DEPOSIT` field is not present in a coinbase transaction with an +older transaction version, it is defined as the value of any unspent miner fee +and miner reward. This re-defines these previously unspendable funds as ZSF +deposits. + +#### Consensus Rule Changes + +- The remaining value in the transparent transaction value pool of a coinbase + transaction is **deposited in the sustainability fund**. + +### `ZSF_DEPOSIT` Requirements + +- ZIP 230 [3] must be updated to include `ZSF_DEPOSIT`. +- ZIP 244 [4] must be updated as well to include `ZSF_DEPOSIT`. + +# Rationale + +All technical decisions in this ZIP are balanced between the necessary +robustness of the ZSF mechanics, and simplicity of implementation. + +## `ZSF_BALANCE` as node state + +Tracking the `ZSF_BALANCE` value as a node state using the above formula is +very simple in terms of implementation, and should work correctly given that +the node implementations calculate the value according to the specifications. + +## `ZSF_DEPOSIT` as explicit transaction field + +An explicit value distinguishes the ZEC destined to Sustainability Fund +deposits from the implicit transaction fee. Explicitness also ensures any +arithmetic flaws in any implementations are more likely to be observed and +caught immediately. + +# Deployment + +This ZIP is proposed to activate with Network Upgrade (TODO ZIP editors). + +# References + +**[1]: [Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119.html)** + +**[2]: [ZIP 200: Network Upgrade Mechanism](https://zips.z.cash/zip-0200)** + +**[3]: [ZIP 230: v6 transactions, including ZSAs](https://github.com/zcash/zips/pull/687)** + +**[4]: [ZIP 244: Transaction Identifier Non-Malleability](https://zips.z.cash/zip-0244)** diff --git a/src/zip-0234.md b/src/zip-0234.md new file mode 100644 index 000000000..332baac6d --- /dev/null +++ b/src/zip-0234.md @@ -0,0 +1,221 @@ +``` +ZIP: 234 +Title: Smooth Out The Block Subsidy Issuance +Owners: Jason McGee + Mark Henderson + Tomek Piotrowski + Mariusz Pilarek +Original-Authors: Nathan Wilcox +Credits: +Status: Draft +Category: Consensus +Created: 2023-08-23 +License: BSD-2-Clause +``` + +# Terminology + +The key words “MUST”, “SHOULD”, “SHOULD NOT”, “MAY”, “RECOMMENDED”, “OPTIONAL”, +and “REQUIRED” in this document are to be interpreted as described in RFC 2119. [1] + +"Network upgrade" - to be interpreted as described in ZIP 200. [2] + +“Block Subsidy” - to be interpreted as described in the Zcash Protocol +Specification (TODO ZIP Editors: link from comment). + +“Issuance” - the sum of Block Subsidies over time. (TODO ZIP Editors: work out +if this definition is correct or can be removed). + +“`ZsfBalanceAfter(h)`” is the total ZEC available in the Zcash Sustainability +Fund (ZSF) after the transactions in block `h`, described in ZIP draft-zsf.md. +In this ZIP, the Sustainability Fund is used to pay out Block Subsidies from +unmined ZEC, and other fund deposits. + +Let `PostBlossomHalvingInterval` be as defined in [#protocol-diffadjustment]_. + + +# Abstract + +This ZIP proposes a change to how nodes calculate the block subsidy. + +Instead of following a step function around the 4-year halving intervals +inherited from Bitcoin, we propose a slow exponential “smoothing” of the curve. +The new issuance scheme would approximate the current issuance over 4-year +intervals. + +This ZIP depends on the ZIP introducing the Zcash Sustainability Fund +(ZIP-XXX). + +# Motivation + +The current Zcash economic model, inherited from Bitcoin, includes a halving +mechanism which dictates the issuance of new coins. While this has been +foundational, halvings can lead to abrupt changes in the rate of new coins +being introduced to the market. Such sudden shifts can potentially disrupt the +network's economic model, potentially impacting its security and stability. +Furthermore, the halvings schedule is fixed and does not provide any way to +"recycle" funds into future issuance. + +To address this, we propose issuing a fixed portion of the pending +funds-to-be-issued in each block. This has the effect of smoothing out the +issuance curve of ZEC, ensuring a more consistent and predictable rate of coin +issuance, while still preserving the overall supply cap of 21,000,000 coins. +This mechanism by itself (without other anticipated changes) seeks to preserve +the core aspects of Zcash's issuance policy and aims to enhance predictability +and avoid sudden changes. By making this shift, the average block subsidy over +time will remain predictable with very gradual changes. + +However, we anticipate schemes proposed in [#draft-zsf]_ where the amount of +funds-to-be-issued may increase. In that scenario, this issuance mechanism +would distribute that increase starting in the immediately following block and +subsequent blocks. Because this distribution mechanism has an exponential +decay, such increases will be spread out in miniscule amounts to future blocks +over a long time period. This issuance mechanism thus provides a way for +potential increases or decreases of issuance while constraining those changes +to be small on a short time scale to avoid unexpected disruptions. + +Additionally, the current Bitcoin-style issuance does not take into account the +current balance of `ZsfBalanceAfter(h)`. If [#draft-zsf]_ were to activate +without a change to the issuance mechanism, then some funds would never be +disbursed after they are deposited back into the ZSF. + +# Requirements + +Smoothing the issuance curve is possible using an exponential decay formula +that satisfies the following requirements: + +## Issuance Requirements + +1. The issuance can be summarised into a reasonably simple explanation +2. Block subsidies approximate a continuous function +3. If there are funds in the ZSF, then the block subsidy must be non-zero, + preventing any final “unmined” zatoshis +4. For any 4 year period, all paid out block subsidies are approximately equal + to half of the ZSF at the beginning of that 4 year period, if there are no + deposits into the ZSF during those 4 years + +TODO daira: add a requirement that makes the initial total issuance match the previous total issuance + +# Specification + +## Goals + +We want to decrease the short-term impact of the deployment of this ZIP on +block reward recipients, and minimise the potential reputational risk to Zcash +of changing the block reward amount. + +## Constants + +Define constants: + +“`BLOCK_SUBSIDY_FRACTION`” = 4126 / 10,000,000,000 or `0.0000004126` + +"`DEPLOYMENT_BLOCK_HEIGHT`" = 2726400 + +## Issuance Calculation + +At the `DEPLOYMENT_BLOCK_HEIGHT`, nodes should switch from the current issuance +calculation, to the following: + +Given the block height `h` define a function **BlockSubsidy(h)**, such that: + +**BlockSubsidy(h)** = Block subsidy for a given `h`, that satisfies above +requirements. + +Using an exponential decay function for **BlockSubsidy** satisfies requirements +**R1** and **R2** above: + +`BlockSubsidy(h) = BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1)` + +Finally, to satisfy **R3** above we always round up to the next zatoshi. + +`BlockSubsidy(h) = ceiling(BLOCK_SUBSIDY_FRACTION * ZsfBalanceAfter(h - 1))` + +# Rationale + +## `BLOCK_SUBSIDY_FRACTION` + +Let `IntendedZSFFractionRemainingAfterFourYears` = 0.5. + +The value `4126 / 10_000_000_000` satisfies the approximation within +0.002%: + +`(1 - BLOCK_SUBSIDY_FRACTION)^PostBlossomHalvingInterval ≈ IntendedZSFFractionRemainingAfterFourYears` + +Meaning after a period of 4 years around half of `ZSF_BALANCE` will be paid out +as block subsidies, thus satisfying **R4**. + +The largest possible amount in the ZSF is MAX_MONEY, in the theoretically +possible case that all issued funds are deposited back into the ZSF. If this +happened, the largest interim sum in the block subsidy calculation would be +MAX_MONEY * 4126 + 10000000000. + +This uses 62.91 bits, which is just under the 63 bit limit for 64-bit signed +two's-complement integer amount types. + +The numerator could be brought closer to the limit by using a larger +denominator, but the difference in the amount issued would be very small. So we +chose a power-of-10 denominator for simplicity. + +TODO for ZIP owners: How many ZEC per day? + +## `DEPLOYMENT_BLOCK_HEIGHT` + +The deployment should happen at the next halving, which is block `2726400`. + +Since there is a planned halving at this point, there will already be a +significant "shock" caused by the drop in issuance caused by the halving. This +reduces surprise and thus increases security. Also, due to the nature of the +smoothed curve having a portion of the curve above the respective step function +line at times, this will maximally _reduce_ the issuance shock at the +`DEPLOYMENT_BLOCK_HEIGHT`. + +## Visualization of the Smoothed Curve + +The following graph illustrates compares issuance for the current halving-based +step function vs the smoothed curve. + +![A graph showing a comparison of the halving-based step function vs the smoothed curve](../rendered/assets/images/zip-0234-block_subsidy.png) + +The graph below shows the balance of the ZSF assuming smooth issuance is +implemented. + +![A graph showing the balance of the ZSF assuming smooth issuance is implemented](../rendered/assets/images/zip-0234-balance.png) + +# Deployment + +The implementation of this ZIP MUST be deployed at the same time or after the +Zcash Sustainability Fund is established (ZIP-XXX). + +# Appendix: Simulation + +The [ZSF simulator](https://github.com/eigerco/zsf-simulator) allows us to +simulate the effects of this ZIP on the ZSF balance and the block subsidy, as +well as generate plots like the ones above. Its output: + +``` +Last block is 47917869 in ~113.88 years +``` + +indicates that, assuming no ZEC is ever deposited to the ZSF, its balance will +be depleted after 113.88 years, and the block subsidy will be 0 ZEC after that +point. + +This fragment of the output + +``` +Halving 1 at block 1680000: + ZSF subsidies: 262523884819889 (~ 2625238.848 ZEC, 1.563 ZEC per block) + legacy subsidies: 262500000000000 (~ 2625000.000 ZEC, 1.562 ZEC per block) + difference: 23884819889 (~ 238 ZEC), ZSF/legacy: 1.0001 +``` + +shows that the difference between the smoothed out and the current issuance +schemes is 238 ZEC after 1680000 blocks (aroound 4 years). + +# References + +[1] RFC-2119: https://datatracker.ietf.org/doc/html/rfc2119 + +[2] ZIP-200: https://zips.z.cash/zip-0200 + +[3] ZIP-XXX: Placeholder for the ZSF ZIP diff --git a/src/zip-0253.md b/src/zip-0253.md new file mode 100644 index 000000000..35e497475 --- /dev/null +++ b/src/zip-0253.md @@ -0,0 +1,88 @@ + + ZIP: 253 + Title: Deployment of the NU6 Network Upgrade + Owners: Arya + Status: Proposed + Category: Consensus / Network + Created: 2024-07-17 + License: MIT + Discussions-To: + +# Terminology + +The key word "MUST" in this document are to be interpreted as described in +BCP 14 [^BCP14] when, and only when, they appear in all capitals. + +The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [^zip-0200]. + +The terms "Testnet" and "Mainnet" are to be interpreted as described in +section 3.12 of the Zcash Protocol Specification [^protocol-networks]. + +# Abstract + +This proposal defines the deployment of the NU6 network upgrade. + +# Specification + +## NU6 deployment + +The primary sources of information about NU6 consensus protocol changes are: + +* The Zcash Protocol Specification [^protocol]. +* ZIP 200: Network Upgrade Mechanism [^zip-0200]. +* ZIP 236: Blocks should balance exactly [^zip-0236]. +* ZIP 1015: Block Reward Allocation for Non-Direct Development Funding [^zip-1015]. +* ZIP 2001: Lockbox Funding Streams [^zip-2001]. + + +The network handshake and peer management mechanisms defined in ZIP 201 [^zip-0201] also apply to this upgrade. + +The following ZIPs have been updated in varying degrees to take into account NU6: + +* ZIP 207: Funding Streams [^zip-0207]. +* ZIP 214: Consensus rules for a Zcash Development Fund [^zip-0214]. + +The following network upgrade constants [^zip-0200] are defined for the NU6 upgrade: + +CONSENSUS_BRANCH_ID +: `0xC8E71055` + +ACTIVATION_HEIGHT (NU6) +: Testnet: 2976000 +: Mainnet: 2726400 + +MIN_NETWORK_PROTOCOL_VERSION (NU6) +: Testnet: `170110` +: Mainnet: `170120` + +For each network (Testnet and Mainnet), nodes compatible with NU6 activation on that network MUST advertise a network protocol version that is greater than or equal to the MIN_NETWORK_PROTOCOL_VERSION (NU6) for that activation. + +# Backward compatibility + +Prior to the network upgrade activating on each network, NU6 and pre-NU6 nodes are compatible and can connect to each other. However, NU6 nodes will have a preference for connecting to other NU6 nodes, so pre-NU6 nodes will gradually be disconnected in the run up to activation. + +Once the network upgrades, even though pre-NU6 nodes can still accept the numerically larger protocol version used by NU6 as being valid, NU6 nodes will always disconnect peers using lower protocol versions. + +NU6 does not define a new transaction version or impose a new minimum transaction version. NU6 transactions are therefore in the same v4 or v5 formats as NU5 transactions. This does not imply that transactions are valid across the NU6 activation, since signatures MUST use the appropriate consensus branch ID. + +# References + +[^BCP14]: [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14) + +[^protocol]: [Zcash Protocol Specification, Version 2024.5.1 or later](protocol/protocol.pdf) + +[^protocol-networks]: [Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet](protocol/protocol.pdf#networks) + +[^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst) + +[^zip-0201]: [ZIP 201: Network Peer Management for Overwinter](zip-0201.rst) + +[^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst) + +[^zip-0214]: [ZIP 214: Consensus rules for a Zcash Development Fund](zip-0214.rst) + +[^zip-0236]: [ZIP 236: Blocks should balance exactly](zip-0236.rst) + +[^zip-1015]: [ZIP 1015: Block Reward Allocation for Non-Direct Development Funding](zip-1015.rst) + +[^zip-2001]: [ZIP 2001: Lockbox Funding Streams](zip-2001.rst) From 45cfb2f8d41251bb73fea31d6da362406e7aeaec Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 13 Apr 2026 19:08:10 +0000 Subject: [PATCH 2/4] Fix typo 'aroound' -> 'around' in zip-0234 Agent-Logs-Url: https://github.com/shielded-nate/zips/sessions/afec0b27-bc72-4348-a984-ec23fce9d717 Co-authored-by: shielded-nate <185561036+shielded-nate@users.noreply.github.com> --- src/zip-0234.md | 2 +- zips/zip-0234.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/zip-0234.md b/src/zip-0234.md index 332baac6d..316bb52ba 100644 --- a/src/zip-0234.md +++ b/src/zip-0234.md @@ -210,7 +210,7 @@ Halving 1 at block 1680000: ``` shows that the difference between the smoothed out and the current issuance -schemes is 238 ZEC after 1680000 blocks (aroound 4 years). +schemes is 238 ZEC after 1680000 blocks (around 4 years). # References diff --git a/zips/zip-0234.md b/zips/zip-0234.md index 332baac6d..316bb52ba 100644 --- a/zips/zip-0234.md +++ b/zips/zip-0234.md @@ -210,7 +210,7 @@ Halving 1 at block 1680000: ``` shows that the difference between the smoothed out and the current issuance -schemes is 238 ZEC after 1680000 blocks (aroound 4 years). +schemes is 238 ZEC after 1680000 blocks (around 4 years). # References From 0cb63b18226c20b2b2265e88b83c9b4f6f40ada9 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 13 Apr 2026 19:09:26 +0000 Subject: [PATCH 3/4] Add DEVELOPMENT.md describing the mdbook-refactor plan Agent-Logs-Url: https://github.com/shielded-nate/zips/sessions/afec0b27-bc72-4348-a984-ec23fce9d717 Co-authored-by: shielded-nate <185561036+shielded-nate@users.noreply.github.com> --- DEVELOPMENT.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 DEVELOPMENT.md diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md new file mode 100644 index 000000000..a557c594a --- /dev/null +++ b/DEVELOPMENT.md @@ -0,0 +1,24 @@ +# mdbook Refactor + +This branch (`mdbook-refactor`) is the long-lived integration branch for the incremental +migration of the ZIPs rendering pipeline to [mdbook](https://rust-lang.github.io/mdBook/). + +## Goal + +Merge a series of bite-sized PRs here, each moving one step closer to the end state: + +- `mdbook build` builds all ZIPs into a single book +- The book can also be built with `nix flake` +- No render artifacts committed to git +- ToC organized by Category → Status → ZIP + +## Steps + +1. **Add mdbook scaffolding** ← *first PR, already open* +2. RST → Markdown conversion build script (all ZIPs in the book) +3. Dynamic `SUMMARY.md` generation (Category → Status → ZIP hierarchy) +4. Front page generated from `README.template` / `makeindex.sh` +5. Nix flake integration +6. Remove committed render artifacts from git tracking +7. (Bonus) GitHub Actions CI to publish to GitHub Pages +8. (Bonus) Integrate protocol spec as a book chapter From d1e565e1ca92d5bb09976d8ea2cff27a092c3ef2 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 13 Apr 2026 19:09:54 +0000 Subject: [PATCH 4/4] Remove DEVELOPMENT.md (not part of step-1 scaffolding) Agent-Logs-Url: https://github.com/shielded-nate/zips/sessions/afec0b27-bc72-4348-a984-ec23fce9d717 Co-authored-by: shielded-nate <185561036+shielded-nate@users.noreply.github.com> --- DEVELOPMENT.md | 24 ------------------------ 1 file changed, 24 deletions(-) delete mode 100644 DEVELOPMENT.md diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md deleted file mode 100644 index a557c594a..000000000 --- a/DEVELOPMENT.md +++ /dev/null @@ -1,24 +0,0 @@ -# mdbook Refactor - -This branch (`mdbook-refactor`) is the long-lived integration branch for the incremental -migration of the ZIPs rendering pipeline to [mdbook](https://rust-lang.github.io/mdBook/). - -## Goal - -Merge a series of bite-sized PRs here, each moving one step closer to the end state: - -- `mdbook build` builds all ZIPs into a single book -- The book can also be built with `nix flake` -- No render artifacts committed to git -- ToC organized by Category → Status → ZIP - -## Steps - -1. **Add mdbook scaffolding** ← *first PR, already open* -2. RST → Markdown conversion build script (all ZIPs in the book) -3. Dynamic `SUMMARY.md` generation (Category → Status → ZIP hierarchy) -4. Front page generated from `README.template` / `makeindex.sh` -5. Nix flake integration -6. Remove committed render artifacts from git tracking -7. (Bonus) GitHub Actions CI to publish to GitHub Pages -8. (Bonus) Integrate protocol spec as a book chapter