# Notes on deferred dev fund proposals

## Background

``@skyl`` posted a proposal on the forum [here](https://forum.zcashcommunity.com/t/nu6-dev-fund-proposal-from-temporarily-unissued-reserve-lockbox-to-grants-only-funding-bloc/47772) that Kris, Str4d and Daira-Emma think has some very good ideas, both from an efficiency and security point of view, and from the point of view of potentially defusing some of the current political disagreement. It can either be an alternative to other dev fund proposals or combined with them (see [Alternative: combination approaches](#Alternative-combination-approaches)) below.

We later did another round of brainstorming on potential attacks, which is also included below.

The basic idea is to define a "dev reserve" (or multiple such reserves) to keep track of the amounts allocated for the purpose of dev funding, rather than literally sending them to multisig addresses. (``@skyl`` refers to this as a "temporarily unissued reserve lockbox", but in fact these funds should be considered issued, unlike the ZSF; they are just not spent yet).

An advantage of this for encouraging convergence on a dev fund proposal is that it allows more time to decide on where dev funds go, while still keeping track of how much ZEC has been allocated for that purpose.

## Arguments to not literally send the deferred funds to a multisig

### Efficiency

It's a lot of TXOs.
- Since Blossom there are 1,152 blocks per day, and 420,000 blocks per "chain year" (where a halving interval is 4 chain years).
- One year of outputs would require a minimum of around 55 2 MiB transactions to combine (calculated as $\mathsf{ceiling}(420000 / \mathsf{floor}(2000000/250))$ plus overhead), with an estimated size of 250 bytes per output (assuming 2 of 2 multisig which is likely exceedingly conservative; the multisig will probably need to be larger, at least 5 of 8 or something of the sort.)
- The ZIP 317 fee for each of these transactions would be ~66,665,000- zatoshis (paying for $\mathsf{floor}(2000000/150) = 13333$ outputs per tx given the standard transparent input size of 150 bytes, and a full transaction assuming the transparent inputs consumed all 2000000 bytes of the block; in practice it will be a bit lower). Overall this is about 36.7 ZEC per chain year.
- The large number of TXOs also presents a logistical challenge for the signers; it's inconvenient to have to build many transactions over several blocks to produce what should be a single large output to a grant recipient.

### Control

If the proposal is predicated on an inability to decide how spend control over the dev funds should be handled, then spend control over the deferred fund multisig has the same problem.

### Key compromise or loss

The multisig approach creates honeypot keys that may be compromised. It is not clear that the holders of the multisig keys will necessarily have the same incentive or technical ability to keep these keys secure that the current dev fund recipients have.

If there were a key compromise, it is likely that the funds would be drained very quickly before the holders could respond. It is also not clear that the holders would be allowed to move the funds at short notice in response to an attack, in the absence of final agreement on the destinations of funds (unless the proposal explicitly permitted it, which itself adds further attack surface and still requires coordination between the multisig holders).

Additionally, the keys could be lost through some accident (or intentionally due to political motivations or disagreements on the part of some subset of the holders).

## Arguments to not send the deferred funds to the ZSF

The ZSF contains unissued supply by definition. The deferred funds are issued supply by definition. Mixing these two is a Bad Idea.

## Alternative: dedicated reserve per funding stream recipient

- More technical complexity, needs dynamic tracking of individual funding stream pools.
- Main improvement over current funding streams sent to addresses is that the funds are "auto-merged"; the recipient can directly use the amounts they need instead of needing to merge many small outputs.

## Alternative: dedicated overall reserve

- The funding streams as currently set up work well for mutually distrustful funding stream recipients. Moving to this model would require multiparty collaboration to withdraw.
- Spend authority could be controlled by a multisig address, or by arbitrary cryptography (a system of dev fund reserve keys), or simply disallowed and deferred to a later network upgrade.

## Alternative: multiple dedicated partial reserves

- Same as above, but multiple reserves each controlled by any of the above spend authority options.

## Alternative: combination approaches

- It is possible to have some [ZIP 207](https://zips.z.cash/zip-0207) funding streams continue after the halving, and also direct additional funds to a dev reserve.
- This is not any more complicated to implement, because the ZIP 207 mechanism already exists in zcashd and Zebra.
- In particular, there is an argument that immediately directing all dev funds to the reserve would be disruptive to the operation of grant recipients. The combination approach could avoid this disruption.
- This approach also allows compromise positions in which the existing funding stream slices are reduced but not eliminated, with the remainder being effectively "locked" pending further community consensus.

## Summary of design space

``@skyl``'s original proposal is the bottom-right corner "Dedicated reserve bucket that can later be allocated".

| | Individual outputs | Per-recipient reserve | Single reserve |
|---|---|---|---|
| **Withdraw to specific address** | Current funding streams (sort of, see below) | Dedicated reserve per recipient | (likely too complex) |
| **Authorize spend to any address** | Current funding streams (the specific address receiving the indivudual outputs _is_ the spend authority, that can subsequently move them to any address) | Multiple dedicated partial reserves | Dedicated overall reserve |
| **Defer to future NU** | (not implementable) | Multiple reserve buckets that can later be allocated | Dedicated reserve bucket that can later be allocated |

#### Columns: Where are the funds stored.

- **Individual outputs**: Funds are stored as individual notes in one of the regular payment protocol pools.
- **Per-recipient reserve**: The consensus rules would keep track of the amounts allocated to each recipient (in the same way it keeps track of how much value is in the transparent and shielded pools), but would not require coins or notes to be created at time of allocation. Instead these would be created at time of withdrawal.
- **Single reserve**: Same as above, except there's only one pool tracked by consensus nodes. The amounts allocated to individual recipients would need to be controlled at time of withdrawal.

#### Rows: How are the funds spent.

- **Withdraw to specific address**: Funds allocated to a specific recipient are guaranteed to go through that recipient's address.
- Note that this address does not need to be controlled by a single entity; it could be a multisig address controlled by multiple entities. But from the perspective of the consensus rules, they are a single recipient receiving a specific fraction of the dev funds.
- **Authorize spend to any address**: The spend authority for the funds is decoupled from where they go; it might be controlled by the recipient, or it might be controlled by a different entity.
- This approach enables recipients to rotate their receiving addresses without needing to change the consensus rules. Only the spend authorizing keys would need a rotation mechanism (either on-chain or via consensus rule updates).
- A corollary is that the recipient is not guaranteed to receive the funds allocated to them unless they control the spend authority. If a different entity controls it, they can redirect or withhold funds, regardless of how the funds are represented in consensus.
- **Defer to future NU**: The reserved funds cannot be spent until a means of doing so is specified in a future network upgrade. That means can be any combination of the other options, or some option that we haven't yet anticipated.

### Interaction with the ZSF

While the balance of the ZSF and the balance of the reserve are separate for the reason given in [Arguments to not send the deferred funds to the ZSF](#Arguments-to-not-send-the-deferred-funds-to-the-ZSF) above, the technical mechanisms are similar, and so implementing both is not twice as complicated as implementing only one or the other.

The ZSF deposit field in a transaction could be generalized to also allow deposits to a specific reserve.

### Relation to Sprout deprecation

Sprout funds return to "unissued reserve" -- the ZSF is effectively unissued reserve. That would be politically quite different, and likely more acceptable, than returning the Sprout funds to a dev reserve.

## Potential negative implications and attacks against a deferred dev fund

1. There is an increased incentive for malicious actors to attack the governance process, to ensure that they get a slice of the pie in a future upgrade.
* Previously, since the dev funds were already allocated there was not the same scope to potentially redirect them.
* This is essentially just increasing the incentive to take advantage of any attacks on governance, not creating new attacks.
2. The overall issuance is effectively reduced until the distribution process is encoded in a future network upgrade. This means that after the halving the issuance to circulating ZEC will be decreased by 60% rather than 50%, and then when distribution is encoded that additional 10% of cumulative issuance is likely to move into circulation quickly instead of gradually.
* On the other hand, the recipients have an incentive not to sell too quickly, and it would also be possible to define a slower distribution curve.
* If some party has an existing capability to manipulate the price of ZEC via short sales, they might want to artificially depress the price just prior to the influx of backed-up issuance starting to circulate. The certain knowledge of a future influx of circulating supply could make it possible to short the market with the anticipation of future sell pressure that will allow the short sellers to exit their positions without raising the price. (Potentially related: [[Finnerty2005]](https://www.sec.gov/comments/s7-08-08/s70808-318.pdf))
* This seems like it would be a consistent problem with "unlocks", which happen frequently in the cryptocurrency ecosystem; it would be valuable to check what market behavior has been in response to unlocks in other protocols.
3. The miner reward is reduced by 50% at the halving, instead of 37.5% for the current consensus rules (under which dev funding completely ceases).
* This would however be consistent with it being a "halving", so not a foreign concept to miners or the wider Zcash ecosystem.
5. In addition to ECC and ZF, which have some reserves that can allow for continued operation, ZCG will be affected, and they likely will not be able to continue operation at previous levels. To what degree ZCG will be able to continue operation is uncertain and depends upon the reserves that they will have at the time of the halving.
* It would be possible to use a hybrid approach in which some funds are distributed via the existing funding stream mechanism and some are deferred.
7. Any reduction in the fiat value of miner rewards causes miner revenue to drop relative to expenses, thus reducing the incentive to mine. This could happen e.g. due to a drop in price possibly from point 2, or the direct reduction in ZEC-denominated rewards from point 3 (assuming that the fiat price does not double at the halving). If this results in a reduction of hash rate, then the security against rollback attack from an adversary with a given hash rate is correspondingly reduced.