A bounty is a simple mechanism for individuals or groups to pay out for the completion of tasks. The issuer of the bounty begins by deploying a new bounty contract, during which time any of the storage variables (like bounty requirements or the payout amount) can be altered. Once sufficient funds have been deposited into the contract, the issuer may activate the bounty, allowing bounty hunters to submit fulfillments for the bounty task. The issuer can then approve the submitted work, releasing the payout funds to the bounty hunter in question.
A bounty can only be contributed to, activated, or fulfilled before the given deadline, however fulfillments can be accepted even after the deadline has passed. This deadline can be moved forward or backwards in the draft stage, but once the bounty is activated it can only be extended. This helps maintain the contractual nature of the relationship, where issuers cannot move deadlines forward arbitrarily while individuals are fulfilling the tasks.
All data representing the requirements are stored off-chain on IPFS, and their hash is updated here. Requirements and auxiliary data are mutable while the bounty is in the `Draft` stage, but becomes immutable when the bounty is activated, thereby "locking in" the terms of the contract, the requirements for acceptance for each milestone. These should be as rich as possible from the outset, to avoid conflicts stemming from task fulfillers believing they merited the bounty reward.
The schema for the bounty data field is:
```
{
title: // A string representing the title of the bounty
description: // A string representing the description of the bounty, including all requirements
sourceFileName: // A string representing the name of the file
sourceFileHash: // The IPFS hash of the file associated with the bounty
contact: // A string representing the preferred contact method of the issuer of the bounty
categories: // an array of strings, representing the categories of tasks which are being requested
The arbiter is an individual or contract who is able to accept fulfillments on the issuer's behalf. The arbiter is also disallowed from fulfilling the bounty.
A representation of whether the given bounty pays in ERC20 tokens or in ETH. When it is `true`, the bounty cannot accept ETH deposits, and vice versa when it is false, it will not transfer tokens to the contract.
Bounties are formed in the `Draft` stage, a period during which the issuer can edit any of the bounty's state variables, and attain sufficient funding. In the draft stage, no fulfillments can be submitted, and no funds can be paid out.
Once the bounty state variables are finalized, and the bounty contract holds sufficient funds to pay out each milestone at least once, it can be transitioned to the `Active` stage by only the issuer. During the active stage, the requirements or payout amount cannot be altered, however the deadline may be extended. Fulfillments can only be submitted in the `Active` stage before the deadline, although they may be accepted by the issuer or arbiter even after the deadline has passed.
At any point, the issuer can kill the bounty returning all funds to them (less the amount due for already accepted but unpaid submissions), transitioning the bounty into the `Dead` stage. However, this behaviour is highly discouraged and should be avoided at all costs.
The number of units of tokens or ETH which the bounty has under its control. The balance must always be greater than or equal to the owedAmount for a given bounty.
Work is submitted and a hash is stored on-chain, allowing any deliverable to be submitted for the same bounty. Fulfillments for a given `_bountyId` are added to the array of fulfillments at that same `_bountyId`.
Constructs the StandardBounties registry and instantiates it's owner as given
```
function StandardBounties(address _owner)
public
{
owner = _owner;
}
```
#### issueBounty()
Issues the bounty and instantiates state variables, initializing it in the draft stage. The bounty deadline must be after the time of issuance (contract deployment), and none of the milestones can pay out 0 tokens.
Issues the bounty and instantiates state variables, initializing it in the active stage. The bounty deadline must be after the time of issuance (contract deployment), and none of the milestones can pay out 0 tokens. The issuer must specify their initial deposit amount, which is checked against the deposited tokens or ETH. This new amount is the initial balance of the bounty.
This allows a bounty to receive 3rd party contributions from the crowd. This functionality is only available before the deadline has passed, and while the bounty is not in the `Dead` stage. The Ether (or tokens) which are deposited are at the mercy of the issuer, who can at any point call `killBounty()` to drain remaining funds.
If the bounty has sufficient funds to pay out at least once, it can be activated, allowing individuals to add submissions. Only the issuer is allowed to activate their bounty.
Once the bounty is active, anyone can fulfill it and submit the necessary deliverables (as long as the deadline has not passed). Anyone can fulfill the bounty, except for the issuer and arbiter, who are disallowed from doing so.
After a bounty has been fulfilled, the data representing the fulfillment deliverables can be changed or updated by the fulfiller, but only before the bounty has been accepted or paid. Individuals may only update the fulfillments which they personally submitted.
Submissions can be accepted by the issuer while the bounty is active, and the contract has sufficient funds to pay out all previously accepted submissions. Arbiters also have the ability to accept work, but should only do so after mediating between the issuer and fulfiller to resolve the conflict.
The issuer of the bounty can transition it into the `Dead` stage at any point in time, draining the bounty of all remaining funds (less the amount still due for successful fulfillments which are yet unpaid).
At any point, the issuer can transfer ownership of the bounty to a new address that they supply. This gives full power and authority to the new issuer address, and releases the old issuer address from the ability to administer the bounty.
The issuer of the bounty can change the deadline while the bounty is in the `Draft` stage. This is not allowed when the bounty is in the `Active` or `Dead` stage.
The issuer of the bounty can change the data while the bounty is in the `Draft` stage. This is not allowed when the bounty is in the `Active` or `Dead` stage.
```
function changeBountyData(uint _bountyId, string _newData)
public
validateBountyArrayIndex(_bountyId)
onlyIssuer(_bountyId)
isAtStage(_bountyId, BountyStages.Draft)
{
bounties[_bountyId].data = _newData;
BountyChanged(_bountyId);
}
```
#### changeBountyFulfillmentAmount()
The issuer of the bounty can change the fulfillment amount while the bounty is in the `Draft` stage. This is not allowed when the bounty is in the `Active` or `Dead` stage.
```
function changeBountyFulfillmentAmount(uint _bountyId, uint _newFulfillmentAmount)
The issuer of the bounty can change the arbiter while the bounty is in the `Draft` stage. This is not allowed when the bounty is in the `Active` or `Dead` stage.
```
function changeBountyArbiter(uint _bountyId, address _newArbiter)
public
validateBountyArrayIndex(_bountyId)
onlyIssuer(_bountyId)
isAtStage(_bountyId, BountyStages.Draft)
{
bounties[_bountyId].arbiter = _newArbiter;
BountyChanged(_bountyId);
}
```
#### changeBountyPaysTokens()
The issuer of the bounty can change whether the bounty pays in tokens or ETH, or change the token contract, while the bounty is in the `Draft` stage. This is not allowed when the bounty is in the `Active` or `Dead` stage. If the balance of the contract is non-zero, it will return all contributed funds to the issuer.
```
function changeBountyPaysTokens(uint _bountyId, bool _newPaysTokens, address _newTokenContract)
The issuer of the bounty can increase the payout of the bounty even in the `Active` stage, as long as the balance of their bounty is sufficient to pay out any accepted fulfillments.
