Idea: 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 (not yet implemented?). 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

A crowdfunding mechanism which allows one or more individuals to propose, crowdfund and payout bounties, with possible dispute resolution from the council. Further, the funding itself can take one of two forms

• Assurance Contract: It only triggers if some minimal quantity is raised, otherwise all funds are returned.
• 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.

Both are described here

• https://en.wikipedia.org/wiki/Assurance_contract
• http://mason.gmu.edu/~atabarro/PrivateProvision.pdf

In both cases, an oracle is required to judge whether a payout should be made depending on whether the provided solution addressed the project goal.

Assurance Contract

Any member can create a new funding project which describes

• deliverable
• min funding bound
• funding cap
• possible contribution cherry: a pool of funding 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.
• max number of distinct entrants which may end up sharing the bounty
• possible required entrant stake
• time at which fund collection ends at the latest
• time allocated for people to submit bounty submissions
• time allocated for deciding who wins the bounty
• time allocated for the challenge period
• oracle: member who will decide who the winner(s) is/are, if any.

A bounty has the following phases

1. 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. If the minimum funding bound is not reached by the time limit, then all funders can withdraw their contribution - possibly including their share of the cherry, which is split proportionate to share of total funding.

2. Work: During the work period, entrants can announce that they are working on a submission, which possibly requires some stake. The staking period is set to be by the end of the judging period. Multiple people may announce they are working in parallel. Announcing this may require some amount of stake. 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.

3. 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.

4. Challenge: During this period, anyone can submit a staked proposal, in the proposal system, challenging the outcome, to the council. This can happen one time, and a single challenge should be used to aggregate all grievances that may be outstanding. It's the responsibility of the council to settle on a single outcome. If a challenge is posted, then one moves to the arbitration stage, otherwise one move to the withdrawl period.

5. Arbitration: During this time, the council is processing a challenge proposal. The period has a max upper bound, and if the council does not submit a final judgment within this time, then one moves to the withdrawl period.

6. Withdrawl: During this time anyone can actually withdraw what they are owed. When the lats withdrawal possible has been made, the bounty should be removed.

Dominant Assurance Contract

The approach here is a bit simpler because there is just a single entrant, but the basic structure is the same.

Implementation

• Should be a reusable set of module(s) that can be plugged into another runtime, so membership and arbitration mechanism should be abstracted.
• There has to be a max cap on the number of bounties that exist since they must be iterated. Since bounties can remain in the withdrawal period perpetually, at least in theory, this does mean that the system can get congested eventually.

Comment

Q: Why not just use Gitcoin?

A:

1. Gitcoin is only really for development, while bounties could be any sort of project.
2. Activity in Gitcoin cannot be captured as well in the Joystream system, and thus conduct in that system cannot be captured and count towards overall standing of a member within Joystream.
3. Activity in Gitcoin does not include the highly informed arbitration which is required in complex Joystream specific project disputes.
4. Its not clear whether JOY could eventually be used as the primary bounty currency.
5. Hard to do shared funding and incentivised shared funding.

Addendum

We should seriously consider whether the discussion module for the proposal system can be slightly refactored so that it can be an instance module base used with different subsystems, for example one discussion per bounty. Here the natural set of posters would be: creator, funders, any active contributor, or alternatively all members?

[mochet]

If I am to understand correctly this would enable funding of projects outside of the council almost entirely (except for dispute resolution?)
If so I think this would be great to have.
Questions:

• When bounties are made, will we get a bounty board where they can be sorted by stake/age?
• I'm assuming each bounty will get a discussion system, similar to how proposals work now?
• Most of the funding for these bounties would come from users if I understand correctly and not from council funds? I guess if that is the case a trusted user could create a spending proposal infrequently and divvy up the rewards between a few chosen projects to help better incentivize workers on projects? (ex. "Spending proposal: 100k tokens for top 10 current bounties") Otherwise if the council could create a separate "fund" specifically for this purpose and occasionally seed a handful of projects to help push things along.
• Should the accepted solution be accepted based on the idea of everyone who funded the proposal? I see that you mention that only the creator can accept a solution, but it would be nice if anyone who added funds to the proposal was able to vote in a proportional manner. This might help in situations where the creator is AFK for some time and its obvious that there is a great solution proposed?
• If it matters any for development, there should be a tag for the kind of project each bounty relates to (ex: "software" "media" "documentation"). Assuming the system is successful it would help if there were a way for users to separate out the kind of proposals they can are interested in funding or working on.

