#Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 [1] 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. [2] [10]

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

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. [3]

Mainnet

The Zcash production network, as defined in the Zcash Protocol Specification. [3]

#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 [19]. It should be read in conjunction with ZIP 1014 [25], 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 [25].

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 [26] directs part of the block subsidy to a reserve, the distribution of which is to be determined via a future ZIP. ZIP 2001 [27] modified this ZIP to augment the funding stream mechanism with a common mechanism to implement this proposal. ZIP 271 [24] 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 [19] 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 [25], 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

• 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]:

• $𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$

• $𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$

• $𝖧𝖺𝗅𝗏𝗂𝗇𝗀(𝗁𝖾𝗂𝗀𝗁𝗍)$

• $𝖡𝗅𝗈𝖼𝗄𝖲𝗎𝖻𝗌𝗂𝖽𝗒(𝗁𝖾𝗂𝗀𝗁𝗍)$

We also define the following function:

• $𝖧𝖾𝗂𝗀𝗁𝗍𝖥𝗈𝗋𝖧𝖺𝗅𝗏𝗂𝗇𝗀(𝗁𝖺𝗅𝗏𝗂𝗇𝗀)$: Smallest $𝗁𝖾𝗂𝗀𝗁𝗍$ such that $𝖧𝖺𝗅𝗏𝗂𝗇𝗀(𝗁𝖾𝗂𝗀𝗁𝗍)=𝗁𝖺𝗅𝗏𝗂𝗇𝗀$

#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 $𝖣𝖤𝖥𝖤𝖱𝖱𝖤𝖣\_𝖯𝖮𝖮𝖫$. 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 $𝖣𝖤𝖥𝖤𝖱𝖱𝖤𝖣\_𝖯𝖮𝖮𝖫$.

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{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}

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 $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖥𝖴𝖭𝖣].𝖠𝖽𝖽𝗋𝖾𝗌𝗌𝖾𝗌$ is indexed from 0, and MUST have $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖥𝖴𝖭𝖣].𝖠𝖽𝖽𝗋𝖾𝗌𝗌𝖨𝗇𝖽𝖾𝗑(𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖥𝖴𝖭𝖣].𝖤𝗇𝖽𝖧𝖾𝗂𝗀𝗁𝗍-1)+1$ entries. (The protocol specification calls the same sequence $𝖿𝗌.𝖱𝖾𝖼𝗂𝗉𝗂𝖾𝗇𝗍𝗌$ and indexes it from 1. [12])

For a funding stream $𝖿𝗌$ we write $𝖿𝗌.𝖵𝖺𝗅𝗎𝖾(𝗁𝖾𝗂𝗀𝗁𝗍)$ for $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖿𝗌].𝖵𝖺𝗅𝗎𝖾(𝗁𝖾𝗂𝗀𝗁𝗍)$ and $𝖿𝗌.𝖱𝖾𝖼𝗂𝗉𝗂𝖾𝗇𝗍(𝗁𝖾𝗂𝗀𝗁𝗍)$ for $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖿𝗌].𝖠𝖽𝖽𝗋𝖾𝗌𝗌(𝗁𝖾𝗂𝗀𝗁𝗍)$ at each block height.

As of Revision 2, the definition of $𝖠𝖽𝖽𝗋𝖾𝗌𝗌𝖯𝖾𝗋𝗂𝗈𝖽$ above is replaced on each network by the following piecewise definition. Let $A$ be the NU7 activation height on that network, let $R=𝖭𝖴\mathrm{𝟩}𝖯𝗈𝖶𝖳𝖺𝗋𝗀𝖾𝗍𝖲𝗉𝖺𝖼𝗂𝗇𝗀𝖱𝖺𝗍𝗂𝗈=3$ and $𝖨𝗌𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝖾𝖽$ be as defined in ZIP 218 [20], let $C=𝖠𝖽𝖽𝗋𝖾𝗌𝗌𝖢𝗁𝖺𝗇𝗀𝖾𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$, let $I=𝖯𝗈𝗌𝗍𝖡𝗅𝗈𝗌𝗌𝗈𝗆𝖧𝖺𝗅𝗏𝗂𝗇𝗀𝖨𝗇𝗍𝖾𝗋𝗏𝖺𝗅$, and let $H_1=𝖧𝖾𝗂𝗀𝗁𝗍𝖥𝗈𝗋𝖧𝖺𝗅𝗏𝗂𝗇𝗀(1)$.

