Crowdfunded Bounties

[bedeho]

Background

Currently, the only way to fund the production of goods that create benefits to a broad set of platform participants is through a financing proposal or discretionary spending by a working group lead out of the group budget. These processes incur the transaction costs of beneficiaries having to convince a number of external decision-makers, such as a council financing quorum, that this is a good idea. For smaller initiatives that ideally should start and finish sooner, or where they depend on knowledge or insight that is not as broadly shared, these processes become too costly.

Proposal

Crowd funded bounties which allows a member, or the council, to crowd fund work on projects with a public benefit. The funding mechanism for the bounties attempts to facliate two forms of crowd funding:

• Assurance Contract: It only triggers if some minimal quantity is raised, otherwise all funds are returned. Described here https://en.wikipedia.org/wiki/Assurance_contract.
• Dominant Assurance Contract: The proposer is the only person who can submit a bounty solution - and thus claim the raised funds, however, the proposer must put up a pool of funds which will be distributed among all third parties that fund the pool in the event that the minimum quantity is not raised. Described further here http://mason.gmu.edu/~atabarro/PrivateProvision.pdf.

In either case, an oracle is required to judge how much of the collected funds should be paid to any given contributor of work on the bounty, and this will either be a pre-specified member, or the council iself.

Bounty Creation

Any member or the council can create a bounty by providing the following information.

• Metadata: A standardised structure document describing user facing information, for example a title, amount requested, deliverable, discovery metadata, link to forum etc. Is not stored in storage, chain only sees raw extrinsic payload blob, like rationales before.
• Oracle: Origin that will select winner(s), is either a given member or the council.
• Cherry: An mount of funding, possibly 0, provided by the creator which will be split among all other contributors should the min funding bound not be reached. If reached, cherry is returned to the creator. When council is creating bounty, this comes out of their budget, when a member does it, it comes from an account.
• Screened Entrants: The set of members who are allowed to submit their work, if not set, then it is open. Main use case for this is to model dominant assurance contract where member sets contribution cherry and him/herself sa only elidable worker.
• Minimum Amount: The minimum total quantity of funds, possibly 0, required for the bounty to become available for people to work on.
• Max Amount: Maximumm funding accepted, if this limit is reached, funding automatically is over.
• Entrant Stake: Amount of stake required, possibly 0, to enter bounty as entrant.
• Funding Period Length (Optional): Number of blocks from creation until funding is no longer possible. If not provided, then funding is called perpetual, and it only ends when minimum amount is reached.
• Work Period Length: Number of blocks from end of funding period until people can no longer submit bounty submissions.
• Judging Period Length: Number of block from end of work period until oracl can no longer decide winners.

Bounty Lifecycle

A bounty has the following phases

Funding

The initial period after creation where any other member can add their funding to the bounty. The funds are kept in a special per bounty account managed by the module. A given funder can repeatedly increase their total contribution multiple times but never decrease it. If the funding cap is reached at any time, then the funding period is instantly over, and one proceeds to the work period. Any contribution that partially overflows the cap results in the difference not being drawn. If the minimum funding bound is not reached by the time limit, then all funders can withdraw their contribution - including their share of the cherry, which is split proportionate to share of total funding (eeeek fractions, watch out!). The creator can cancel at any time before this, something that is of particular importance of in perpetual funding periods. If no one has contributed, any cherry is returned and the bounty is instantl removed, but if at least one contributor has funded, then the cherry will be split amont all contributors, and the bounty goes to the withdraw period.

Work

During the work period, a suitable member can announce they are working on the bounty - possibly requiring stake, called an entry, submit one or more work submissions corresponding to a given entry, or withdraw an entry at any time. A given member can submit independent entries to the same bounty. The staking period, by which we mean the earliest time you will get your stake back, is set to be by the end of the judging period. The stake is not reusable with any other purpose except voting in elections. Multiple members may announce they are working in parallel. One can withdraw an entry, which may return up to the staked amount, but possibly less. The slashing penalty is proportional to the total time the entry was active as a percentage of the share of the working period they were active, as this was discouraging other entrants. Being able to submit an entry depends on having announced you are working prior, and submitting your entry must be done prior to the end of the work period. All submitted entries are public.

Judging

The oracle selects two subset of entrants. First, the winners are selected, and the funding pool is split among them according to the ratio selected by the oracle. Second, any other legitimate entrants are selected as legitimate, yet not winning, which results in them being able to withdraw their full stake. Anyone else, that is those who either never submitted an entry at all, or submitted something bogus, will only be able to withdraw their stake with a penalty deducted. Withdrawing is in all cases an active operation by the entrant, so no iteration is required. When an oracle submits such a judgment, one transition to the challenge period. If no judgment is submitted, then the default outcome is that everyone will be able to withdraw the full stake, and all funders can withdraw their contributed funds also. The latter is also an action on the funders. But before this goes into effect, the challenge period begins.

Withdraw

During this time anyone can actually withdraw what they are owed, both winning submissions, losing submissions or funders in failed bounties. When the last withdrawal possible has been made, the bounty should be removed.

Implementation

• Should be a reusable set of module(s) that can be plugged into another runtime, so membership and oracle mechanism should be abstract.
• It appears (but this may be wrong) to be possible to write this without any limitation on the number of bounties, funders to a bounty or submissions to a bounty, as no iteration is really required. A key to observing this is that determinig what period a proposal is in determinable purely from user triggered milestones and time limits provided.

[mochet]

@bedeho one issue that has been floating around in my mind for a while is how the council, in a mainnet scenario could adapt the current KPI system to ensure there are regular checks and reports being made. I created a forum thread discussing this, and linked to some github issues exploring the idea of council checks/reports being made on an incentive basis (whereby users create reports with spending proposals, rather than relying on the council to do work, as they are the most incentivized people when it comes to this work): https://testnet.joystream.org/#/forum/threads/188

The regular checks/reports are difficult to define since they require both data and opinion, the data part is easy to perform using scripts, but when it comes to providing opinion things get complicated.

How it relates to the bounty board is that the council could create bounties for each council session for performing spot checks/creating reports. This would free up the proposal system from multiple spending proposals and also ensure there is some likely "guarantee" that good actors are paid for doing work.

So in each given council term, the council could issue several bounties, covering the "paperwork" and expect that the bounty board system/oracle would deal with judging the work, rather than relying on spending proposals.

This also means that the council could have a system of judging whether the platform is achieving reporting requirements, and adjust incentives accordingly if the reports are not completed: Joystream/community-repo#65

(this is largely redundant since you already mentioned the council being able to issue bounties, but if this use case changes anything I think its worth pointing out)

[bedeho]

Done in Olympia.