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.
Summary
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.
Terms
- 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
Board should consist of at least:
- 1 representative of the foundation,
- 2 representatives of the community,
- 2 able technical reviewers.
- 2 able technical reviewers as backup, called upon in case where others are not replying for longer than a week.
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.
Payouts
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.
Anyone can ask the board to start project termination at any moment, however burden of proof is on the party which asks for the termination in case of premature request to terminate.
Chargebacks
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.