# ZIP 271: Dev Fund Extension and One-Time Disbursement

Status: Proposed

Owners: Daira-Emma Hopwood, Kris Nuttycombe, Jack Grigg

Snapshot: a34cfc091434275120ff017c92c3b50d3cef623a

Source date: 2026-10-16T02:56:04+01:00

[Source revision](https://github.com/zcash/zips/commit/a34cfc091434275120ff017c92c3b50d3cef623a)

[Official source](https://zips.z.cash/zip-0271) · [Source file](https://github.com/zcash/zips/blob/a34cfc091434275120ff017c92c3b50d3cef623a/zips/zip-0271.md)

Preamble

**ZIP**: 271

**Title**: Dev Fund Extension and One-Time Disbursement

**Owners**: 

- [Daira-Emma Hopwood](mailto:daira@jacaranda.org)
- [Kris Nuttycombe](mailto:kris@nutty.land)
- [Jack Grigg](mailto:thestr4d@gmail.com)

**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/989)
- [https://github.com/zcash/zips/pull/1014](https://github.com/zcash/zips/pull/1014)
- [https://github.com/zcash/zips/pull/1015](https://github.com/zcash/zips/pull/1015)
- [https://github.com/zcash/zips/pull/1099](https://github.com/zcash/zips/pull/1099)

<a id="terminology"></a>

## Terminology

The key words "MUST", "MUST NOT", and "RECOMMENDED" in this document are
to be interpreted as described in BCP 14 <a id="user-content-fnref-bcp14"></a>
[1](#user-content-fn-bcp14) when, and only when, they
appear in all capitals.

<a id="abstract"></a>

## 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 <a id="user-content-fnref-zip-1016"></a>
[2](#user-content-fn-zip-1016) 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 <a id="user-content-fnref-zip-1016-2"></a>
  [2](#user-content-fn-zip-1016).

- 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 id="user-content-fnref-zip-1015-funding-streams"></a>
  [3](#user-content-fn-zip-1015-funding-streams).

- A variety of different mechanisms that may be used for distributing funds
  that accrue in the lockbox during the period of the extension.

<a id="requirements"></a>

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

<a id="specification"></a>

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

<a id="one-time-lockbox-disbursement"></a>

### 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 <a id="user-content-fnref-zip-0255"></a>
[4](#user-content-fn-zip-0255).

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 <a id="user-content-fnref-zip-0048"></a>
[5](#user-content-fn-zip-0048). $\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 <a id="user-content-fnref-bip-0388"></a>
[6](#user-content-fn-bip-0388) 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

Rationale

The keyholders may desire the grant-filling transactions use transparent inputs or
shielded inputs. Regardless of their desire, the one-time disbursement must at some
point go through a shielded pool, because this ZIP does not propose altering the
consensus rules for spendability of transparent coinbase outputs. That would be far
too complex a change for the intended scope.

This means that by using P2MS (i.e. P2SH multisig) outputs in consensus, the
Key-Holder Organizations will need to spend each chunk of the one-time disbursement
completely into a shielded output. This spend would presumably be to a FROST address
in order to maintain consistent security position over the lockbox funds; perhaps
publishing the viewing key to maintain visibility.

An alternative proposal could require the one-time disbursement to directly create
a shielded output to the FROST address. This would mean that the Key-Holder
Organizations could immediately start disbursing grants (although the 100-block
coinbase maturity is not particularly onerous).

This ZIP instead uses P2MS outputs for two reasons:

- Using a shielded output would place a requirement on the miner (or mining pool)
  to be able to create shielded coinbase outputs. Technically that requirement
  is already in the consensus rules, but it has never before been exercised,
  since no Funding Stream has been defined with a shielded address.

- Using a shielded output in the context of this ZIP would mean that the FROST
  address needs to be derived well in advance of NU activation. At the time of
  writing (May 2025), ZIP 312 does not specify key generation, and it would be
  undesirable to couple the specification process for that to this ZIP. P2SH
  multisig addresses by comparison have a relatively stable and well understood
  format and generation process.

The one-time disbursement is split into 10 P2MS outputs in order to give the
Key-Holder Organisations more flexibility to shield only part of the disbursement
at a time.

#### Changes to the Zcash Protocol Specification

##### § 4.17 ‘Chain Value Pool Balances’ <a id="user-content-fnref-protocol-chainvaluepoolbalances"></a>
[7](#user-content-fn-protocol-chainvaluepoolbalances)

Change:

> Define $\mathsf{totalDeferredOutput}$ as in
> § 7.8 ‘Calculation of Block Subsidy, Funding Streams, and Founders’ Reward’.
> 
> 
> 
> 
> Then, consistent with [[ZIP-207]](/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]](/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’ <a id="user-content-fnref-protocol-txnconsensus"></a>
[8](#user-content-fn-protocol-txnconsensus)

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]](/zip/207), and lockbox
>   disbursement outputs [ZIP-271].

##### § 7.8 ‘Calculation of Block Subsidy, Funding Streams, and Founders’ Reward’ <a id="user-content-fnref-protocol-subsidies"></a>
[9](#user-content-fn-protocol-subsidies)

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},&\!\!\textsf{if } \mathsf{height} = \mathsf{ZIP217ActivationHeight} \\
>    0,&\!\!\textsf{otherwise.}
>  \end{cases}$

##### § 7.10 ‘Payment of Funding Streams’ <a id="user-content-fnref-protocol-fundingstreams"></a>
[10](#user-content-fn-protocol-fundingstreams)

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]](/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]](/zip/2001) extended this mechanism to support directing funds
> from issuance into a reserve, the deferred development fund lockbox. [[ZIP-271]](/zip/271)
> defines a one-time disbursal of funds from this lockbox in order to support the
> Community And Coinholder Funding Model [[ZIP-1016]](/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]](/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]](/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 <a id="user-content-fnref-bitcoin-multisig"></a>
[11](#user-content-fn-bitcoin-multisig), to ZIP 48 <a id="user-content-fnref-zip-0048-2"></a>
[5](#user-content-fn-zip-0048). (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]](/zip/213), using the post-Heartwood consensus rules specified for
>   Sapling and Orchard outputs of coinbase transactions in
>   § 7.1.2 ‘Transaction Consensus Rules’ <a id="user-content-fnref-protocol-txnconsensus-2"></a>
>   [8](#user-content-fn-protocol-txnconsensus).

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]](/zip/213)
>   and [[ZIP-207]](/zip/207).

##### § 7.10.1 ‘ZIP 214 Funding Streams’ <a id="user-content-fnref-protocol-zip214fundingstreams"></a>
[12](#user-content-fn-protocol-zip214fundingstreams)

Add the Mainnet and Testnet funding streams from Revision 2 of ZIP 214
<a id="user-content-fnref-zip-0214-funding-streams"></a>
[13](#user-content-fn-zip-0214-funding-streams) to this section.

<a id="extension-to-the-lockbox-funding-stream"></a>

### Extension to the lockbox funding stream

The continuation of the 12% lockbox funding stream is `FS_CCF_H3`, as
defined in ZIP 214 Revision 2 <a id="user-content-fnref-zip-0214-funding-streams-2"></a>
[13](#user-content-fn-zip-0214-funding-streams). Under the
pre-NU7 block spacing, it spans Mainnet heights 3146400 through 4406399
(1,260,000 blocks) and Testnet heights 3536500 through 4475999
(939,500 blocks). If NU7 activates before the respective end height,
ZIP 214 Revision 3 extends the stream to the revised third-halving
height on that network, calculated using ZIP 218 <a id="user-content-fnref-zip-0218"></a>
[14](#user-content-fn-zip-0218).

#### Rationale for lockbox extension

Rationale

Performing a one-time disbursement to a P2SH multisig address will provide a
source of grant funding for a limited period, allowing time for a lockbox
disbursement mechanism to be specified and deployed, as originally intended by
ZIP 1015 <a id="user-content-fnref-zip-1015"></a>
[15](#user-content-fn-zip-1015).

In particular, this provides an opportunity for transaction format changes that
may be required for such a mechanism to be included in the v6 transaction
format <a id="user-content-fnref-zip-0230"></a>
[16](#user-content-fn-zip-0230). It is desirable to limit the frequency of transaction
format changes because such changes are disruptive to the ecosystem. It is not
necessary that protocol rules for disbursement actually be implemented until
after the transaction format changes are live on the network. It is RECOMMENDED
that any such transaction format changes be included in the upcoming v6
transaction format in order to avoid such disruption.

By implementing a one-time disbursement along with a continuation of the
`FS_DEFERRED` stream, we prioritize both the availability of grant funding
and the implementation of a more flexible and secure mechanism for disbursement
from the lockbox — making it possible to address the need to rotate keys and/or
alter the set of key holders in a way that reverting to hard-coded output
addresses for repeated disbursements would not.

<a id="privacy-and-security-implications"></a>

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

<a id="security-implications-of-the-one-time-lockbox-disbursement"></a>

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

<a id="security-implications-for-extension-of-the-lockbox-funding-stream"></a>

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

<a id="previously-considered-alternatives"></a>

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

<a id="option-1-extend-the-lockbox-funding-stream"></a>

### Option 1: Extend the lockbox funding stream

This was the selected option; the section [Extensions to the lockbox funding stream](#extensiontothelockboxfundingstream)
was previously referred to as "Option 1" of this ZIP. ZIP 1016 <a id="user-content-fnref-zip-1016-3"></a>
[2](#user-content-fn-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 under the pre-NU7 block spacing. ZIP 214 Revision 3
<a id="user-content-fnref-zip-0214"></a>
[17](#user-content-fn-zip-0214) adjusts the end height to the revised third halving if NU7
activates before the original end height.

<a id="option-2-revert-to-hard-coded-output-address"></a>

### 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
<a id="user-content-fnref-zip-1015-funding-streams-2"></a>
[3](#user-content-fn-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 disbursement]s,
that all output to the same address.

##### Rationale for periodic disbursement

Rationale

Classic funding streams <a id="user-content-fnref-zip-0207"></a>
[18](#user-content-fn-zip-0207) produce many small output values, due to
only being able to direct funds from a single block's subsidy at a time. This
creates operational burdens to utilizing the funds — in particular due to block
and transaction sizes limiting how many outputs can be combined at once, which
increases the number of required transactions and correspondingly the overall
fee.

The periodic lockbox disbursement mechanism can produce the same effective
funding stream, but with aggregation performed for free: the output to the
funding stream recipient is aggregated into larger outputs every $N$ blocks. In
the specific case of Mechanism 2b, the recipient multisig address would receive
around 40 outputs, instead of around 1,300,000.

<a id="security-implications-for-mechanism-2a"></a>

### 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 <a id="user-content-fnref-zip-1014"></a>
[19](#user-content-fn-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.

<a id="security-implications-for-mechanism-2b"></a>

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

<a id="deployment"></a>

## Deployment

This proposal will be deployed with the NU6.1 network upgrade. <a id="user-content-fnref-zip-0255-2"></a>
[4](#user-content-fn-zip-0255)

<a id="reference-implementation"></a>

## Reference implementation

- [zcashd PR 7032: Network Upgrade 6.1](https://github.com/zcash/zcash/pull/7032)

- [zcashd PR 7059: Release zcashd v6.10.0](https://github.com/zcash/zcash/pull/7059)

- [librustzcash PR 1979: Crate releases for NU6.1 mainnet upgrade](https://github.com/zcash/librustzcash/pull/1979)

- [zebrad PR 9603: add(consensus): Implement one-time lockbox disbursement mechanism for NU6.1](https://github.com/ZcashFoundation/zebra/pull/9603)

<a id="references"></a>

## References

<a id="footnote-label"></a>

### Footnotes

1. [Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"](https://www.rfc-editor.org/info/bcp14) [↩](#user-content-fnref-bcp14)

2. [ZIP 1016: Community and Coinholder Funding Model](/zip/1016) [↩](#user-content-fnref-zip-1016) [↩2](#user-content-fnref-zip-1016-2) [↩3](#user-content-fnref-zip-1016-3)

3. [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams](/zip/1015#funding-streams) [↩](#user-content-fnref-zip-1015-funding-streams) [↩2](#user-content-fnref-zip-1015-funding-streams-2)

4. [ZIP 255: Deployment of the NU6.1 Network Upgrade](/zip/255) [↩](#user-content-fnref-zip-0255) [↩2](#user-content-fnref-zip-0255-2)

5. [ZIP 48: Transparent Multisig Wallets](/zip/48) [↩](#user-content-fnref-zip-0048) [↩2](#user-content-fnref-zip-0048-2)

6. [BIP 388: Wallet Policies for Descriptor Wallets](https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki) [↩](#user-content-fnref-bip-0388)

7. [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 4.17: Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) [↩](#user-content-fnref-protocol-chainvaluepoolbalances)

8. [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 7.1.2: Transaction Consensus Rules](protocol/protocol.pdf#txnconsensus) [↩](#user-content-fnref-protocol-txnconsensus) [↩2](#user-content-fnref-protocol-txnconsensus-2)

9. [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 7.8: Calculating Block Subsidy, Funding Streams, Lockbox Disbursement, and Founders’ Reward (section title as modified)](protocol/protocol.pdf#subsidies) [↩](#user-content-fnref-protocol-subsidies)

10. [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 7.10: Payment of Funding Streams, Deferred Lockbox, and Lockbox Disbursements (section title as modified)](protocol/protocol.pdf#fundingstreams) [↩](#user-content-fnref-protocol-fundingstreams)

11. [Bitcoin Developer Documentation — Pay To Script Hash (P2SH) — Multisig](https://developer.bitcoin.org/devguide/transactions.html#multisig) [↩](#user-content-fnref-bitcoin-multisig)

12. [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 7.10.1: ZIP 214 Funding Streams](protocol/protocol.pdf#zip214fundingstreams) [↩](#user-content-fnref-protocol-zip214fundingstreams)

13. [ZIP 214: Consensus rules for a Zcash Development Fund — Funding Streams](/zip/214#funding-streams) [↩](#user-content-fnref-zip-0214-funding-streams) [↩2](#user-content-fnref-zip-0214-funding-streams-2)

14. [ZIP 218: 25-second Block Target Spacing](/zip/218) [↩](#user-content-fnref-zip-0218)

15. [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding](/zip/1015) [↩](#user-content-fnref-zip-1015)

16. [ZIP 230: Version 6 Transaction Format](/zip/230) [↩](#user-content-fnref-zip-0230)

17. [ZIP 214: Consensus rules for a Zcash Development Fund](/zip/214) [↩](#user-content-fnref-zip-0214)

18. [ZIP 207: Funding Streams](/zip/207) [↩](#user-content-fnref-zip-0207)

19. [ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants](/zip/1014) [↩](#user-content-fnref-zip-1014)

## Citation relationships

Cites: [ZIP 48](https://zips.tools/zip/48), [ZIP 207](https://zips.tools/zip/207), [ZIP 213](https://zips.tools/zip/213), [ZIP 214](https://zips.tools/zip/214), [ZIP 218](https://zips.tools/zip/218), [ZIP 230](https://zips.tools/zip/230), [ZIP 255](https://zips.tools/zip/255), [ZIP 312](https://zips.tools/zip/312), [ZIP 1014](https://zips.tools/zip/1014), [ZIP 1015](https://zips.tools/zip/1015), [ZIP 1016](https://zips.tools/zip/1016), [ZIP 2001](https://zips.tools/zip/2001)

Cited by: [ZIP 207](https://zips.tools/zip/207), [ZIP 255](https://zips.tools/zip/255), [ZIP 1016](https://zips.tools/zip/1016)