Storage

StandardBounties storage structure

address issuer
The issuer is the creator of the bounty, and has full control over administering its rewards.

uint deadline
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.

string public data
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 can be found at the schema

uint public fulfillmentAmount
The number of units which the bounty pays out for successful completion, either in wei or in token units for the relevant contract.

address arbiter
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.

bool paysTokens
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.

BountyStages bountyStage
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.

uint balance
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.

mapping(uint=>Fulfillment[]) public fulfillments
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.

mapping(uint=>uint) public numAccepted
The number of submissions which have been accepted for each bounty