[DRAFT][help wanted] Peercoin crowdfund model


This is long in the making, I never seem to get some spare time to actually finish it.
Technically this is a simple project, rudimentary version can be handled in one afternoon, however it’s painful to properly put all the definitions upfront. Definitions must be strict as they will become the law and it this law(s) will handle the money.
Post is made wiki so we handle this faster.


Peercoin project has a problem with funding for most of it’s existence. The problem of supporting both core and third party developers was seemingly tackled with Peer4Commit project but in the retrospective we can see that it has never really worked and amount of projects which are successfully funded with the Peer4commit is very low.

Major downfalls of Peer4commit project are:

  • centralized architecture (user data and funds are kept at central server);
  • lax security practices (multisig is not used);
  • fundraiser can change the scope of the project on the fly;
  • fundraisers have complete control over the funds;
  • fundraisers can keep the project active forever and never deliver without any repercussions.

The system in the following paper may not help the situation but it’s surely a better system which imposes stricter control over the donated money and forces the fund-raiser to fulfill the task.
Proposed system is fully decentralized, without a single point of failure and funds are kept in the multisig address(es). Projects have an negotiable expiry rate by default. Funds are released to the fundaraiser in tranches, which are equivalent of project milestones. In case of project failure backers are eligible for money return.


  • fundraiser

Individual, group of individuals or a company seeking funding from the Peercoin community.

  • backers

Backers are all individuals who back the project with donations.

  • board

Board is a body made of judges and technical reviewers who represent the interests of the community.

  • scope

A document used to present the project to board and the community.


Board should consist of at least:

  • 1 representative of the foundation,
  • 2 representatives of the community,
  • 2 able technical reviewers.

Board is in charge of keeping the donated funds in a multisig address, judging the completeness of the project, issuing payments to the fundraiser upon completion of the milestones or the whole project and liquidating the project.

Multisignature address

There should always be space left for lost wallets, people who go missing or other events.
For example if board has 7 members, multisig should be 3of5 up to 3of7.

General process explanation

A fundraiser requests for funding from the Peercoin community by writing a document (scope) in which the project is described in detail.
This document states what is going to be build, who is going to build it, how long will it take, how much will it cost, and how will it’s completion be judged.
After board reviews the scope and agrees with it, the scope is presented to the community and fundraise may begin.

After the first milestone is complete, fundraise asks the board to review and issue the first payment. And so is continued until project is completed and paid in full.

In case of project stalling and failing to deliver within timeframe defined in the scope, board starts the termination process in which funds are returned to backers.


As per scope payouts can be done upon completion of individual milestones or the
Whatever is left after all milestones are complete is considered a bonus for the fundraiser and payed out regardless of former payments.

Project scope

On submission fundraiser must define a clear scope of the project. Scope is detailed paper with in-depth descriptions of the project. Scope should include a summary, detailed design and finally milestones. It’s mandatory to include the estimate of total project duration and total estimated costs. Scope is submitted to the board for approval before the fundraise can start.
Project can have no milestones or up to five milestones. Milestones are limited to five to reduce the strain on reviewers and judges. If a project requires more than five milestones it should be split into several smaller projects. Each milestone must have a clear description on features which have to be implemented and proven to be working.
In case of a software project it’s recommended that function tests are implemented.

Milestones should be clear as possible and precisely define the expected state of the project upon each milestone.

Mandatory informations:

  • project scope,
  • total estimated time to complete the project,
  • total estimated cost required to complete the project,
  • tranches (milestones),
  • total estimated time to complete each individual milestone,
  • expected monetary reward upon completion of each milestone.

Project termination

In case of project failure or stalling, board starts the project termination.


In case of a fundraise failure for any reason the funds are to be returned to donors in a process called fundraise liquidation. While this is simple task in essence in reality we can expect many complications. It’s to be expected that some donors will send the funds directly from exchanges or other services, rather than from their personal wallets. This will make chargeback impossible.

Chargback process is executed via web interface where user is offered a randomy generated message which is to be signed with the privkey, a process which can be executed fully with the reference Peercoin client.

To prove the ownership of the address, customer is to sign random message with the pubkey matching the signature of at least one of the tranaction inputs.

