Below is an extract from the ZIP discussions had on the forum that I believe aligns with the preferred implementation requirements. Assuming “funding streams” are still the preferred method for defining recipients after ZSF deployment the definition below would still apply after ZSF deployment.
Keep in mind these splits are only intended to be examples and would be adjusted to suit the communities desires.
Declining Schedule
This allocation is designed to decrease by approximately 3% every 35064 blocks (~1 month). This reduction is calculated by multiplying the denominator in the split calculations below, starting at 1000, by 1.03^(blocks_since_halving / 35064) and rounding down the result. The Unissued Reserve’s calculation is an estimate and should be calculated as the leftover unallocated rewards. Beginning with the second Zcash halving in 2024, the development fund’s allocation for the ensuing 35064 blocks will be as follows:
- 240/1000 (24%) Unissued Reserve/Zcash Sustainability Fund (denoted UR slice);
- 266/1000 (26.6%) for the Bootstrap Project (denoted BP slice);
- 190/1000 (19%) for the Zcash Foundation, for general use (denoted ZF slice);
- 304/1000 (30.4%) for additional “Major Grants” for large-scale long-term projects
(denoted ZCG slice).
After 35064blocks (~1month) the Dev Fund SHALL continue for another 35064blocks and be allocated as follows:
- 260/1030 (~26.21%) Unissued Reserve/Zcash Sustainability Fund (denoted UR slice);
- 266/1030 (~25.83%) for the Bootstrap Project (denoted BP slice);
- 190/1030 (~18.45%) for the Zcash Foundation, for general use (denoted ZF slice);
- 304/1030 (~29.51%) for additional “Major Grants” for large-scale long-term projects
(denoted ZCG slice).
This calculation will continue until the dev fund allocation effectively reaches 0 or the dev fund is change which should be voted on every network upgrade. Implementations of this development fund SHALL use the numerators and denominators above to calculate the slice.