Dev Fund Proposal: Enhanced Community Funding System

Community Collaborations
1

Dev Fund Proposal: Enhanced Community Funding System

Advocate: boxalex

Disclaimer:
The author of the original proposal is currently not available and can’t push the proposal forward. I have some ideas how to improve this proposal and hence meanwhile making a modified version called: Enhanced Community Funding System. If the original author comes back it’s possible, if he agrees, that both proposals get merged. This proposal is a good alternative and it should be in no case abandoned in my opinion.
Large parts of it are copied from the original proposal, some parts are modified and some parts are added entirely new.

Original proposal: [ZIP 1005] ZIP proposal: ZCFS (Zcash Community Funding System)

Abstract

This proposal specifies an alternative funding system by introducing a new funding mechanism called ECFS (Enhanced Community Funding System).

Motivation

The motivations for ECFS are:

  • The Founders Reward is set to expire in 2020 and a new development fund will be required.
  • The Founders Reward has caused significant friction in the Zcash community and sparked forks due to disagreement with the fund’s structure.
  • There needs to be a more fair and decentralized funding mechanism.
  • No promise should be broken. Founders Reward ends 2020. 90% of tokesn get allocated to miners if opt-in as an additional option is choosen.
  • Development after 2020 should be more competive.
  • With this proposal the ECC can keep it’s for-profit status.

Specification

This specification is a modification of the Monero Community Crowdfunding System (CCS) and is defined as follows and the original proposal as defined in the disclaimer above:

  1. The Zcash protocol will NOT be changed so that 100% of mining rewards go to miners after 2020. This reflects the initial protocol that the founders reward ends in 2020 (only if the opt-in option as an additionally funding option is choosen!)
  2. An individual, team or company (for-profit or non-profit), henceforth ‘proposer’, has an idea to improve the Zcash ecosystem that requires funds.
  3. The proposer creates a ECFS proposal in a modified version of the existing ZF Grants website, to be called the ECFS website. The ZF Grants website already has the basic infrastructure for this mechanism and needs to be tweaked in order to facilitate this specification. The ZF Grants website will continue to operate in its current form, but not limited to it. Further improvements could be made. Later described in detail.
  4. In the beginning, the Zcash Foundation is put in charge of the ECFS.
  5. The Zcash Foundation is required to make ECFS proposals for its own funding. If the community decides not to fund it, then the ownership of the ECFS is transferred to the proposer who is instead funded by the community for that matter.
  6. After a ECFS proposal has been created, the community discusses the pros and cons of the proposal, and offers feedback and critique.
  7. The proposer changes the proposal (if necessary), utilizing the feedback and critique of the community.
  8. Repeat steps 6 and 7 as needed.
  9. After the Zcash Foundation (or whoever has ownership of the ECFS at the time) has determined that the community has reached loose consensus, the funding begins by ZEC holders and miners who wish to donate.
  10. Once fully funded (not guaranteed), the proposer begins on the work, if they haven’t already.
  11. Milestones are completed and funds are disbursed upon their completion.
  12. After all milestones are completed, the proposal is locked and all info is retained for posterity.
  13. Miners should be given the option, voluntary and opt-in only, to donate part of their block rewards to ECFS proposals.
    13a. For easyness an alternative mechanism for miners could be that opt-in, maybe even opt-out with a burning option could be allocated to a general ECFS fund which is than split equally to all ECFS proposals that are active at that time.
  14. There should be an option introduced in native wallets that let ZEC holders donate to given proposals or at least make them aware of such option by setting up links into the wallet.
    14a. For easyness and alternative mechanism in the wallet could be introduced with the option of donating x amount which is allocated to a general ECFS fund which is than split equally to all ECFS proposals that are active at that time.

Rules and Expectations

The ECFS is intentionally left as informal as possible. This allows for flexibility of the system, and keeps things from being red taped into oblivion. However, there are some things you should understand, things that will be expected of you, as either a proposer or a donor, and a recommended way of structuring a proposal for maximum likelihood that your project will be funded.

