ZIP: 271 Title: Dev Fund Extension and One-Time Disbursement Owners: Daira-Emma Hopwood Kris Nuttycombe Jack Grigg Status: Proposed Category: Consensus / Process Created: 2025-02-19 License: MIT Pull-Request: # Terminology The key words "MUST", "MUST NOT", and "RECOMMENDED" in this document are to be interpreted as described in BCP 14 [^BCP14] 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 [^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 [^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 [^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. # 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 [^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 [^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 [^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’ [^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-0207), 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-0207), 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’ [^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-0207), and lockbox > disbursement outputs [ZIP-271]. #### § 7.8 ‘Calculation of Block Subsidy, Funding Streams, and Founders’ Reward’ [^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’ [^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-0207) 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 [^Bitcoin-Multisig], to ZIP 48 [^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’ [^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’ [^protocol-zip214fundingstreams] Add the Mainnet and Testnet funding streams from Revision 2 of ZIP 214 [^zip-0214-funding-streams] to this section. ## 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 [^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 [^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 [^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 [^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.
# 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](#extensiontothelockboxfundingstream) was previously referred to as "Option 1" of this ZIP. ZIP 1016 [^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 [^zip-0214] adjusts the end height to the revised third halving if NU7 activates before the original end height. ## 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 [^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 [^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.
## 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 [^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. [^zip-0255] # 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) # References [^BCP14]: [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) [^protocol-chainvaluepoolbalances]: [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 4.17: Chain Value Pool Balances](protocol/protocol.pdf#chainvaluepoolbalances) [^protocol-txnconsensus]: [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 7.1.2: Transaction Consensus Rules](protocol/protocol.pdf#txnconsensus) [^protocol-subsidies]: [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) [^protocol-fundingstreams]: [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) [^protocol-zip214fundingstreams]: [Zcash Protocol Specification, Version 2025.6.0 [NU6.1 proposal]. Section 7.10.1: ZIP 214 Funding Streams](protocol/protocol.pdf#zip214fundingstreams) [^zip-0048]: [ZIP 48: Transparent Multisig Wallets](zip-0048.md) [^zip-0207]: [ZIP 207: Funding Streams](zip-0207.rst) [^zip-0207-consensus-rules]: [ZIP 207: Funding Streams — Consensus Rules](zip-0207#consensus-rules) [^zip-0214]: [ZIP 214: Consensus rules for a Zcash Development Fund](zip-0214.rst) [^zip-0214-funding-streams]: [ZIP 214: Consensus rules for a Zcash Development Fund — Funding Streams](zip-0214#funding-streams) [^zip-0218]: [ZIP 218: 25-second Block Target Spacing](zip-0218.md) [^zip-0230]: [ZIP 230: Version 6 Transaction Format](zip-0230.rst) [^zip-0255]: [ZIP 255: Deployment of the NU6.1 Network Upgrade](zip-0255.md) [^zip-1014]: [ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants](zip-1014.rst) [^zip-1015]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding](zip-1015.rst) [^zip-1015-funding-streams]: [ZIP 1015: Block Subsidy Allocation for Non-Direct Development Funding — Funding Streams](zip-1015#funding-streams) [^zip-1016]: [ZIP 1016: Community and Coinholder Funding Model](zip-1016.md) [^bip-0388]: [BIP 388: Wallet Policies for Descriptor Wallets](https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki) [^Bitcoin-Multisig]: [Bitcoin Developer Documentation — Pay To Script Hash (P2SH) — Multisig](https://developer.bitcoin.org/devguide/transactions.html#multisig)