Funding Streams

Preamble

ZIP

207

Title

Funding Streams

Owners

• Jack Grigg
• Daira-Emma Hopwood

Status

[Revision 0: Canopy, Revision 1: NU6] Final, [Revision 2: NU7] Draft

Category

Consensus

Created

2019-01-04

Last-Updated

2026-10-13

License

MIT

Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 ¹ when, and only when, it appears in all capitals.

The terms "block subsidy" and "halving" in this document are to be interpreted as described in sections 3.10 and 7.8 of the Zcash Protocol Specification. ²³

The terms "consensus branch" and "network upgrade" in this document are to be interpreted as described in ZIP 200.⁴

The terms below are to be interpreted as follows:

Canopy

Code-name for the fifth Zcash network upgrade, also known as Network Upgrade 4.

Testnet

The Zcash test network, as defined in the Zcash Protocol Specification.⁵

Mainnet

The Zcash production network, as defined in the Zcash Protocol Specification.⁶

Abstract

This proposal specifies a mechanism to support funding streams, distributed from a portion of the block subsidy for a specified range of block heights.

This is intended as a means of implementing the Zcash Development Fund, using the funding stream definitions specified in ZIP 214⁷. It should be read in conjunction with ZIP 1014⁸, which describes the high-level requirements for that fund.

Revision 2 preserves the approximate duration and value of each address period when NU7 reduces the target block spacing to 25 seconds.

Motivation

Motivation for the Zcash Development Fund is considered in ZIP 1014⁹.

This ZIP 207 was originally proposed for the Blossom network upgrade, as a means of splitting the original Founders’ Reward into several streams. It was then withdrawn when such splitting was judged to be unnecessary at the consensus level. Since the capabilities of the funding stream mechanism match the requirements for the Zcash Development Fund, the ZIP was reintroduced for that purpose in the Canopy upgrade in order to reuse specification, analysis, and implementation effort.

As of NU6, ZIP 1015¹⁰ directs part of the block subsidy to a reserve, the distribution of which is to be determined via a future ZIP. ZIP 2001¹¹ modified this ZIP to augment the funding stream mechanism with a common mechanism to implement this proposal. ZIP 271¹² specifies a one-time disbursement from this reserve at NU6.1 activation, which is deducted from the Deferred Development Fund Chain Value Pool Balance.

Requirements

The primary requirement of this ZIP is to provide a mechanism for specifying the funding streams that are used in ZIP 214¹³ to implement the Zcash Development Fund. It should be sufficiently expressive to handle both the main three "slices" (BP, ZF, and MG) defined in ZIP 1014¹⁴, and also (with additional funding stream definitions) the "direct grant option" described in that ZIP.

As for the original Founders’ Reward, a mechanism is provided to allow addresses for a given funding stream to be changed on a roughly-monthly basis, so that keys that are not yet needed may be kept off-line as a security measure.

Specification

Revisions

Definitions

We use the following constants and functions defined in²⁰, ²¹, and²²:

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

We also define the following function:

• $\mathsf{HeightForHalving}(\mathsf{halving})$: 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.²³

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.

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 ²⁴ or²⁵).

As of Revision 1, each recipient identifier MUST be either the string encoding of a transparent P2SH address or Sapling address (as specified in ²⁶ or²⁷) or the identifier $\mathsf{DEFERRED\_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.

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 ²⁹ or³⁰) or the identifier $\mathsf{DEFERRED\_POOL}$.

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{aligned} \begin{array}{rcl} \mathsf{AddressChangeInterval} &=& \mathsf{PostBlossomHalvingInterval} / 48 \\ \mathsf{AddressPeriod}(\mathsf{height}) &=& \mathsf{floor}\left( {\small\frac{\mathsf{height} + \mathsf{PostBlossomHalvingInterval} - \mathsf{HeightForHalving}(1)}{\mathsf{AddressChangeInterval}}} \right) \\ \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height}) &=& \mathsf{AddressPeriod}(\mathsf{height}) - \\&&\hspace{2em} \mathsf{AddressPeriod}(\mathsf{FundingStream[FUND].StartHeight}) \\ \mathsf{FundingStream[FUND].Address}(\mathsf{height}) &=& \mathsf{FundingStream[FUND].Addresses[} \\&&\hspace{2em} \mathsf{FundingStream[FUND].AddressIndex}(\mathsf{height})\mathsf{]} \end{array} \end{aligned}$$

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.³¹)

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³², let $C = \mathsf{AddressChangeInterval}$, let $I = \mathsf{PostBlossomHalvingInterval}$, and let $H_1 = \mathsf{HeightForHalving}(1)$.

$$\begin{aligned} \mathsf{AddressPeriod}(\mathsf{height}) = \begin{cases} \mathsf{floor}\left( \dfrac{\mathsf{height} + I - H_1}{C} \right), &\textsf{if not } \mathsf{IsNU7Activated}(\mathsf{height}) \\ \mathsf{floor}\left( \dfrac{R(A + I - H_1) + \mathsf{height} - A}{RC} \right), &\textsf{otherwise} \end{cases} \end{aligned}$$

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 AddressChangeInterval - 1	A0 A0
AddressChangeInterval	A1	B0	C0
AddressChangeInterval + 1 ...	A1	B0	C0
2*AddressChangeInterval - 2	A1	B0	C0
2*AddressChangeInterval - 1 2*AddressChangeInterval 2*AddressChangeInterval + 1 ... PostBlossomHalvingInterval - 2 PostBlossomHalvingInterval - 1 PostBlossomHalvingInterval PostBlossomHalvingInterval + 1 ... PostBlossomHalvingInterval + AddressChangeInterval/2 ... PostBlossomHalvingInterval + 2*AddressChangeInterval - 1 PostBlossomHalvingInterval + 2*AddressChangeInterval ... PostBlossomHalvingInterval + 5*AddressChangeInterval - 1 PostBlossomHalvingInterval + 5*AddressChangeInterval	A1 A2 A2 A2 A2	B0	C0 C1 C1 C1 C1 C2 C2 C2 C2 C3 C3 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 ³³ (see also ZIP 209³⁴).

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}$.