\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}

The $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖥𝖴𝖭𝖣].𝖠𝖽𝖽𝗋𝖾𝗌𝗌𝖨𝗇𝖽𝖾𝗑$ and $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖥𝖴𝖭𝖣].𝖠𝖽𝖽𝗋𝖾𝗌𝗌$ 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.

(The protocol specification [12] expresses this through $𝖯𝗋𝖾𝖭𝖴\mathrm{𝟩}𝖤𝗊𝗎𝗂𝗏𝖺𝗅𝖾𝗇𝗍𝖧𝖾𝗂𝗀𝗁𝗍(𝗁𝖾𝗂𝗀𝗁𝗍)$, the height that the block at $𝗁𝖾𝗂𝗀𝗁𝗍$ would have if the blocks from NU7 activation onward had been mined at the pre-NU7 target spacing: $𝗁𝖾𝗂𝗀𝗁𝗍$ if not $𝖨𝗌𝖭𝖴\mathrm{𝟩}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝖾𝖽(𝗁𝖾𝗂𝗀𝗁𝗍)$, and $A+(𝗁𝖾𝗂𝗀𝗁𝗍-A)/R$ otherwise. Its $𝖥𝖲𝖱𝖾𝖼𝗂𝗉𝗂𝖾𝗇𝗍𝖯𝖾𝗋𝗂𝗈𝖽$ applies the pre-NU7 formula to this rational number in place of $𝗁𝖾𝗂𝗀𝗁𝗍$, which is equal to the definition above after dividing the numerator and denominator of the second case by $R$.)

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 $𝖢𝗁𝖺𝗂𝗇𝖵𝖺𝗅𝗎𝖾𝖯𝗈𝗈𝗅𝖡𝖺𝗅𝖺𝗇𝖼{𝖾}^{𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽}$ 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 $𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆𝗌(𝗁𝖾𝗂𝗀𝗁𝗍)$ is the set of funding streams with recipient identifier $𝖣𝖤𝖥𝖤𝖱𝖱𝖤𝖣\_𝖯𝖮𝖮𝖫$ in the block at height $𝗁𝖾𝗂𝗀𝗁𝗍$.

Define $𝗍𝗈𝗍𝖺𝗅𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽𝖨𝗇𝗉𝗎𝗍(𝗁𝖾𝗂𝗀𝗁𝗍)$ as in [10]: it is $𝖹𝖨𝖯\mathrm{𝟤𝟩𝟣}𝖣𝗂𝗌𝖻𝗎𝗋𝗌𝖾𝗆𝖾𝗇𝗍𝖠𝗆𝗈𝗎𝗇𝗍$ at the height $𝖹𝖨𝖯\mathrm{𝟤𝟩𝟣}𝖠𝖼𝗍𝗂𝗏𝖺𝗍𝗂𝗈𝗇𝖧𝖾𝗂𝗀𝗁𝗍$ of the one-time lockbox disbursement specified in ZIP 271 [24], and zero at every other height.

The $𝖢𝗁𝖺𝗂𝗇𝖵𝖺𝗅𝗎𝖾𝖯𝗈𝗈𝗅𝖡𝖺𝗅𝖺𝗇𝖼{𝖾}^{𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽}$ chain value pool balance for a given block chain is the sum of the values of payments to $𝖣𝖤𝖥𝖤𝖱𝖱𝖤𝖣\_𝖯𝖮𝖮𝖫$ for transactions in the block chain, minus the lockbox disbursement from it in that block chain.

