Smart Contracts in Solidity to serve as a Standard for Bounties for EVM dApps

Go to file

mbeylin 2b930132cb removing build folder		2017-09-28 15:05:34 -04:00
contracts	updated tests	2017-09-28 14:52:29 -04:00
docs	changed param ordering, more tests, rearchitected the factory into sub-factories for each type of bounty	2017-09-05 11:51:10 -04:00
migrations	removing extras	2017-07-04 17:00:44 -04:00
test	more testing on increaseFulfillmentAmount function	2017-09-28 15:04:36 -04:00
.gitignore	fixed bugs, updated tests	2017-09-28 14:01:55 -04:00
.soliumignore	Linting and turning the stages state var to an Enum	2017-05-01 00:46:06 +01:00
.soliumrc.json	Linting and turning the stages state var to an Enum	2017-05-01 00:46:06 +01:00
README.md	reduced contract sizing, factory now allows for token bounty creation	2017-09-01 15:31:27 -04:00
truffle.js	truffle inits	2017-07-04 15:34:20 -04:00

README.md

StandardBounties

Version 0.0.1

Rationale
Implementation
Development
Documentation

A set of standard contracts to be used as interfaces for any kind of bounty, either qualitative or quantitative in nature.

1. Rationale

Ethereum smart contracts can trivially facilitate transactions of resources (or tokens) between individuals or groups, but service transactions are more complex. Requesting individuals (issuers) must first approve the work they're receiving before paying out funds, meaning bounty hunters must have trust that the issuer will pay them in the spirit of the original contract.

The StandardBounty.sol contract facilitates transactions on qualitative data (often representing artifacts of completion of some service), allowing bounty issuers to systematically approve the work they receive.

2. Implementation

A single bounty contract can be used to pay amounts of ETH or a given token, based on the successful completion of specific Milestones. The contract aims to reduce the necessary trust in the issuer by forcing them to deposit sufficient Ether (or tokens) to at minimum pay out each milestone once.

A bounty begins in the Draft state, where the requirements, deadline, arbiter, and reward amounts can still be altered.

In this state, the various functions which can be called are:
- contribute() [ANYONE]: contributes ETH (or tokens) to the bounty
- activateBounty() [ONLY ISSUER]: This will activate the bounty
- killBounty() [ONLY ISSUER]: This will kill the bounty
As well as several functions to alter the bounty details:
- changeBounty() [ONLY ISSUER]
- extendDeadline() [ONLY ISSUER]
A bounty transitions to the Active state when the issuer calls activateBounty().

This is only possible if
- the bounty hasn't expired (isn't past its deadline)
- the bounty has sufficient funds to pay out each milestone at least once
Once a bounty is Active, bounty hunters can submit fulfillments for the various milestones, and the bounty issuer can approve fulfillments to pay out the rewards.

In this state, the various functions which can be called are:
- fulfillBounty() [ANYONE BUT ISSUER OR ARBITER]:
- acceptFulfillment() [ONLY ISSUER OR ARBITER]:
- fulfillmentPayment() [ONLY FULFILLER]:
- killBounty() [ONLY ISSUER]:
A bounty transitions to the Dead state when the issuer calls killBounty(), which drains the contract of its balance, less the necessary funds to pay out fulfillments which have already been accepted but aren't yet paid out.

In this state, the only functions which can be called are:
- extendDeadline() [ONLY ISSUER]
- contribute() [ANYONE]
- activateBounty() [ONLY ISSUER]

3. Development

All the extension bounty types musn't break the state transitions as described above.

4. Documentation

For thorough documentation of all functions, see the documentation