ZIP: 271
Title: Dev Fund Extension and One-Time Disbursement
Owners: Daira-Emma Hopwood <[email protected]>
        Kris Nuttycombe <[email protected]>
        Jack Grigg <[email protected]>
Status: Proposed
Category: Consensus / Process
Created: 2025-02-19
License: MIT
Pull-Request: <https://github.com/zcash/zips/pull/989>
              <https://github.com/zcash/zips/pull/1014>
              <https://github.com/zcash/zips/pull/1015>
              <https://github.com/zcash/zips/pull/1099>

Terminology

The key words “MUST”, “MUST NOT”, and “RECOMMENDED” in this document are to be interpreted as described in BCP 14 ¹ when, and only when, they appear in all capitals.

Abstract

This ZIP proposes an extension of protocol-based development funding, in the context of multiple alternatives for distributing funds that have accrued to the Deferred Dev Fund Lockbox. This proposal is intended to be evaluated in the context of the Community And Coinholder Funding Model ² proposal.

At a high level, this ZIP proposes:

• A one-time disbursement of the full contents of the lockbox to a transparent P2SH multisig address, at the time of the activation of this ZIP. The key-holders of that address are then responsible for distributing the resulting funds in the form of development grants, according to the rules set by ².
• Extension of protocol-based development funding blocks starting from the scheduled end height of the current FS_DEFERRED and FS_FPF_ZCG funding streams defined in ZIP 1015 ³.
• A variety of different mechanisms that may be used for distributing funds that accrue in the lockbox during the period of the extension.

Requirements

• Funds are held in a multisig P2SH address that is resistant to compromise of some of the parties' keys, up to a given threshold.
• No single party’s non-cooperation or loss of keys is able to cause any Protocol-defined Ecosystem Funding to be locked up unrecoverably.
• The funds previously accrued to the Deferred Dev Fund Lockbox as of the activation height of this ZIP will be usable immediately on activation.

Specification

This ZIP proposes the creation of a new Zcash Development Fund. The balance of this Fund consists of the contents of the ZIP 1015 Deferred Development Fund Lockbox as of the activation height of this ZIP, plus any funds that later accrue to the lockbox.

One-time lockbox disbursement

The coinbase transaction of the activation block of this ZIP MUST include one or more lockbox disbursement output(s) to a 2-of-3 P2SH multisig with keys held by the following “Key-Holder Organizations”: Zcash Foundation, the Electric Coin Company, and Shielded Labs.

Let \(\mathsf{ZIP271ActivationHeight}\) be the activation height of NU6.1 on the relevant network (Mainnet or Testnet) as defined in ⁴.

Let \(\mathsf{ZIP271DisbursementAmount}\) be the zatoshi amount in the Deferred Dev Fund Lockbox as of the end of the block preceding the activation height. (\(\mathsf{ZIP271DisbursementAmount}\) can be predicted in advance given that height.)

Let \(\mathsf{ZIP271DisbursementChunks} = 10\).

Let \(\mathsf{ZIP271DisbursementAddress}\) be \(“\texttt{t3ev37Q2uL1sfTsiJQJiWJoFzQpDhmnUwYo}”\) on Mainnet and \(“\texttt{t2RnBRiqrN1nW4ecZs1Fj3WWjNdnSs4kiX8}”\) on Testnet.

The additional coinbase outputs MUST pay a sum of \(\mathsf{ZIP271DisbursementAmount}\) zatoshi, split into \(\mathsf{ZIP271DisbursementChunks}\) equal outputs, to the address represented by \(\mathsf{ZIP271DisbursementAddress}\), each using a standard P2MS script as specified in ZIP 48 ⁵. \(\mathsf{ZIP271DisbursementAmount}\) zatoshi are added to the transparent transaction value pool of the coinbase transaction to fund the output(s), and deducted from the balance of the Deferred Dev Fund Lockbox. The latter deduction occurs before any other change to the Deferred Dev Fund Lockbox balance in the transaction, and MUST NOT cause the Deferred Dev Fund Lockbox balance to become negative at that point.

Note: The value \(\mathsf{ZIP271DisbursementAmount}\) needs to be precalculated so that it is known at the point when the relevant consensus check is done in node implementations.

\(\mathsf{ZIP271DisbursementAmount}\) MUST be \(78750\_0000\_0000\) zatoshi on both Testnet and Mainnet (i.e. 78,750 TAZ on Testnet, 78,750 ZEC on Mainnet).

