ZIP: XXX
Title: Deferred Dev Fund Lockbox Disbursement
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
        Kris Nuttycombe <kris@nutty.land>
        Jack Grigg <jack@electriccoin.co>
Status: Draft
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>

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 ² and Zcash Governance Bloc ³ proposals; the mechanisms it describes are applicable to both of these and may be applicable to other similar proposals as well.

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 for that address are then responsible for distributing the resulting funds in the form of development grants, according to the rules set by either ² or ³, or another similar proposal.
• 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 during the period of the extension, which may vary depending upon the proposal that uses this mechanism.

Requirements

• Funds are held in a multisig 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 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 either the lockbox or to one or more transparent multisig addresses as specified by this ZIP.

One-time lockbox disbursement

The coinbase transaction of the activation block of this ZIP MUST include a lockbox disbursement output 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 \(v\) be the zatoshi amount in the Deferred Dev Fund Lockbox as of the end of the block preceding the activation height. (\(v\) can be predicted in advance given that height.)

The additional coinbase output MUST contain at least one output that pays \(v\) zatoshi to the above P2SH multisig address, using a standard P2SH script as specified in ⁵. \(v\) zatoshi are added to the transparent transaction value pool of the coinbase transaction to fund this output, 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.

Exactly one of the following options will also be taken. The proposal that activates this ZIP must define values for the following two parameters:

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

Note: The value \(v\) might need to be precalculated so that it is known at the point when the relevant consensus check is done in node implementations. If so, the specification should be written in terms of the precalculated value.

Rationale for using a P2SH output

Change to the Zcash Protocol Specification

In section 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 {{ reference to this ZIP section }}.

Option 1: Extend the lockbox funding stream

The FS_DEFERRED lockbox funding stream is set to receive \(\mathsf{stream\_value}\%\) of the block subsidy and is extended until block height \(\mathsf{stream\_end\_height}\). Both of these parameters must be specified by the proposal under which this ZIP is activated.

Rationale for Option 1

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

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 of (but not necessarily subsequent distribution) of development funds is 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 Option 1

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.

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.

References