View on GitHub


SetBounty v1.0 Specification

Background & Research

Let us define three roles that will be referenced throughout:

  1. Leader
  2. Investor
  3. Developer

An issue is created by a Leader containing some amount of information, detail, or specification (for example, “Deploy landing page with project logo and contact form”). The amount of work required to resolve the issue may depend on many variables including the skill level of Developers contributing to the issue and the complexity of the solution desired by the Leader. This leads to challenges in estimating the time it will take to resolve the issue, compensating those that contributed that time, and proving that the work was completed as specified.

To simplify these problems, we will “blackbox” these unknowns as a function of the amount of money committed to a given issue. Investors interested in seeing the issue resolved will communicate that interest in the form of money “staked” while protecting their investment with a time-locked refund period. The Leader will then have until the end of that refund period to coordinate efforts to close the issue and disburse the money to Developers who had contributed to any pull requests that close the issue. If the issue remains open after the end of the refund period, the staked money will be returned to the Investor, who can then re-stake the same issue, stake on any other open issue, or simply take his/her money elsewhere.

The basic interface for v1.0 may be built directly into GitHub as a Chrome extension. API data can be accessed directly from a Node server that the Chrome app communicates with. A database may be used, but storing and securing sensitive user data with a Blockstack solution may decentralize the core technology and add long-term value to the project. Other solutions including drivechains and LN payment channels will also be explored to reduce the need for institutional financial services. The interactions among Leaders, Investors, & Developers may be modeled by setting certain constraints on sidechain mining nodes or LN channel counterparties, but further research & experimentation is required.

Creating an Issue

Issues are created through Github and maintained by a repository’s Leader. An issue should contain enough information, detail, or specification so that a Developer can resolve the issue with minimal communication with a Leader.

Resolving multiple pull requests

One solution could be to merge the 1st PR as is and open a new unfunded issue for adding a testing suite + code cleanup since it wasn’t explicitly asked for. Or the Leader could ask the 2nd dev to merge his PR into the 1st one and then evenly split the reward between the 2 devs.

If the Leader has begun reviewing 2 “competing” PRs (i.e. has left a comment on the PR or clicked “Start a Review” on GitHub), the developers who contributed to each PR have the ability to veto the Leader’s bounty % (if any). That way if the Leader fails to satisfy Developers of both PRs fairly, they lose their %. The vetoed Leader bounty could go back to the Investor, or diverted to other issues, but it should not go to the Developers so they are not incentivized to abuse the veto ability.



User Authentication & Github Access

Payment Options

All Users and Issues have a unique wallet to facilitate transactions while minimizing stripe transaction fees

Funding an Issue


Issue Resolution

Database Schema

# api/database/datamodel.graqphl

Tech Stack

Chrome Extension