Inputs list

Inputs list a cumulative list of all the UTXOs (unspent transaction outputs) which have participated in the crowdfund.

For example transaction A has two input UTXOs, 0 and 1 - both of which are owned by PMsx9DcEx3sj9nff7e1s34R5mzMPWXH8KX. So this address eligible to be on the list of input addresses.

Transaction B has two inputs, one originating from PSWNTA77E8h6DySr89eooNimBAQTBXzQ8z and P9qN6D4DpxVFwVo18ZNFm4EHrtYUKq6sGF - both addresses are eligible to be on the list of input addresses.

Donor can prove ownership over any of listed addresses to participate in the chargeback.

In case of two different UTXO addresses sign for different chargeback addresses on the same donation first come first serve principle is applied.

Conditions needed to participate in the chargeback process:

  • valid signature (proof-of-ownership)

blacklisting know exchange addresses

To disable personnel of exchanges from claiming chargebacks, known exchange addresses are to be blacklisted and can not participate in the chargeback process.


Great work. A few things to consider:

From my experience multisig which requires more than 3 people to sign become very slow and a lot of effort goes into chasing people to sign. So even if there are 7 people on a project board, I would recommend multi-sig not more than 3 of 7.

Board size appears to be very large. Would work for the large projects, but would be harder for indy-type one-person smaller projects. Perhaps we should have a small size project e.g. <$2,500. Probably not worth all the governance, just a reviewer and foundation rep would be adequate. The alternative is to scope projects under $2,500 out of crowdfunding supported by foundation. We may keep peer4commit or something else for the "indy’’ projects.

From a functionality perspective:

  1. Is there something for users to comment on projects. Or at least a link to the official project thread or chat.
  2. What is the process for scope changes? Almost no (larger) project exists without some scope changes.

Just my 0.02 PPC


@Cybnate what you say about multisig is probably correct.
I don’t think we can differentiate between indy and big projects, perhaps this board can simply dismiss too-small projects who are better of with a simple donation address or keeping with pee4commit.

  1. Is there something for users to comment on projects. Or at least a link to the official project thread or chat.

I was thinking to keep it simple and public, so I would use the forum for this.

  1. What is the process for scope changes? Almost no (larger) project exists without some scope changes.

That’s why milestones, like more detail views of the full scope. I guess changing scope for the full projects depends on the board. If board allows it to happen it can fly.


You could allow the developers to request an alteration of scope at each milestone. The issue is that then it’s possible for the initial investors to be edged out of what they ultimately want. But if you make it perfectly clear that only the first milestone will be implemented as written, the others will be implemented in spirit, then it might be fine.

Maybe make it ‘3-of-5’ up to ‘3-of-7’ and tell the dev that it is in their best interest to find those last two people, that have to be community members or particularly technically able (or a foundation rep).


1. What happens if a milestone or project is late, but hasn’t been abandoned. For example some unexpected issues came up and they were unable to finish it in the original timeframe they gave but they are almost done? Does the termination process start or is discretion given to the board to make the decision?

2. You say the scope is submitted to the board before fundraising can begin. Is this a private process where only the board can read the scope or is it public where the entire community can read it, perhaps a dedicated board on the forum? It seems to me that it would be public from the beginning and that fundraising would only begin once the board publicly posts a multisig address specific to that project for donations.

3. How are the board members chosen? Is it volunteer basis? Is there only one board to manage all fundraising or can there be a different board for different projects? For example in the case a technical reviewer knows how to review one project but not another. Someone else who has more knowledge and can properly judge a project could step in as a board member. That would require two different boards for different projects where the only difference may be one member being different.

4. Are board members compensated in any way or is it all volunteer work for the community? For example do they split 1% of what was raised in total for their fee in managing the process? This might help board members from abandoning the process during the length of the project, especially if it’s long-term project with many milestones.


Well sure it’s possible to ask for the board not to go into liquidation process so soon. We are all humans involved.

Public. Indeed fundraise only starts once board makes the multisig.

Basically we’ll chose them. Most of them will be people who read this board. I’d go with one board for all to minimize the confusion. I do not see us being prepared to form two boards anyway.
Volunteer basis, yes.

