Initial Design

[laddhoffman]

Overview

The goal of this project is to enable Ethereum users to assign bounties to GitHub issues, and for solution contributors to claim those bounties.

Design Proposal

Contract

A bounty contract shall be developed. To create a bounty for an issue would involve deploying an instance of this contract.

The contract shall be able to store the following data:

• issueUrl: URL of GitHub issue
• donations: List of donations
  • donorAddress: ETC Address of donor
  • amount: Amount of donation
  • date: Date of donation
• claims: List of Claims
  • recipientAddress: ETC Address of potential recipient
  • date: Date of claim
  • approvals: Approval status by each donor
  • donorAddress: ETC Address of donor
  • status: enum value (null, approved, or rejected)
  • date: Date of approval status change

The contract shall expose the following methods:

• constructor(issueUrl)
• donate(donorAddress, issueUrl, amount) // Specify issueUrl to avoid race condition with possible newUrl
• claim(recipientAddress)
• assessClaim(recipientAddress, status) // status is an enum value (null, approved, or rejected)
• withdrawClaim(recipientAddress)

The rules of the contract shall be as follows:

• Anyone may construct a new bounty
• Anyone may donate to a bounty
• Anyone may submit a claim for a bounty
• Only the claim submitter may withdraw a claim
• Only donors may approve or reject claims
• If a claim is unanimously approved, the bounty is dispensed immediately
• If a claim is rejected by any donors, the bounty is not dispensed until the rejection is removed
• If, after 2 weeks, a claim has no rejections, the bounty will be dispensed
• A bounty may only be dispensed once

Off-chain Server-side Application

An off-chain server-side application shall be developed. This may run as a daemon, or on a scheduled interval.

This application shall have the following responsibilities:

• Monitor a list of bounty contracts
  • Check GitHub for issue status changes
  • Notify donors and claim submitters of these status changes, and how they affect the bounty process
• Serve a badge image that can be included in a GitHub issue Readme

Client-side Application

A client-side application shall be developed. This may be a web application.

This application shall have the following responsibilities:

• Allow donors to post new bounties for GitHub issues
• Publicly display the bounties associated with a GitHub issue
• Allow solution contributors to submit or withdraw claims
• Allow bounty donors to approve or reject claims
• When actions are performed, coordinate with the server-side app in order to notify donors and claim submitters of the changes

Design Considerations

The following questions were considered when preparing this design proposal.

How should bounty payouts work?

• One way would be "all or nothing"; entire bounty goes to the contributor whose solution is accepted.
• Another option would be to have the possibility of splitting a bounty among multiple contributors.

How should donations work?

• Donors can transfer funds to a bounty contract

Should bounties expire?

• If not, then the funds are potentially locked away indefinitely, in the case that a bounty is never fulfilled.
• If they do expire, this imposes a time constraint on contributors. Such a constraint could have a positive effect in that it provides an incentive to solve problems more quickly; but this would be a negative effect if it caused solutions to be hastily prepared.
• Time constraints increase complexity of the system

Can bounties be withdrawn?

• If bounties can be revoked, it increases the risk for potential contributors.
• There could be a delay for this, to prevent a bounty from being suddenly revoked at the last minute before fulfillment.
• If bounties can not be revoked, then the funds are potentially locked away indefinitely, in the case that a bounty is never fulfilled.
• Without a revokation mechanism, if a donor does not wish to pay the bounty they've posted, they will need to monitor that bounty and reject any claims submitted for it. This appropriately places the burden on the donor to make sure they only post bounties they are willing to pay.
• The rule could be that if a ticket is closed without resolution, bounties are refunded to the donors.
• Rather than being enforced by the contract, this could be enacted by an off-chain app, and by convention.

Does the contract need a monetary policy?

• This will be tracked as a separate issue, as it's not required for the core functionality

Can a bounty contract be upgraded in the future? By what mechanism?

• perhaps the community / those who have posted to a bounty can vote to approve changes; perhaps each one can be changed.
• This would be unnecessary if bounties can expire or be revoked

What role should core maintainers play in this scheme?

