What is the ZCS, and what are its rules and expectations?

Introduction

Zcoin currently has a development reward of 6% of the block reward. This has been sufficient to fund development and marketing expenses of the project.

However there is a pressing need for alternative sources of funding both for the long term sustainability of the project and also for further decentralization. A development reward is a source of centralization and we hope the ZCS incentivizes external third party development and prepares us for a time when we may not need a development reward anymore.

There are many different types of proposals, all with their own goals in mind. In the past, we have seen things from coding new software, developing third party resources, travel reimbursement for conference presenters, and hiring skilled individuals for full-time or part-time work.

The ZCS is a way for the community to propose ideas and request money, while utilizing the services of the Core Team as an escrow. The ZCS is forked from Monero's CCS with the help of rehrar.

ZCS Proposal Standard Flow

The standard ZCS workflow is as follows:

  1. An individual or team (henceforth 'proposer') has an idea to improve the Zcoin ecosystem that requires funds.
  2. The proposer creates a ZCS proposal, understanding the rules and expectations presented in the following section, and makes a Merge Request (MR) to the ZCS Proposals repository on Zcoin's Github instance. All steps to submit this Merge Request can be found here.
  3. The community discusses the pros and cons of the proposal, and offers feedback and critique.
  4. The proposer changes the proposal (if necessary), utilizing the feedback and critique of the community.
  5. Repeat steps 3 and 4 as needed.
  6. After the Core Team has determined that the community has reached loose consensus, the MR is merged, and funding begins.
  7. Once fully funded (not guaranteed), the proposal is moved to Work in Progress, where the team begins on the work, if they haven't already.
  8. Milestones are completed, and funds are dispersed upon their completion.
  9. After all milestones are completed, the proposal is moved into Completed Proposals, where all info is retained for posterity.

ZCS Rules and Expectations

The ZCS 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 ZCS is escrowed by the Core Team. When you make a donation, you are releasing funds to them to disperse 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 dispersed to the intended recipient, the default is that the remaining XZC will be put in the Zcoin development fund. There are some exceptions, but they are rare, and these decisions rest with the Core Team.
  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 proposers wishes (meaning some will require more trust of the proposer if the fund release schedule is immediate or accelerated), it is up to the donor to do their due diligience 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 Ideas 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 first two stages. Do not expect others (especially the Core Team 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 the Github comments of your 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, such as at the biweekly community or dev meetings.
  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 ZCS, and can lead to scams.
  6. Your work on the project can begin before the proposal is fully funded, and milestones may (at times) be paid out before the proposal is fully funded.

How to submit a proposal

Please read this page for step-by-step instructions on how to submit a proposal.