I did not think about this. Peercoin is open-source volunteer project so this should also be done in the same fashion.
Not sure how to fairly execute the fee and how would community react.
Perhaps that can be introduced in the future.


Devel team which is interested in taking this task is now available again, I will start moving with the implementation of this scheme.

Process to Receive Development Funding

1.	You, the developers, start by filling out the Project Pre-Form ULC00a01000.

2.	Next, propose your project to Peercoin Foundation members.  Try to start a discussion, possibly post your project publicly on the forum if you are comfortable with that.  Once you have some interest, provide the Foundation with your project pre-form.

3.	The Peercoin Foundation will move forward with projects at their discretion.  When ready, a committee will be formed with 1 Foundation Representative, 2 Community Representatives, and 2 Technical Reviewers.  They will form a multisignature address charged with collecting funds, judging completeness, and issuing the relevant transactions associated with completion/dissolution of the project.  Once completely formed, the committee will fill out the Project Development Form ULC00A02000 and provide it to you.  They may adjust aspects of the proposal, but should seek consent from the developers before publicly posting the form.

4.	Advertise the project and the associated multisignature donation address.  If the minimum donation is not achieved before the maximum allowed time, the funds will be dissolved and the developers are encouraged to rethink the proposal.

5.	Once the minimum donation is received, the committee will encourage you to begin development.

6.	You may request payment at most once for each completed quarter of the project, or once every 40 completed hours, whichever is more frequent, but not more than once every month.  Requests for payment should be made public, though contacting the board directly is also encouraged.  Due payment is at the discretion of the committee.

7.  If the grant expiration date is reached without completing the development work, the remaining funds in the donation address will be dissolved.  In this event, the committee will encourage developers to cease work on the expired grant and to propose a fresh one if applicable.

Development Project Pre-Form

1.	Project Title

2.	Developer Names/Aliases 

3.	Peercoin Receiving Address

4.  Project Description

5.	Funding Goal (in PPC)

6.	Minimum Donation Required to Begin Development (in PPC)

7.	Maximum Time to Wait for Minimum Donation (Days/Months/Years)

8.	Estimated Required Time (Number of Days/Months/Years after Beginning Development)

9.	Grant Expiration Date (Default: Estimated + 3 Months)

10.	Hourly Rate(s)

11.	Estimated Required Hours (Work Breakdown for Multiple Developers)

12.	Quality Control/Testing Standards

Development Project Form

1.	Project Title

2.	Donation Address

3.	Developer Names/Aliases 

4.	Committee Members

5.	Project Description

6.	Funding Goal (in PPC)

7.	Minimum Donation Required to Begin Development (in PPC)

8.	Maximum Time to Wait for Minimum Donation (Days/Months/Years)

9.	Estimated Required Time (Number of Days/Months/Years after Beginning Development)

10.	Grant Expiration Date

11.	Hourly Rate(s)

12.	Estimated Required Hours (Work Breakdown for Multiple Developers)

13.	Quality Control/Testing Standards


Peercoin has a market cap of rougly 21 million, is the first proof of stake cryptocurrency.

Is it that hard to get developers to actually invest in the coin and then have the self interest to do the project on their own time?


If you want talent to work on a project, you need to pay them. It is equally unreasonable to assume that all investors are also developers. When you say ‘get developers to have self interest’, what exactly would be the mechanism by which development projects are accomplished? Are you implying that we need to force developers to give both their time and money in order to be allowed to work on a project? How would we ever attract talent with that kind of deal?


Im just saying because the coin is valued so low is that not an incentive enough to invest in the future of the coin?

Dash/Cardano/Ethereum completely different scenario, you want to be paid because you won’t see a ROI by buying coins at market price, doing a project to add value.

Look at primecoin which fizzled out, 10 cents to $3+ based on a proposed fork.

Maybe outside the square thinking here, I see it as an opportunity for a developer…

If I had the skills why not buy 10,'s of thousands of coins, do the work, promote it, reap the rewards, thats called putting your money where your mouth is kind of thing…


If a developer’s intent is to pump the price of the coin so that they can cash out at a profit, there are plenty of ways to do that in the crypto space. With Peercoin, we hope to promote more long term thinking amongst our developers.