Dev Fund Proposal : Continued from block rewards with a halving schedule

Community Collaborations protocol
1

Reposting here (if I’ve messed up please edit/delete)

I propose :-

  • Funding continues from block rewards at (XXX per block)
  • Funding follow a halving schedule (every XXX blocks)
  • Funding stops when it reaches block (XXX)

(Note: The amount per block and block numbers are blank, this is simply a proposal for the mechanism)

Benefits :-

  • The dev funding issue will not have to be revisited every few years
  • Provides more support for short/near term activities
  • Provides incentives to work on adoption & marketing (market price)
  • Provides time for ECC to develop additional longer-term revenue streams
  • Establishes an end-date for dev funding
  • The community is familiar with ‘things that halve’

Summary :-

The main benefit is ‘certainty’, re-visiting the DevFund issue every few years is divisive and damaging.

5 Likes
2

Couple of initial thoughts, who is receiving the funding? We already have a halving schedule built in - are you suggesting something more granular than the 4 year halving periods?

2 Likes
3

I’m suggesting a schedule specific for dev funding, its a separate issue so amounts & timing would have to be different.

Also, no attempt here to specify recipients, thats a separate thing & I have faith that resources would be channeled as appropriate.

2 Likes
4

Thanks for the proposal!

Clarifying Questions:

  • This is just for Dev Funds outside of mining rewards, right? (Mining rewards already follow a halving schedule like this.)
  • What is the source of these funds? Some options I can brain storm:
    • keep the overall ZEC issuance schedule (21M cap, same timeline), and source these funds from new block rewards, reducing the amount miners would receive compared to the current rules.
    • increase the total number of ZEC above the 21M cap, and add new issuance. (Note: this is effectively transferring wealth from all ZEC holders into the Dev Fund.)
    • reduce existing balances and redirect those funds to a Dev Fund. (Note: I believe this is economically and ethically identical to the previous alternative. There are accounting differences I consider miner. The technical implementation may be more complicated.)
  • How can there be both a halving schedule and an end block?
  • Does this proposal explicitly transfer this new Dev Fund source to ECC? What about the Foundation, or other organizations or individual contributors?
  • Does this proposal require/request ECC to develop additional revenue streams?
  • What happens is a substantial share of users are dissatisfied with how the Dev Fund is being deployed, but it’s still a long time until the end of the
3 Likes
5

Yes, the idea is to completely separate Dev Funding from everything else.

(EDIT: ‘Halving’ is proposed to avoid future situations where funding stops abruptly)

Funds come from new block rewards (as per the existing Founders Reward), the 21m cap should not be changed. The amount per block is not specified.

The idea is for a mechanism that allows dev funding to both reduce over time and eventually come to an end, for example (ignore the numbers!) ‘halve every two years until its less than 0.25 ZEC per block’.

The end block could be the block issuing the last reward which would provide continuous funding that reduces over time, or an earlier block so it can expire.

EDIT: This method could be used to define funding for ECC and also for Zfnd, ie: two definitions, different amounts, halving schedule & expiry date.

No, this is simply an attempt to define ‘where the money comes from’.

I think ‘where the money goes’ is a different question, its also subject to whatever the needs are at the time and things change.

I was surprised to read they haven’t already, that’s what private companies usually do, however its only a suggestion.

My opinion :-

The ECC/Zcash relationship is evolving towards a ‘private company providing services to a government’ - in this case the ‘government’ being the community (however that’s defined).

Private companies are not usually supported exclusively by taxes, so I think its appropriate for dev funding to supplement revenue rather than define it.

Resolving this should be via whatever governance/polling/voting mechanism exists at the time.

4 Likes
6

The idea of progressive halving is interesting.

7

Could you follow my request on Proposal authors, please read: Help making ZIPs ?

That will help me and ZIP editors know which forum proposals we can help turn into ZIPs.

Thanks again for your contribution!

1 Like
8

I think my proposal works best as a component of others, its an outline of an idea rather than something that could become a standalone proposal.

I’ve discussed it with a couple of authors already & will team up with any who want to incorporate it.

2 Likes
9

Bumping this thread. Is this mechanism feasible? it seems okay on my flow chart (which I will publish shortly after I finished these bloody subtitles.)

@mhluongo @Blocktown @acityinohio what do you think about this? and your proposals? or do you think this question should be re visited every 4 years?

(That isn’t a rhetorical question.)

1 Like
10

Note: If the Dev Fund halving parameters (of this proposal) are set to be the same as the block reward halving, then what we get is simply:
“The Dev Fund is a fixed percentage of the block reward in perpetuity”.
Just like in my Dev Fund to ECC + Zfnd + Major Grants proposal.

2 Likes
11

As painful as this process is, I would (personally) prefer to raise it again in a couple of years (if a dev fund is necessary then) rather than guarantee funding for a single group or process. That said, if others disagree they should definitely integrate that into their proposals, and as @tromer said a fixed % of block reward in perpetuity is probably the most elegant way to accomplish this.

3 Likes