• They have the right / privilege / responsibility of reviewing and accepting or rejecting pull requests intended to fulfill bounties.
• Thus, they should not be eligible to receive payment for bounties.
• To enforce this, the bounty contract fulfillment mechanism would need to be able to identify these users.
• Preferably, the core maintainers' power should be limited to this one primary function of accopting and merging, or rejecting, pull requests. Additional control over bounties could impose unnecessary burdens on core maintainers and could increase exposure to moral hazards, since there is a possibility of collusion.
• It would be simpler to forgo automating this rule, and instead leave it up to the donors to enforce it with their bounty claim approvals / rejections.
• An off-chain app can assist in making these identifications if necessary.

Are there benefits to having a single contract for multiple bounties?

• Lower gas costs? How much does it cost to post a new contract?
• Potential for consolidating funds that are in escrow and investing; though, this is also something that could be managed by each contract.
• An important use case is to browse all open bounties! This could however be accomplished by an off-chain app with its own database; it would either simply track all bounties that it helped to post, or it could potentially scan the entire blockchain to discover any bounty contracts.

Are there benefits to having a separate contract deployed for each bounty?

• Each contract can be simpler
• If a new version of the contract is developed, it will be easy to migrate by simply using the new version for new bounties. If necessary, perhaps an old bounty can be revoked and a new one created.
• To start, we should aim for the simplest viable design, which is to deploy a separate contract for each bounty.

How will the contract identify GitHub issues?

• As bountysource does, by GitHub URL (github.com/X/Y/issues/N)
• The issue URL should be stored in the bounty

How will the contract know when issues are resolved?

• An off-chain application can query GitHub for the issue's status.
• The rules of bountysource are as follows: if an issue is closed as wont-fix, the bounty is refunded; if an issue is closed as a duplicate, the bounty is transferred to the referenced issue.
• The off-chain application will not have special privilege to modify the contract's data. Therefore the contract may not formally depend on the issue's status
• However, the off-chain application should have the capability of notifying the bounty donors. It can store their contact information in its ownoff-chain database.
• Bountysource also has some kind of feature to link Pull Requests to issues. We might be able to do something similar in an off-chain app.

How will the contract know when a solution is accepted?

• The rules of bountysource are as follows: Once the issue is closed, the solution contributor would post a claim for the bounty. The donors would then have 2 weeks to accept or reject the claim. If the donors unanimously approve the claim, it is paid immediately. If any reject it, it is not paid until the rejections are resolved. Otherwise it is paid after the 2 weeks is complete.
• The contract itself does not need to enforce any dependency on the issue status; that can be handled by an off-chain app, and by the donors when reviewing claims.

How can donors verify the identity of a claim submitter?

• We can define scheme for GitHub users to advertise their ETC address in their GitHub public profile.
• An off-chain application can assist donors in their claim review process by comparing the ETC address provided in a claim, with the ETC address provided in the GitHub profile of a claim submitter.

[laddhoffman]

I raised the question of whether it should be possible to revoke bounties.

Just wanted to note that with the current implementation, it is possible for a donor to claim their own bounty, which would have the same effect as revoking the bounty.

[laddhoffman]

@realcodywburns suggests that a registry is the best way to keep a list of bounties.

Should such a registry be stored on the blockchain? Storing on the blockchain would cost something to register, but has the advantage that anyone could implement a client to list bounty contracts. Storing off-chain could avoid paying gas costs, but information is power and nothing is free, so whoever controls the registry has the potential to influence what bounties are made visible.

I think a registry contract makes sense but I'm interested in alternate opinions.

[realcodywburns]

I like registries :) and voting on stuff. And bounties really. It would be easy enough to write a registry that tracked bounty contracts. Oddly enough I think I have most of the basic parts laying around in other projects.

• A voting board of directors: https://github.com/realcodywburns/BoardRoom
• Bounty contracts: https://github.com/realcodywburns/ChoreMaster
• Managed registry https://github.com/ethereumproject/TokenMint/blob/master/contracts/manReg.sol

[realcodywburns]

Members of a board can vote on sending funds or executing bytecode. Voting requires a quorum of members and a majority rules.

Bounty contracts can be issued, registered, and funded by the board. After someone claims they have completed a bounty, the board votes on whether or not it is complete and releases the funds.