Revisions

• Revision 0: The initial version of this specification, as agreed upon by the Zcash community in ZIP 1014 25.

• Revision 1: Adds the Deferred Development Fund Chain Value Pool Balance as a potential recipient of funding stream outputs, as agreed upon by the Zcash community in ZIP 1015 26 and specified in ZIP 2001 27.

• Revision 2: Extends the remaining address period at NU7 activation and subsequent address periods in proportion to the change in target block spacing specified in ZIP 218 20, and permits transparent P2PKH addresses per ZIP 2008 28.

Definitions

We use the following constants and functions defined in 5, 9, and 10:

• \(\mathsf{BlossomActivationHeight}\)
• \(\mathsf{PostBlossomHalvingInterval}\)
• \(\mathsf{Halving}(\mathsf{height})\)
• \(\mathsf{BlockSubsidy}(\mathsf{height})\)

We also define the following function:

• \(\mathsf{HeightForHalving}(\mathsf{halving})\kern-0.03em\textsf{:}\) Smallest \(\mathsf{height}\) such that \(\mathsf{Halving}(\mathsf{height}) = \mathsf{halving}\)

Funding streams

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. 15

The value of a funding stream at a given block height is defined as:

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.

The value of each funding stream is paid to one of a pre-defined set of recipients, depending on the block height.

As of Revision 0, each recipient MUST be the string encoding of a transparent P2SH address or Sapling address (as specified in 6 or 7).

As of Revision 1, each recipient identifier MUST be either the string encoding of a transparent P2SH address or Sapling address (as specified in 6 or 7) or the identifier \(\mathsf{DEFERRED\_POOL}\kern-0.03em\textsf{.}\) The latter, added in the NU6 network upgrade 22, 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.

As of Revision 2, each recipient identifier MUST be either the string encoding of a transparent P2PKH or P2SH address or of a Sapling address (as specified in 6 or 7) or the identifier \(\mathsf{DEFERRED\_POOL}\kern-0.03em\textsf{.}\)

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:

This has the property that all active funding streams change the address they are using on the same block height schedule, aligned to the height of the first halving so that 48 funding periods fit cleanly within a halving interval. This can be leveraged to simplify implementations, by batching the necessary outputs for each funding period.

The sequence \(\mathsf{FundingStream[FUND].Addresses}\) is indexed from 0, and MUST have \(\mathsf{FundingStream[FUND].AddressIndex}(\mathsf{FundingStream[FUND].EndHeight} - 1) + 1\) entries. (The protocol specification calls the same sequence \(\mathsf{fs.Recipients}\) and indexes it from 1. 12)

For a funding stream \(\mathsf{fs}\) we write \(\mathsf{fs.Value}(\mathsf{height})\) for \(\mathsf{FundingStream[fs].Value}(\mathsf{height})\) and \(\mathsf{fs.Recipient}(\mathsf{height})\) for \(\mathsf{FundingStream[fs].Address}(\mathsf{height})\) at each block height.

As of Revision 2, the definition of \(\mathsf{AddressPeriod}\) above is replaced on each network by the following piecewise definition. Let \(A\) be the NU7 activation height on that network, let \(R = \mathsf{NU7PoWTargetSpacingRatio} = 3\) and \(\mathsf{IsNU7Activated}\) be as defined in ZIP 218 20, let \(C = \mathsf{AddressChangeInterval}\kern-0.03em\textsf{,}\) let \(I = \mathsf{PostBlossomHalvingInterval}\kern-0.03em\textsf{,}\) and let \(H_1 = \mathsf{HeightForHalving}(1)\kern-0.03em\textsf{.}\)

The \(\mathsf{FundingStream[FUND].AddressIndex}\) and \(\mathsf{FundingStream[FUND].Address}\) calculations above MUST use this definition for funding streams active at or after NU7 activation, including when calculating the period at a stream's start height. This preserves the address index at activation. If NU7 activates partway through an address period, its remaining block count is tripled; each subsequent period lasts 105000 blocks. At the 25-second target spacing, each period therefore retains approximately its previous wall-clock duration and funding amount, subject to per-block rounding.