[bedeho]

Thanks for the feedback! Yes, this is meant to be outside the council. I have many times wanted to fund stuff myself personally, but there was never a great way to do it within the system itself I felt. But the scenario in which such a system would really shine is when there is a group of people all wanting something to get done, but without having to lobby the council.

• Yes, there will be a such bounty page and lots of supporting stuff that makes it easy to interact with.
• I was not sure about this, but it does make a great deal of sense. The fact that you asked for it makes me think that perhaps we should really do it right away.
• All funding comes from individual JOY holders, yes, not the platform through minting via the council or any other such mechanism.
• The acceptance would be the oracle, which the creator would pick, so the creator could pick themselves, or someone else that people trust. I agree that giving the funders influence could be quite good also, but it starts getting a bit too complex at that point.
• I agree tags and similar UI level features would help with discovery of relevant bounties.

[mochet]

The acceptance would be the oracle, which the creator would pick, so the creator could pick themselves, or someone else that people trust. I agree that giving the funders influence could be quite good also, but it starts getting a bit too complex at that point.

I think as long as that option is there to elect someone else as the oracle it would be good enough. My main worry was that there would be situations where people fund stuff and never accept the solutions because they get busy/AFK.

[mochet]

One other use case I hadn't thought of in previous responses was the marketplaces that currently exist for creating channel intros, thumbnails, logos and layouts. Or maybe a video creator wants an infographic or animation created for a project.

In a case like that the user creating the bounty would be putting 100% of the funds forward and the work being done would be solely for their benefit (ex. 100 JOY bounty for a new channel avatar).

I assume this could be done within the same bounty system without any real changes, but maybe just something to consider as it would enable this kind of work to take place directly within Joystream. Even if not its intended use, I could foresee people trying to use it for this purpose.

[bedeho]

Very interesting, yes I did not think of that use-case, I always thought of it as a place to produce things that benefit multiple people, but you are right that nothing in the design prevents it from being just a sort of gig board among members. That would actually be really cool.

[bedeho]

Here is an alternative scenario which may require a bit of a different model:

Some good cause is identified, a bit of money is put in, but it's not clear when exactly anyone is going to come along to solve it, nor is it perhaps very urgent to have it done by some deadline, it could just be some beneficial thing. E.g. getting some documentation improved, or solving some long-standing smaller issue. In this case, you may want funding not to stop at some predetermined amount of time. You instead want people to be able to contribute as long as the issue remains open, and for someone to be able to make a submission at any time, without announcing, and winning becomes a race that the oracle decides when has ended. Getting the funds back requires the council to cancel the bounty at some point.

[mochet]

Here is an alternative scenario which may require a bit of a different model:

Some good cause is identified, a bit of money is put in, but it's not clear when exactly anyone is going to come along to solve it, nor is it perhaps very urgent to have it done by some deadline, it could just be some beneficial thing. E.g. getting some documentation improved, or solving some long-standing smaller issue. In this case, you may want funding not to stop at some predetermined amount of time. You instead want people to be able to contribute as long as the issue remains open, and for someone to be able to make a submission at any time, without announcing, and winning becomes a race that the oracle decides when has ended. Getting the funds back requires the council to cancel the bounty at some point.

Would those issues be the sort added by council proposal? Similar to a spending proposal, but it would create a bounty listing with a set amount of tokens that is then the responsibility of the oracle to oversee?
If that were possible it would really strengthen the bounty system, especially in early days, as the council could determine what is worth funding and outsource work to the community. At later stages, when the platform is more developed, the council could provide initial funding for worthwhile bounties (ex. 30% of initial funding for new tutorial videos) and leave the rest of the funding up to community members.

The spending proposal system has some limitations which make it a bit challenging to use effectively as there is no oversight (like the bounty system would provide), so having some sort of link where a proposal is voted on that creates a bounty listing would be quite interesting to see.

Alternatively, if adding funding to a bounty is as simple as a balance transfer between accounts and does not involve extrinsics, then the spending proposal system could be used to send tokens directly towards a specific bounty. It would achieve the same thing.

[bedeho]

Check this for useful ideas

paritytech/substrate#5713

[bedeho]

Extra idea: perhaps it should be possbile for the council to also open a bounty, in which case the value add is less about getting outside buyin, and more about signalling - with commitment, what the council is explicitly looking to fund.

[bedeho]

Narrowed down and cleaned up here: #1998