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

Introduction

In the cryptocurrency sphere there are many ways that projects try to fund their efforts. In recent years a veteran of the space may have heard terms such as ICO, Founder's/Dev Fee, Decentralized Treasury, and more.

The Monero Project, which is itself a decentralized project without formalized leadership or governance structures, is unable or unwilling to partake in any of the above funding methods, and has looked for a more decentralized method of both raising and dispersing funds that doesn't compromise the ideals of the community. The result is the Community Crowdfunding System (CCS) formerly known as the Forum Funding System (FFS).

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 CCS is a way for the community to propose ideas and request money, while utilizing the services of the Core Team as an escrow.

CCS Proposal Standard Flow

The standard CCS workflow is as follows:

1. An individual or team (henceforth 'proposer') has an idea to improve the Monero ecosystem that requires funds.
2. The proposer creates a CCS proposal, understanding the rules and expectations presented in the following section, and makes a Merge Request (MR) to the CCS Proposals repository on Monero's Gitlab 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.

CCS Rules and Expectations

The CCS 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 CCS 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 XMR will be put in the Monero General 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 Gitlab 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 CCS, 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.

For Translation Proposals

Translation proposals are currently disallowed, pending system redesign. You can still submit translations as a volunteer and are encouraged to do so.

Please create an account on translate.getmonero.org and follow the instructions described here. A Weblate guide is also provided.

If you need any assistance, please contact the Localization Workgroup at #monero-translations on Libera.Chat or Matrix.

How to submit a proposal

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