Equivalently, $𝖢𝗁𝖺𝗂𝗇𝖵𝖺𝗅𝗎𝖾𝖯𝗈𝗈𝗅𝖡𝖺𝗅𝖺𝗇𝖼{𝖾}^{𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽}$ for a block chain up to and including height $𝗁𝖾𝗂𝗀𝗁𝗍$ is given by $sum_{mathsf{h} = 0}^{mathsf{height}} left(mathsf{totalDeferredOutput}(mathsf{h}) - mathsf{totalDeferredInput}(mathsf{h})right)$.

Note: $𝗍𝗈𝗍𝖺𝗅𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽𝖮𝗎𝗍𝗉𝗎𝗍(𝗁)$ is necessarily zero for heights $𝗁$ prior to NU6 activation, and $𝗍𝗈𝗍𝖺𝗅𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽𝖨𝗇𝗉𝗎𝗍(𝗁)$ is necessarily zero for heights $𝗁$ 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 $𝖿𝗌.𝖱𝖾𝖼𝗂𝗉𝗂𝖾𝗇𝗍(𝗁𝖾𝗂𝗀𝗁𝗍)$ of a funding stream $𝖿𝗌$ at block 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 $\mathrm{𝟎}𝐱\mathrm{𝟎𝟐}$, as specified in [17].

Once the NU6 network upgrade activates:

• Rule 2 above is replaced by: In each block with coinbase transaction $𝖼𝖻$ at block height $𝗁𝖾𝗂𝗀𝗁𝗍$, for each funding stream $𝖿𝗌$ active at that block height with a recipient identifier other than $𝖣𝖤𝖥𝖤𝖱𝖱𝖤𝖣\_𝖯𝖮𝖮𝖫$ given by $𝖿𝗌.𝖱𝖾𝖼𝗂𝗉𝗂𝖾𝗇𝗍(𝗁𝖾𝗂𝗀𝗁𝗍)$, $𝖼𝖻$ MUST contain at least one output that pays $𝖿𝗌.𝖵𝖺𝗅𝗎𝖾(𝗁𝖾𝗂𝗀𝗁𝗍)$ 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 $𝖢𝗁𝖺𝗂𝗇𝖵𝖺𝗅𝗎𝖾𝖯𝗈𝗈𝗅𝖡𝖺𝗅𝖺𝗇𝖼{𝖾}^{𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽}$ above is that payments to the $𝖣𝖤𝖥𝖤𝖱𝖱𝖤𝖣\_𝖯𝖮𝖮𝖫$ cause $𝖥𝗎𝗇𝖽𝗂𝗇𝗀𝖲𝗍𝗋𝖾𝖺𝗆[𝖥𝖴𝖭𝖣].𝖵𝖺𝗅𝗎𝖾(𝗁𝖾𝗂𝗀𝗁𝗍)$ to be added to $𝖢𝗁𝖺𝗂𝗇𝖵𝖺𝗅𝗎𝖾𝖯𝗈𝗈𝗅𝖡𝖺𝗅𝖺𝗇𝖼{𝖾}^{𝖣𝖾𝖿𝖾𝗋𝗋𝖾𝖽}$ for the block chain including that block, and that the lockbox disbursement specified in ZIP 271 [24] causes $𝖹𝖨𝖯\mathrm{𝟤𝟩𝟣}𝖣𝗂𝗌𝖻𝗎𝗋𝗌𝖾𝗆𝖾𝗇𝗍𝖠𝗆𝗈𝗎𝗇𝗍$ 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]

#Deployment

This proposal was initially deployed with Canopy. [21]

Changes to support deferred funding streams were deployed with NU6. [22]

Revision 2 is intended to activate with NU7 as specified in ZIP 259 [23].

#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: [30] [31]

#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 [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).

#References