For Donors

  1. The ECFS is escrowed by the Zcash Foundation (or whoever has ownership of the ECFS at the time). When you make a donation, you are releasing funds to them to disburse when they deem the community agrees that a milestone is complete. They do not do the work to verify donors, and the final decision for all disputes falls with them, although they do their best to follow community sentiment.
  2. In the event that a proposal is overfunded, unable to be completed, or otherwise put in a state where donated money will not be disbursed to the proposer, the default is that the remaining ZEC will be put in the ZF Grants fund and/or split equally to all other active proposals at that time.
  3. Refunds are extraordinarily rare. Donate accordingly.
  4. If the proposer disappears, no problem, someone else can pick up from their last milestone.
  5. Milestone and payout structures vary per proposal based on the proposer’s wishes. It is up to the donor to do their due diligence in whether or not they support the proposal in its entirety.

For Proposers

  1. There is no guarantee that your project will get past the community feedback stage, and if it does, there is no guarantee that it will be funded.
  2. You have to drum up support for your proposal during the feedback and funding stages. Do not expect others (especially the Zcash Foundation or other trusted members of the community) to do it for you. Others may share and support if they are excited about your project, but ultimately it is nobody’s responsibility but your own.
  3. It is expected that you provide updates on the progress of your proposal to the community. For every milestone completed there should be a written report put into your ECFS proposal announcing its completion and the work done, but depending on the timeline of your project, it may be wise to update the community more frequently.
  4. All work must be licensed permissively at all stages of the proposal. There is no time where your work can be licensed under a restrictive license (even as you’re working on it). Your proposal will be terminated if this is not remedied.
  5. You may NOT under any circumstances include a donation address directly in your proposal. This circumvents the ECFS, and can lead to scams.
  6. Your work on the project can begin before the proposal is fully funded but disbursment of funds is done only upon completion of milestones and only if the proposal is fully funded.

Competive Character of this Proposal:

This proposal should increase competition within development of the Zcash protocol. The ECC still can develop Zcash but with this proposal it has to compete with other developers that might propose similar or even better options which should lead to more and better competition.

Decentralized Character of this Proposal:

In my opinion this proposal advocates for more decentralization and a fairer funds distribution.

Transparency Character of this Proposal:

This proposal will lead to full transparency what costs how much and how many funds are used for a given improvement and proposal. The community can decide IF a given proposal is worth the amount and support it or not.

Combining this proposal with an miner opt-in/opt-out block reward option:

I think it’s possible as an alternative, better additional, variant of this proposal to have miner opt-in or even miner opt-out been added. Possible scenarios could be:

  1. The amount from miner’s blockrewards are put equally distributed to all active ECFS proposals
  2. The amount from miners blockrewards are put into a ZF grant fund and the Foundation decides where to allocate these.
    3.) The amount from miners blockrewards are put into a special fund and the New Community Governance Panel decides monthly or quarterly and decides to which proposals to allocate which % of these funds.

Further thoughs about opt-in/opt-out. I personally would prefer the voluntary opt-in option, but i agree that opt-in alone and even the ECFS alone through donating would not be enough to indeed ensure a safe, good funded developement, but it is still an option.

But i’am as well willing with this proposal to add the opt-out option and even to have burning coins the alternative additonally option for it. The important part and difference to the original proposal is that this version leaves room for such addition and option.

Modifying/Changing the current Zcash Governance Community Panel:

There would be need for a changed/improved Zcash Governance Community Panel and i’am taking the whole idea and example from my other proposal which as well has it as an requirement. It should be a must as allocating funds, discussing proposals and finally even voting on these should be an essential part of fair discussion, fair voting, fair polling, fair allocation of funds.

A new enhanced Governance Panel should replace the current Foundation’s Governance Panel:
This is just an idea below to show how a better, more fair goverance panel could look like:

  • ECC, 10 member
  • ZF, 10 member
  • Zcash Founding Scientists, 7 members IF not employed/paid at/by ZF or ECC allready.
  • Mining pools, biggest 10 mining pools each 1 member, results in 10 members
  • Hardware producers, Innosilicon & Bitmain: Each 3 or 5 members, results in 6-10 members
  • Investors like placeholder, blocktown, grayscale and such, each 1 or 2 members, results in “unclear”.
  • Zcash community: Every forum member registered on the official Zcash forum for at least 3 months? Eventually a minimal post count or other restriction could be added to avoid people joining just for voting reasons, results in unlimited unclear members.

Other possibilities to include"

  • Zcash affilated or Zcash supporting projects like parity, wallet creators, such like, 1 member each.
  • pretty sure i forgot some groups, this of course can be included as well.

