Funding streams 
- A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), and an end height (exclusive).
- By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example.
+ A funding stream is defined by a block subsidy fraction (represented as a numerator and a denominator), a start height (inclusive), an end height (exclusive), and a sequence of recipients as defined below.
+ By defining the issuance as a proportion of the total block subsidy, rather than absolute zatoshis, this ZIP dovetails with any changes to both block target spacing and issuance-per-block rates. Such a change occurred at the Blossom network upgrade, for example.
The value of a funding stream at a given block height is defined as:
\(\mathsf{FundingStream[FUND].Value}(\mathsf{height}) =
\mathsf{floor}\left(
\frac{\mathsf{BlockSubsidy}(\mathsf{height}) \,\cdot\, \mathsf{FundingStream[FUND].ValueNumerator}}{\mathsf{FundingStream[FUND].ValueDenominator}}
\right)\)
An active funding stream at a given block height is defined as a funding stream for which the block height is less than its end height, but not less than its start height.
- Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.
+ The funding streams are paid to one of a pre-defined set of recipients, depending on the block height. Each recipient identifier MUST be either the string encoding of a transparent P2SH address or Sapling address (as specified in or [#protocol-saplingpaymentaddrencoding]) to be paid by an output in the coinbase transaction, or the identifier
+ \(\mathsf{DEFERRED}\_\mathsf{POOL}\)
+ . The latter, added in the NU6 network upgrade , indicates that the value is to be paid to a reserve to be used for development funding, the distribution of which is to be determined via a future ZIP.
Each address is used for at most 1/48th of a halving interval, creating a roughly-monthly sequence of funding periods. The address to be used for a given block height is defined as follows:
\(\begin{eqnarray*}
\mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\
@@ -195,22 +198,83 @@
On Mainnet, Canopy is planned to activate exactly at the point when the Founders' Reward expires, at block height 1046400. On Testnet, there will be a shortened Founders' Reward address period prior to Canopy activation.
+
Deferred Development Fund Chain Value Pool Balance
+ Full node implementations MUST track an additional
+ \(\mathsf{ChainValuePoolBalance^{Deferred}}\)
+ chain value pool balance, in addition to the Sprout, Sapling, and Orchard chain value pool balances.
+ Define
+ \(\mathsf{totalDeferredOutput}(\mathsf{height}) := \sum_{\mathsf{fs} \in \mathsf{DeferredFundingStreams}(\mathsf{height})} \mathsf{fs.Value}(\mathsf{height})\)
+ where
+ \(\mathsf{DeferredFundingStreams}(\mathsf{height})\)
+ is the set of funding streams with recipient identifier
+ \(\mathsf{DEFERRED}\_\mathsf{POOL}\)
+ in the block at height
+ \(\mathsf{height}\)
+ .
+ The
+ \(\mathsf{ChainValuePoolBalance^{Deferred}}\)
+ chain value pool balance for a given block chain is the sum of the values of payments to
+ \(\mathsf{DEFERRED}\_\mathsf{POOL}\)
+ for transactions in the block chain.
+ Equivalently,
+ \(\mathsf{ChainValuePoolBalance^{Deferred}}\)
+ for a block chain up to and including height
+ \(\mathsf{height}\)
+ is given by
+ \(\sum_{\mathsf{h} = 0}^{\mathsf{height}} \mathsf{totalDeferredOutput}(\mathsf{h})\)
+ .
+ Note:
+ \(\mathsf{totalDeferredOutput}(\mathsf{h})\)
+ is necessarily zero for heights
+ \(\mathsf{h}\)
+ prior to NU6 activation.
+
Consensus rules
- Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced.
+ Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders' Reward is enforced.
Once the Canopy network upgrade activates:
- - The existing consensus rule for payment of the Founders' Reward is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
- - The coinbase transaction in each block MUST contain at least one output per active funding stream that pays the stream's value in the prescribed way to the stream's recipient address for the block's height.
+ - The existing consensus rule for payment of the Founders' Reward is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
+ - In each block with coinbase transaction
+ \(\mathsf{cb}\)
+ at block height
+ \(\mathsf{height}\)
+ , for each funding stream
+ \(\mathsf{fs}\)
+ active at that block height with a recipient identifier other than
+ \(\mathsf{DEFERRED}\_\mathsf{POOL}\)
+ given by
+ \(\mathsf{fs.Recipient}(\mathsf{height})\!\)
+ ,
+ \(\mathsf{cb}\)
+ MUST contain at least one output that pays
+ \(\mathsf{fs.Value}(\mathsf{height})\)
+ zatoshi in the prescribed way to the address represented by that recipient identifier.
+ -
+ \(\mathsf{fs.Recipient}(\mathsf{height})\)
+ is defined as
+ \(\mathsf{fs.Recipients_{\,\fs.RecipientIndex}}(\mathsf{height})\!\)
+ .
- The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form
OP_HASH160 RedeemScriptHash(height) OP_EQUAL as the scriptPubKey.
- - The "prescribed way" to pay a Sapling address is as defined in . That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
- \(\mathbf{0x02}\)
- , as specified in .
+ - The "prescribed way" to pay a Sapling address is as defined in . That is, all Sapling outputs in coinbase transactions (including, but not limited to, outputs for funding streams) MUST have valid note commitments when recovered using a 32-byte array of zeroes as the outgoing viewing key. In this case the note plaintext lead byte MUST be
+ \(\mathbf{0x02}\!\)
+ , as specified in .
- For the funding stream definitions to be activated at Canopy, see ZIP 214. Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process.
+ These rules are reproduced in [#protocol-fundingstreams].
+ The effect of the definition of
+ \(\mathsf{ChainValuePoolBalance^{Deferred}}\)
+ above is that payments to the
+ \(\mathsf{DEFERRED}\_\mathsf{POOL}\)
+ cause
+ \(\mathsf{FundingStream[FUND].Value}(\mathsf{height})\)
+ to be added to
+ \(\mathsf{ChainValuePoolBalance^{Deferred}}\)
+ for the block chain including that block.
+ For the funding stream definitions to be activated at Canopy and at NU6, see ZIP 214. Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process.
Deployment
- This proposal is intended to be deployed with Canopy.
+ This proposal was initially deployed with Canopy.
+ Changes to support deferred funding streams are to be deployed with NU6.
Backward compatibility
This proposal intentionally creates what is known as a "bilateral consensus rule change". Use of this mechanism requires that all network participants upgrade their software to a compatible version within the upgrade window. Older software will treat post-upgrade blocks as invalid, and will follow any pre-upgrade consensus branch that persists.
@@ -227,7 +291,7 @@
| 1 |
- 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" |
+ 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> |
@@ -235,7 +299,7 @@
| 2 |
- Zcash Protocol Specification, Version 2021.2.16 or later |
+ Zcash Protocol Specification, Version 2024.5.1 or later <protocol/protocol.pdf> |
@@ -243,7 +307,7 @@
| 3 |
- Zcash Protocol Specification, Version 2021.2.16. Section 3.10: Block Subsidy and Founders' Reward |
+ Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.10: Block Subsidy and Founders' Reward <protocol/protocol.pdf#subsidyconcepts> |
@@ -251,7 +315,7 @@
| 4 |
- Zcash Protocol Specification, Version 2021.2.16. Section 3.12: Mainnet and Testnet |
+ Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.12: Mainnet and Testnet <protocol/protocol.pdf#networks> |
@@ -259,95 +323,143 @@
| 5 |
- Zcash Protocol Specification, Version 2021.2.16. Section 5.3: Constants |
+ Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants <protocol/protocol.pdf#constants> |
-