Definitions

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

• \(\mathsf{BlossomActivationHeight}\)
• \(\mathsf{PostBlossomHalvingInterval}\)
• \(\mathsf{Halving}(\mathsf{height})\)
• \(\mathsf{BlockSubsidy}(\mathsf{height})\)
• \(\mathsf{RedeemScriptHash}(\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. 14

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 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 6 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 19, 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:

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.

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

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

Once the Canopy network upgrade activates:

• The existing consensus rule for payment of the Founders' Reward 10 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 16. 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 15.

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