Definitions

We use the following constants and functions defined in 5, 6, 7, and 8:

• \(\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), 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. 11

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.

Each funding stream has an associated sequence of recipient addresses, each of which MUST be either a transparent P2SH address or a Sapling address.

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.

Consensus rules

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

Once the Canopy network upgrade activates:

• The existing consensus rule for payment of the Founders' Reward 8 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 "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 13. 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 12.

For the funding stream definitions to be activated at Canopy, see ZIP 214. 14 Funding stream definitions can be added, changed, or deleted in ZIPs associated with subsequent network upgrades, subject to the ZIP process. 9