CIP: 8 Title: CIP Implementation Bounties Author: Robby Dermody Status: Accepted Type: Process Created: 2017-02-23
This CIP outlines the process by which bounties for work on Counterparty or Counterparty-related software should be proposed, created, operated and monitored.
Implementation of most CIPs requires a non-trivial amount of highly skilled design and development time. Bounties raised from the Counterparty community can be a useful tool to promote implementation of specific CIPs via raising the funds sometimes necessary to incentivize talented developers and compensate them for their time. This is especially true given the non-profit, volunteer nature of Counterparty development in general.
Prior to this process, implementation of CIPs via bounties was performed somewhat ad-hoc. This raised some confusion and exposed several ambiguities, such as potential mismatches in expectations between the individuals donating to the effort and the parties implementing the effort, as well as confusion regarding the degree of latitude to which the development party and/or project maintainers could exercise creative control of the implementation.
The goal of this CIP is to remove these and other potential points of conflict and institute a process that maximizes the chance of success while remaining as lightweight as possible.
The Counterparty Foundation Board may appoint one or more CIP Custodians, who shall be in charge of handling funds for currently open CIP bounty efforts. CIP custodians shall serve for an indeterminate amount of time and may be freely appointed and removed by the Counterparty Foundation members via a majority vote.
In its fiduciary duty, the Board shall seek to only appoint individuals that have a both a proven track record of involvement in Counterparty, as well as demonstrate trustworthy character traits. Each CIP custodian may not serve as a Counterparty Foundation board member at the same time, and may not serve as both a CIP author and CIP custodian for any specific proposal.
Current CIP Custodians
The foundation has appointed the following as CIP custodians:
- Jeremy Johnson (j-dog)
Bounty provisioning and operation
To begin, a CIP is created as normal, with the "Draft" status assigned. Once a CIP is in the draft stage, the CIP's author may choose to contact a CIP custodian, who will provision a donation address for that bounty under the sole control of the CIP custodian. A separate private key/address shall be used to handle the funds for each bounty independently. If multiple CIP custodians are serving, they may choose to jointly secure funds for a specific bounty via a multi-signature scheme, but such a scheme is not required. All funds gathered shall stay at the address to which they were sent while under the control of a CIP custodian.
Before a CIP custodian may provision a donation address for a specific CIP, that CIP must be written to include a section entitled "Milestones", which shall include the following:
- The fundraising goal, being a total amount (in BTC or XCP) that must be raised in order to consider fundraising for the CIP complete. (Contributions over and above this amount will be refunded to their senders by the CIP custodian.)
- One or more discrete milestones. For each, sufficiently detailed and actionable criteria which must be met in order to consider the milestone completed should be listed.
- Each milestone must also list a certain percentage figure, which will be the percentage of the total funds raised that will be disbursed by the CIP custodian upon the listed criteria being satisfied. All percentages must add up to 100%, and any "kickoff" milestone present, where funds are awarded without any actual work being done yet, may not exceed 10%.
Once produced, the donation address will be provided back to the CIP author over a pubic, auditable medium such as the Counterparty forums. The CIP author shall then include it in the "Milestones" section of the CIP draft, and may then commence the fundraising necessary to attract development talent to implement the CIP for an amount up to the listed fundraising goal. Once an interested developer is found, that developer's name should also be listed in the CIP as the individual (or individuals) implementing it. The CIP custodian shall not serve as a developer for any CIP for which he or she has control (or partial control) of the funds.
The CIP custodian is only obligated to disburse funds once the CIP is approved and the appropriate milestone(s) are completed. If either is not the case, no funds will be disbursed. If the CIP is rejected or deferred, the CIP author may choose to ask the CIP custodian to refund the raised funds to the community. In this event, the CIP custodian will send the funds back to each address that sent them, minus any applicable transaction fees. (For this reason, individuals should never donate from an exchange address, and should only donate from an address they control.)
The decision as to whether a milestone is reached shall be the sole decision of the relevant project maintainers (i.e. those who have write/commit access to the CounterpartyXCP repository or respositories to which the code is being merged). For each involved respository, a single project maintainer may normally review and approve a milestone being complete. However, if there is disagreement among project maintainers as to the completion of a specific milestone, such a disagreement must be resolved via a majority (51%) of project maintainers approving the completion of the milestone.
In the event of fraud or sufficient controversy surrounding a CIP or CIP bounty, a project maintainer or the Counterparty Foundation board (via a majority vote) may compel the CIP custodian to refund undisbursed funds. Although the Board makes every effort to elect trustworthy CIP custodians, it is ultimately not in control of or reponsible for their behavior. If a CIP custodian were to abuse the public trust and abscond with the funds entrusted to them, the Board will make every reasonable effort in its discretion to recover the funds in good faith but may not be held liable otherwise.
Alternative (non-CIP) use
Although this process is intended for use with implementation of CIPs, it may be adapted for use in development efforts that are not formalized via a CIP but are instead more general. An example of this would be a proposal to raise funds for a block of hours of a developer's time to fix bugs in
counterparty-lib. In this case, no CIP would exist, but the proposal would list out the primary duties required of the developer and would be split into one or more milestones. A CIP custodian could also be utilized to gather and hold the funds to be disbursed as the milestones were meant. As with merging of a CIP's implementation, the relevant bug fixes would be merged into
counterparty-lib at the sole discresion of the project maintainers.
This document is placed in the public domain.