The reasoning behind such design would be that indeed every arm of the Zcash community would be represented, would have a voice and even a vote and can influence important decisions that have to be made.
So far everybody is talking about community decisions but nobody is even near a plan on how this could be done fair, promising and working and accessable to literally everybody interested. Here at least a solution that tries to include all the different streams of the Zcash network.

Edit: Just thought that the more “normal community members” join the less influence the ZF, ECC, investors and so on would have.

I think a possible solution would be that the fixed members for a given organization should be per 100 people that vote. Means if the new governance community panel gets for example 200 members the members or vote count of the fixed members should be double to garantee a fair voting power distribution.

In my example this would mean that the 10 ECC members would have/get double the voting power resulting in 20 votes at the point the community panel reaches 200 members. Just as an example as there must be a mechanism that the bigger the community governance panel gets the influence of the must members like ZF, ECC doesn’t get inflationed.

Voting, Polling, Results:

  • Every member of the new governance panel gets invited to take take part in the discussion around a given proposals, changes, whatever and of course later a vote in the governance panel.
    A voting must result in a suggested 75% majority to be accepted, maybe 66% could be an alternative level as well. Up to community discussion what the best level in % would be to replace a wider community agreement.

Voting/Polling by the New community governance panel should be seen as binding even if not ultimatly and not like now just some polling. Eventually some pure highly technical aspects should not be taking into the new community governance panel, that’s up to further fine adjustment on what would qualify to be decided by the new community governance panel.

Final word:

3 Likes
2

@Sonya

any chance to get this proposal as well to the list of all proposals???

1 Like
3

Just added it to the lists!

1 Like
4

@sonya @str4d @mistfpga @acityinohio

Is this proposal ok in this form or does it have to get modified to get past the 31th august deadline?
If not, can someone please direct me what has to be changed to make it confirm?

1 Like
5

To be honest, I have not even seen or read this proposal before. It will take me a bit more time to look over. It is on my todo list now, and I think I should have reasonable feedback for you by 2pm UTC 27th. (tomorrow after lunch)

1 Like
6

I think it’s fine to submit as a draft ZIP. Advocates can still modify their draft ZIPs after the submission deadline, based on the feedback and discussion. So it doesn’t need to be 100% finalized and perfect. The goal is to be clear and well-considered, and in my opinion you’ve met that standard.

1 Like
7

Thx for the feedback, i appreciate it!

1 Like
8

@sonya , i’am withdrawing this proposal, please remove it from the list at: Future of Zcash dev funding — megathread / everything in one place

@str4d , as this proposal is one of the few that is not yet commented, no need to do it either as i’am withdrawing it, just to spare you some time!

Reasoning:

  • It was a proposal made to go strict with foundation’s opt-in only guideline. As in my opinion it’s clear by today that opt-in is no more a real requirement this proposal lost more or less it’s propose.

  • As the Zcash foundation refueses to be the soley recepient of a new dev fund, and they would be mostly with the proposal, even there is an option that the ECFS could be handled multi-sig as well, don’t think this proposal has any chances.

  • This proposal does not seem to get enough community support either so it would be only a waste of time and votes to push it further. Actually it got the most negative comments from all, lol.

  • I think the “votes” this proposal might get maybe are suited better for a proposal that has actually a chance to be choosen. Having in mind the overwhelming efford the ECC does to push their 20% favourite proposals it doesn’t make sense to have proposals that do not advocate a 20% dev fund splitting that much into various proposals that have minimal chances versus the proposals that are showcased by the ECC and it’s employees/affilates.

  • Therefore and due the above described personal arguments i choose to withdraw this proposal in favour of @Blocktown & @JamesTodaroMD proposal at [ZIP 1006] Blocktown Development Fund Proposal: 10% to a 2-of-3 multisig with community involved Third Entity which seems for me personally the only one opposing a new 20% dev fund that has a chance.

3 Likes
9

well im not deleting the work I did on this. :stuck_out_tongue: I like parts of it. I really don’t understand others.

I guess you are not up for answering questions. I hope you are just having a bad day. I think that the more proposals that go past august 31st the better. I will start a thread on it.

1 Like
10

No, it’s not a bad day, actually it’s a perfect day, lol.

I argumented above. Some proposals just don’t make sence by today, easy and simple as that.
The opt-in proposals have exactly 0 chance to get anywhere. Why even bother?

1 Like