Define $\mathsf{totalDeferredInput}(\mathsf{height})$ as in ³⁵: it is $\mathsf{ZIP271DisbursementAmount}$ at the height $\mathsf{ZIP271ActivationHeight}$ of the one-time lockbox disbursement specified in ZIP 271³⁶, 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)$.

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.³⁷

Once the Canopy network upgrade activates:

1. 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.)

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³⁹, where RedeemScriptHash is the 20-byte script hash in the raw encoding of the address ⁴⁰.

   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⁴¹. 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⁴².

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}$, 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})$, $\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⁴³.

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 ⁴⁴, using the post-Heartwood consensus rules specified for shielded outputs of coinbase transactions in⁴⁵. 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⁴⁶.

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⁴⁷.

These rules are reproduced in⁴⁸.

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 ⁴⁹ 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.⁵⁰ Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process.⁵¹

Deployment

This proposal was initially deployed with Canopy.⁵²

Changes to support deferred funding streams were deployed with NU6.⁵³

Revision 2 is intended to activate with NU7 as specified in ZIP 259 ⁵⁴.

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.

Reference Implementation

• https://github.com/zcash/zcash/pull/4560
• https://github.com/zcash/zcash/pull/4675
• https://github.com/zcash/zcash/pull/4830
• Revision 2, Zebra:⁵⁵⁵⁶

Change History

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⁵⁷ 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⁵⁸ 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⁵⁹ to this ZIP (implicitly defining Revision 1).

2020-05-30

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

References

---

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"↩︎

2. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.10: Block Subsidy, Funding Streams, and Founders’ Reward↩︎

3. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.8: Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders’ Reward↩︎

4. ZIP 200: Network Upgrade Mechanism↩︎

5. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet↩︎

6. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 3.12: Mainnet and Testnet↩︎

7. ZIP 214: Consensus rules for a Zcash Development Fund↩︎

8. ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants↩︎

9. ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants↩︎

10. ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding↩︎

11. ZIP 2001: Lockbox Funding Streams↩︎

12. ZIP 271: Dev Fund Extension and One-Time Disbursement↩︎

13. ZIP 214: Consensus rules for a Zcash Development Fund↩︎

14. ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants↩︎

15. ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants↩︎

16. ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding↩︎

17. ZIP 2001: Lockbox Funding Streams↩︎

18. ZIP 218: 25-second Block Target Spacing↩︎

19. ZIP 2008: Update to FS_FPF_ZCG_H3 address list↩︎

20. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.3: Constants↩︎

21. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.7.3: Difficulty adjustment↩︎

22. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.8: Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders’ Reward↩︎

23. ZIP 208: Shorter Block Target Spacing↩︎

24. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.1.1: Transparent Addresses↩︎

25. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.3.1: Sapling Payment Addresses↩︎

26. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.1.1: Transparent Addresses↩︎

27. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.3.1: Sapling Payment Addresses↩︎

28. ZIP 253: Deployment of the NU6 Network Upgrade↩︎

29. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.1.1: Transparent Addresses↩︎

30. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.3.1: Sapling Payment Addresses↩︎

31. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.10: Payment of Funding Streams, Deferred Lockbox, and Lockbox Disbursement↩︎

32. ZIP 218: 25-second Block Target Spacing↩︎

33. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 4.17: Chain Value Pool Balances↩︎

34. ZIP 209: Prohibit Out-of-Range Chain Value Pool Balances↩︎

35. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.8: Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders’ Reward↩︎

36. ZIP 271: Dev Fund Extension and One-Time Disbursement↩︎

37. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.9: Payment of Founders’ Reward↩︎

38. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.9: Payment of Founders’ Reward↩︎

39. Transactions: P2SH Scripts — Bitcoin Developer Guide↩︎

40. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 5.6.1.1: Transparent Addresses↩︎

41. ZIP 213: Shielded Coinbase↩︎

42. ZIP 212: Allow Recipient to Derive Ephemeral Secret from Note Plaintext↩︎

43. ZIP 271: Dev Fund Extension and One-Time Disbursement↩︎

44. ZIP 213: Shielded Coinbase↩︎

45. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.1.2: Transaction Consensus Rules↩︎

46. ZIP 213: Shielded Coinbase↩︎

47. ZIP 213: Shielded Coinbase↩︎

48. Zcash Protocol Specification, Version 2026.8.0 [NU6.3]. Section 7.10: Payment of Funding Streams, Deferred Lockbox, and Lockbox Disbursement↩︎

49. ZIP 271: Dev Fund Extension and One-Time Disbursement↩︎

50. ZIP 214: Consensus rules for a Zcash Development Fund↩︎

51. ZIP 0: ZIP Process↩︎

52. ZIP 251: Deployment of the Canopy Network Upgrade↩︎

53. ZIP 253: Deployment of the NU6 Network Upgrade↩︎

54. ZIP 259: Deployment of the NU7 Network Upgrade↩︎

55. Zebra PR 11529: feat(consensus)!: implement NU7 spacing, funding schedules, and shielded limits↩︎

56. Zebra PR 11527: feat(nu7)!: prepare ZIP 259 deployment and ZIP 2008 payouts↩︎

57. ZIP 2008: Update to FS_FPF_ZCG_H3 address list↩︎

58. ZIP 2008: Update to FS_FPF_ZCG_H3 address list↩︎

59. ZIP 2001: Lockbox Funding Streams↩︎