Below is a visual representation of how stream addresses align with funding periods:

Example height	Stream A	Stream B	Stream C
AddressChangeInterval - 2	A0
AddressChangeInterval - 1	A0
AddressChangeInterval	A1	B0	C0
AddressChangeInterval + 1	A1	B0	C0
...
2*AddressChangeInterval - 2	A1	B0	C0
2*AddressChangeInterval - 1	A1	B0	C0
2*AddressChangeInterval	A2		C1
2*AddressChangeInterval + 1	A2		C1
...
PostBlossomHalvingInterval - 2	A2		C1
PostBlossomHalvingInterval - 1	A2		C1
PostBlossomHalvingInterval			C2
PostBlossomHalvingInterval + 1			C2
...
PostBlossomHalvingInterval + AddressChangeInterval/2			C2
...
PostBlossomHalvingInterval + 2*AddressChangeInterval - 1			C2
PostBlossomHalvingInterval + 2*AddressChangeInterval			C3
...
PostBlossomHalvingInterval + 5*AddressChangeInterval - 1			C3
PostBlossomHalvingInterval + 5*AddressChangeInterval			C4

The last rows illustrate Revision 2 with NU7 activating halfway through the period of address C2, at height PostBlossomHalvingInterval + AddressChangeInterval/2: the remaining half of that period is tripled, and the period of C3 lasts 3*AddressChangeInterval blocks.

On Mainnet, Canopy activated exactly at the point when the Founders’ Reward expired, at block height 1046400. On Testnet, there was a shortened Founders’ Reward address period prior to Canopy activation.

Deferred Development Fund Chain Value Pool Balance

As of Revision 1 of this specification, full node implementations MUST track an additional \(\mathsf{ChainValuePoolBalance^{Deferred}}\) chain value pool balance, in addition to the other chain value pool balances defined in 4 (see also ZIP 209 16).

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\_POOL}\) in the block at height \(\mathsf{height}\kern-0.03em\textsf{.}\)

Define \(\mathsf{totalDeferredInput}(\mathsf{height})\) as in 10: it is \(\mathsf{ZIP271DisbursementAmount}\) at the height \(\mathsf{ZIP271ActivationHeight}\) of the one-time lockbox disbursement specified in ZIP 271 24, and zero at every other 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\_POOL}\) for transactions in the block chain, minus the lockbox disbursement from it in that 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}} \left(\mathsf{totalDeferredOutput}(\mathsf{h}) - \mathsf{totalDeferredInput}(\mathsf{h})\right)\kern-0.03em\textsf{.}\)

Note: \(\mathsf{totalDeferredOutput}(\mathsf{h})\) is necessarily zero for heights \(\mathsf{h}\) prior to NU6 activation, and \(\mathsf{totalDeferredInput}(\mathsf{h})\) is necessarily zero for heights \(\mathsf{h}\) prior to NU6.1 activation.

Consensus rules

Prior to activation of the Canopy network upgrade, the existing consensus rule for payment of the original Founders’ Reward is enforced. 11

Once the Canopy network upgrade activates:

1. The existing consensus rule for payment of the Founders’ Reward 11 is no longer active. (This would be the case under the preexisting consensus rules for Mainnet, but not for Testnet.)
2. 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.
3. The recipient \(\mathsf{fs.Recipient}(\mathsf{height})\) of a funding stream \(\mathsf{fs}\) at block height \(\mathsf{height}\) is as defined in Funding streams.
4. The "prescribed way" to pay a transparent P2SH address is to use a standard P2SH script of the form OP_HASH160 RedeemScriptHash OP_EQUAL as the scriptPubKey 29, where RedeemScriptHash is the 20-byte script hash in the raw encoding of the address 6.

   As of Revision 2, the "prescribed way" to pay a transparent P2PKH address is to use OP_DUP OP_HASH160 <keyHash> OP_EQUALVERIFY OP_CHECKSIG as the output's scriptPubKey, where <keyHash> is the direct push of the 20-byte public-key hash decoded from the recipient's Base58Check address. No other script encoding satisfies this funding-stream payment rule.