Non-normative note: The BIP 388 wallet policy ⁶ for the Mainnet \(\mathsf{ZIP271DisbursementAddress}\) is

Wallet descriptor template: sh(sortedmulti(2,@0/**,@1/**,@2/**))
Key information vector:
[2efd03f5/48'/133'/0'/133000']xpub6ERFr6gbA9jHXGj9Qxebua1Fj78ADQJPMyFgP78rUz9kdr4kMMXjkbGQSk6GPD8aYsyPPDXUqftNbuW3jKcHPP1hBa1paPv9FNMLqCqWsNz
[281d1aeb/48'/133'/0'/133000']xpub6FNah9qMu1jMRQdsFXXYWfWXXMhsdP3KRAexTBnnMykskq7VWQGm4439zUwAxNPGVfi7nuL5UWhLwGrHmfnxvLFEx3coS2tjYrezDavvh3T
[e1c4c104/48'/133'/0'/133000']xpub6E2qmBdHpQu9yJ3HvYJ8p8FVYMEWG4a6St2Knd7vfQC9jm7gyWZdvxMo6FafcKvjxiSmd61NW2Mu7udKDbcA5DAVzVdNU6JPrY2uhtPXxE4

Rationale for using P2MS outputs

Changes to the Zcash Protocol Specification

§ 4.17 ‘Chain Value Pool Balances’ ⁷

Change:

Define \(\mathsf{totalDeferredOutput}\) as in § 7.8 ‘Calculation of Block Subsidy, Funding Streams, and Founders’ Reward’.

Then, consistent with [ZIP-207], 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.

to

Define \(\mathsf{totalDeferredOutput}\) and \(\mathsf{totalDeferredInput}\) as in § 7.8.

Then, consistent with [ZIP-207], 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}) - \mathsf{totalDeferredInput}(\mathsf{h})\]

Consensus rule: If the deferred development fund chain value pool balance would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.

Non-normative notes:

• \(\mathsf{totalDeferredOutput}(\mathsf{h})\) is necessarily zero for heights \(\mathsf{h}\) prior to NU6 activation.
• \(\mathsf{totalDeferredInput}(\mathsf{h})\) is necessarily zero for heights \(\mathsf{h}\) prior to NU6.1 activation.

§ 7.1.2 ‘Transaction Consensus Rules’ ⁸

Change:

• A transaction MUST NOT spend a transparent output of a coinbase transaction from a block less than 100 blocks prior to the spend. Note that transparent outputs of coinbase transactions include Founders’ Reward outputs and transparent funding stream outputs.

to

• A transaction MUST NOT spend a transparent output of a coinbase transaction from a block less than 100 blocks prior to the spend. Note that transparent outputs of coinbase transactions include Founders’ Reward outputs, transparent funding stream outputs [ZIP-207], and lockbox disbursement outputs [ZIP-271].

§ 7.8 ‘Calculation of Block Subsidy, Funding Streams, and Founders’ Reward’ ⁹

Change the section title to include “Lockbox Disbursement”.

Add the following definitions:

Let \(\mathsf{ZIP217ActivationHeight}\) and \(\mathsf{ZIP271DisbursementAmount}\) be as defined in [ZIP-271].

and

\(\mathsf{totalDeferredInput}(\mathsf{height}) := \begin{cases} \mathsf{ZIP271DisbursementAmount},&\!\!\text{if } \mathsf{height} = \mathsf{ZIP217ActivationHeight} \\ 0,&\!\!\text{otherwise}. \end{cases}\)

§ 7.10 ‘Payment of Funding Streams’ ¹⁰

Change the section title to ‘Payment of Funding Streams, Deferred Lockbox, and Lockbox Disbursement’.

Add a new paragraph at the start of the section:

[ZIP-207] defines a consensus mechanism to require coinbase transactions to include funding stream outputs, intended to provide funds from issuance for Zcash development. [ZIP-2001] extended this mechanism to support directing funds from issuance into a reserve, the deferred development fund lockbox. [ZIP-271] defines a one-time disbursal of funds from this lockbox in order to support the Community And Coinholder Funding Model [ZIP-1016].

Add the following definition:

Let \(\mathsf{ZIP271ActivationHeight}\), \(\mathsf{ZIP271DisbursementAmount}\), \(\mathsf{ZIP271DisbursementChunks}\), and \(\mathsf{ZIP271DisbursementAddress}\) be as defined for the relevant network (Mainnet or Testnet) in [ZIP-271].

Change:

Consensus rule: [Canopy onward] 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{DeferredPool}\) 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.

• The prescribed way to […]

to

Consensus rule: [Canopy onward] In each block with coinbase transaction \(\mathsf{cb}\) at block height \(\mathsf{height}\), \(\mathsf{cb}\) MUST contain at least the given number of distinct outputs for each of the following:

• for each funding stream \(\mathsf{fs}\) active at that block height with a recipient identifier other than \(\mathsf{DeferredPool}\) given by \(\mathsf{fs.Recipient}(\mathsf{height})\), one output that pays \(\mathsf{fs.Value}(\mathsf{height})\) zatoshi in the prescribed way to the address represented by that recipient identifier.
• [NU6.1 onward] if the block height is \(\mathsf{ZIP271ActivationHeight}\), \(\mathsf{ZIP271DisbursementChunks}\) equal outputs paying a total of \(\mathsf{ZIP271DisbursementAmount}\) zatoshi in the prescribed way to the Key-Holder Organizations’ P2SH multisig address represented by \(\mathsf{ZIP271DisbursementAddress}\), as specified by [ZIP-271].

The term “prescribed way” is defined as follows:

• The prescribed way to […]

Change the reference to the definition of standard redeem script hashes for P2SH multisig addresses from the “Pay To Script Hash (P2SH) — Multisig” section of the Bitcoin Developer Documentation ¹¹, to ZIP 48 ⁵. (This is a clarification, and is not intended to change the redeem scripts for existing P2SH addresses defined by consensus before NU6.1.)

Change the second bullet point defining the prescribed way to pay a Sapling payment address so that it also applies to Orchard, i.e.:

• The prescribed way to pay a Sapling or Orchard payment address is defined in [ZIP-213], using the post-Heartwood consensus rules specified for Sapling and Orchard outputs of coinbase transactions in § 7.1.2 ‘Transaction Consensus Rules’ ⁸.

Clarify the notes as follows:

• The funding stream addresses are not treated specially in any other way, and there can be other outputs to them, in coinbase transactions or otherwise. In particular, it is valid for a coinbase transaction to have other outputs, possibly to the same address, that do not meet the criterion in the above consensus rule, as long as there is at least the given number of distinct outputs that meet it, disjointly for each funding item.
• For clarification, if there are multiple active funding streams or lockbox disbursements with the same recipient identifier and/or value, there MUST be at least the given number of distinct outputs for each of them.
• Up to and including NU6.1 there have been no funding streams or lockbox disbursements defined with a shielded payment address as a recipient. That might change in future, so implementations are encouraged to support Sapling and Orchard outputs as recipients, as permitted by [ZIP-213] and [ZIP-207].

§ 7.10.1 ‘ZIP 214 Funding Streams’ ¹²

Add the Mainnet and Testnet funding streams from Revision 2 of ZIP 214 ¹³ to this section.

Extension to the lockbox funding stream

The FS_DEFERRED lockbox funding stream is set to receive 12% of the block subsidy and is extended by 1,260,000 blocks on both Mainnet and Testnet. This ZIP activates before or on the first block after the end of current dev fund as of this writing and specified in ³, and will extend FS_DEFERRED on Mainnet until block height 4406400.

Rationale for lockbox extension

Privacy and Security Implications

As development funding is a public good on the Zcash network, there are not relevant privacy concerns related to this proposal; all disbursement (but not necessarily subsequent distribution) of development funds is intentionally transparent and auditable by any participant in the network.

Security implications of the One-Time Lockbox Disbursement

After the activation block of this ZIP has been mined, all development funds previously accrued to the in-protocol lockbox will be held instead by a 2-of-3 multisig address. The key-holders for this address will have the capability to spend these funds. Compromise or loss of 2 of these 3 keys would result in total loss of funds; as such, in the event of the compromise or loss of a single key, the Key-Holders MUST establish a new multisig key set and address, and transfer remaining unspent funds held by the original address before additional loss or compromise occurs.

Because this is a one-time disbursement, additional key rotation infrastructure is not required.

Security implications for extension of the lockbox funding stream

Funds will continue to securely accrue to the Deferred Development Lockbox until a disbursement mechanism for the lockbox is implemented in a future network upgrade. Such a disbursement mechanism should be designed to include an in-protocol option for key rotation, such that it is not necessary to perform a network upgrade to recover from key loss or compromise, or to change the size of the signing set or the number of signatures required to reach threshold.

Previously considered alternatives

The following two variables were defined for use in this ZIP:

• \(\mathsf{stream\_value}\): the percentage of the block subsidy to send to a new funding stream, as described in the options below.
• \(\mathsf{stream\_end\_height}\): The ending block height of that stream.

Option 1: Extend the lockbox funding stream

This was the selected option; the section Extensions to the lockbox funding stream was previously referred to as “Option 1” of this ZIP. ZIP 1016 ² set the \(\mathsf{stream\_value}\) parameter to 12%, and the \(\mathsf{stream\_end\_height}\) parameter to Mainnet block height 4406400, equal to that of the Zcash Community Grants stream so that both streams end at Zcash’s 3rd halving.

Option 2: Revert to hard-coded output address

A new funding stream consisting of \(\mathsf{stream\_value}\%\) of the block subsidy is defined to begin when the existing ZIP 1015 funding streams ³ end. The new streams will distribute funds to a 3-of-5 P2SH multisig with keys held by the same Key-Holder Organizations as above. The resulting Fund is considered to include both this stream of funds, and funds from the one-time lockbox disbursement described above.

Option 2 can be realized by either of the following mechanisms:

Mechanism 2a: Classic funding stream

A new funding stream is defined that pays directly to the above-mentioned 3-of-5 multisig address on a block-by-block basis. It is defined to start at the end height of the existing FS_DEFERRED funding stream and end at \(\mathsf{stream\_end\_height}\) and consists of \(\mathsf{stream\_value}\%\) of the block subsidy.

Mechanism 2b: Periodic lockbox disbursement

Constant parameter \(N = 35000\) blocks \(= \mathsf{PostBlossomHalvingInterval}/48\) (i.e. approximately one month of blocks).

The FS_DEFERRED lockbox funding stream is extended to end at height \(\mathsf{stream\_end\_height}\) and has its per-block output value set to \(\mathsf{stream\_value}\%\). A consensus rule is added to disburse from the Deferred Dev Fund Lockbox to a 2-of-3 P2SH multisig with keys held by the same Key-Holder Organizations as above, starting at block height \(\mathsf{activation\_height} + N\) and continuing at periodic intervals of \(N\) blocks until \(\mathsf{stream\_end\_height}\). Each disbursement empties the lockbox.

This is equivalent to specifying \(\frac{\mathstrut\mathsf{stream\_end\_height} \,-\, \mathsf{activation\_height}}{N}\) One-time lockbox disbursements, that all output to the same address.

Rationale for periodic disbursement

Security implications for Mechanism 2a

As of the activation height of this ZIP, development funds will begin accruing as additional outputs spendable by a 2-of-3 multisig address on a block-by-block basis. Key-Holders will need to perform regular multiparty signing ceremonies in order to shield the resulting coinbase outputs. Each such signing ceremony involves shared spending authority being used to sign thousands of inputs to large shielding transactions; for practical reasons, this is often handled using a scripted process that has spending authority over these funds. This process is an attractive target for compromise; for this reason it is RECOMMENDED that address rotation (in this case, by means of hard-coding a sequence of addresses, each of which receives a time-bounded subset of the block reward fractional outputs) be implemented, as was done for the ECC funding stream described in ZIP 1014 ¹⁷.

In the case of key compromise or loss, it may be necessary to perform an emergency Network Upgrade to perform a manual key rotation to ensure that future development funds are not lost.

Security implications for Mechanism 2b

Due to the aggregation of funds recommended by Option 2b, it is no longer necessary to use scripts with spending privileges to perform shielding and/or distribution operations; instead, these operations can be performed by human operators using an interactive protocol that does not require sharing spending key material.

As with Option 2a, key compromise or loss would require an emergency Network Upgrade to perform manual key rotation to mitigate the potential for loss of funds.

Deployment

This proposal will be deployed with the NU6.1 network upgrade. ⁴

Reference implementation

• zcashd PR 7032: Network Upgrade 6.1
• zcashd PR 7059: Release zcashd v6.10.0
• librustzcash PR 1979: Crate releases for NU6.1 mainnet upgrade
• zebrad PR 9603: add(consensus): Implement one-time lockbox disbursement mechanism for NU6.1

References