Changes to ZIP 207 11

The following paragraph is added to the section Motivation:

As of NU6, ZIP 1015 17 directs part of the block reward to a reserve, the distribution of which is to be determined via a future ZIP. ZIP 2001 18 modified the present ZIP to augment the funding stream mechanism with a common mechanism to implement this proposal.

In the section Funding streams 12, instead of:

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

it will be modified to read:

Each element of \(\mathsf{fs.Recipients}\) MUST represent either a transparent P2SH address as specified in 6, or a Sapling shielded payment address as specified in 7, or the identifier \(\mathsf{DEFERRED\_POOL}\!\) .

After the section Funding streams, a new section is added with the heading "Deferred Development Fund Chain Value Pool Balance" and the following contents:

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\_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\_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.

In the section Consensus rules 13, instead of:

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

it will be modified to read:

• 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.
• \(\mathsf{fs.Recipient}(\mathsf{height})\) is defined as \(\mathsf{fs.Recipients_{\,fs.RecipientIndex}}(\mathsf{height})\!\) .

After the list of post-Canopy consensus rules, the following paragraphs are added:

These rules are reproduced in 10.

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.

In the section Deployment 14, the following sentence is added:

Changes to support deferred funding streams are to be deployed with NU6. 15

Changes to the Zcash Protocol Specification

In section 4.17 Chain Value Pool Balances 5 (which is new in version 2024.5.1 of the protocol specification), include the following:

Define \(\mathsf{totalDeferredOutput}\) as in 9.

Then, consistent with 11, the deferred development fund chain value pool balance for a block chain up to and including height \(\mathsf{height}\) is given by \(\mathsf{ChainValuePoolBalance^{Deferred}}(\mathsf{height}) := \sum_{\mathsf{h} = 0}^{\mathsf{height}} \mathsf{totalDeferredOutput}(\mathsf{h})\!\) .

Non-normative notes:

• \(\mathsf{totalDeferredOutput}(\mathsf{h})\) is necessarily zero for heights \(\mathsf{h}\) prior to NU6 activation.
• Currently there is no way to withdraw from the deferred development fund chain value pool, so there is no possibility of it going negative. Therefore, no consensus rule to prevent that eventuality is needed at this time.

The total issued supply of a block chain at block height \(\mathsf{height}\) is given by the function:

In section 7.1.2 Transaction Consensus Rules 8, instead of:

The total value in zatoshi of transparent outputs from a coinbase transaction, minus \(\mathsf{v^{balanceSapling}}\!\) , minus \(\mathsf{v^{balanceOrchard}}\!\) , MUST NOT be greater than the value in zatoshi of the block subsidy plus the transaction fees paid by transactions in this block.

it will be modified to read:

For the block at block height \(\mathsf{height}\!\) :

• define the "total output value" of its coinbase transaction to be the total value in zatoshi of its transparent outputs, minus \(\mathsf{v^{balanceSapling}}\!\) , minus \(\mathsf{v^{balanceOrchard}}\!\) , plus \(\mathsf{totalDeferredOutput}(\mathsf{height})\!\) ;
• define the "total input value" of its coinbase transaction to be the value in zatoshi of the block subsidy, plus the transaction fees paid by transactions in the block.

The total output value of a coinbase transaction MUST NOT be greater than its total input value.

where \(\mathsf{totalDeferredOutput}(\mathsf{height})\) is defined consistently with ZIP 207.

Note: this ZIP and ZIP 236 both make changes to the above rule. Their combined effect is that the last paragraph will be replaced by:

[Pre-NU6] The total output value of a coinbase transaction MUST NOT be greater than its total input value.

[NU6 onward] The total output value of a coinbase transaction MUST be equal to its total input value.

Section 7.10 Payment of Funding Streams 10 contains language and definitions copied from ZIP 207; it should be updated to reflect the changes made above.

The second paragraph of section 1.2 High-level Overview 2 should be updated to take into account the deferred chain value pool. Since that section of the specification is entirely non-normative, we do not give the full wording change here.