5. The "prescribed way" to pay a Sapling address is as defined in 18. 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}\kern-0.03em\textsf{,}\) as specified in 17.

Once the NU6 network upgrade activates:

• Rule 2 above is replaced by: In each block with coinbase transaction \(\mathsf{cb}\) at block height \(\mathsf{height}\kern-0.03em\textsf{,}\) for each funding stream \(\mathsf{fs}\) active at that block height with a recipient identifier other than \(\mathsf{DEFERRED\_POOL}\) given by \(\mathsf{fs.Recipient}(\mathsf{height})\kern-0.03em\textsf{,}\) \(\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, distinct from the outputs counted for every other such funding stream and for the lockbox disbursement outputs required by ZIP 271 24.

Note: The outputs required by rule 2 before NU6 activation are likewise distinct for each funding stream. In particular, a single output cannot be counted for two active funding streams that have the same recipient and the same value.

Rule 5 has subsequently been clarified as follows:

• The "prescribed way" to pay a Sapling or Orchard address is as defined in 18, using the post-Heartwood consensus rules specified for shielded outputs of coinbase transactions in 8. A Sapling address is paid by a Sapling-pool output. An Orchard address is paid by an Orchard-pool output before NU6.3 activation, and by an Ironwood-pool output from NU6.3 activation onward, since coinbase transactions can then contain no Orchard-pool component 18.

Note: The recipient identifiers permitted above do not include Orchard addresses; the "prescribed way" to pay an Orchard address is defined in anticipation of a future change. Up to and including NU7 there have been no funding streams defined with a shielded payment address as a recipient. That might change in future, so implementations are encouraged to support Sapling and Orchard addresses as recipients, as permitted by 18.

These rules are reproduced in 12.

The effect of the definition of \(\mathsf{ChainValuePoolBalance^{Deferred}}\) above is that payments to the \(\mathsf{DEFERRED\_POOL}\) cause \(\mathsf{FundingStream[FUND].Value}(\mathsf{height})\) to be added to \(\mathsf{ChainValuePoolBalance^{Deferred}}\) for the block chain including that block, and that the lockbox disbursement specified in ZIP 271 24 causes \(\mathsf{ZIP271DisbursementAmount}\) to be subtracted from it.

For the funding stream definitions activated at Canopy, NU6, and NU6.1, and their changes at NU7, see ZIP 214. 19 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 13

2026-10-13

• Defined fs.Value and fs.Recipient, and required each address list to cover its funding stream's height range.
• Clarified that each funding stream requires a distinct output.
• Defined the "prescribed way" to pay any P2SH address, and applied the P2PKH payment rule of ZIP 2008 28 to Revision 2.
• Clarified the "prescribed way" to pay an Orchard address from NU6.3, and that Orchard addresses are not permitted recipients.
• Deducted the ZIP 271 lockbox disbursement from the deferred development fund chain value pool balance.
• Corrected the address-period example table, section numbers, reference titles, and tense.
• Added the reference implementation of Revision 2, and updated the protocol specification citations.

2026-09-30

• Applied ZIP 2008 28 to Revision 2 of this ZIP.

2026-09-24

• Drafted Revision 2 for the NU7 address-period schedule.

2025-08-19

• Defined Revision 0 and Revision 1 explicitly.

2024-10-31

• Released Revision 1.

2024-09-26

• Applied ZIP 2001 27 to this ZIP (implicitly defining Revision 1).

2020-05-30

• Released Revision 0 (status changed from Draft to Proposed).