swarms/ideas/121-swarm-compensation/models.md

A list of potential models to explore in experiments as part of this swarm

• Bountify All
• Grant & Burn

Bountify All

Problem

We have a lot of issues in various Status repositories. These could to a large extent be solved by the larger community, as well as incentivized according to priority by core contributors.

Additionally, there's no reward for putting bounties on issues, which leads to an uphill battle in terms of bounty growth (see Andy's slides Town Hall).

Solution

Create a swarm that will put a bounty on all outstanding issues and give bountifier/issue creator a reward (finder's fee) for doing so, assuming the issue gets solved.

The finder's fee can be ad hoc in inital implementation, and if proven successful it can be encoded in a SOB contract.

There are five objections for putting a bounty on all issues as far as I can see:

1. Issue is not well-defined enough

   Then it should be closed.

2. Issue requires privileged access

   OK exception - mark with label 'closed-flow' and move on.

3. Cost

   Currently we have around 500 issues in status-react. Assuming they are all good issues, and they get rewarded an average of $100 if solved, that's $50k. This isn't an unreasonable amount, assuming we actually solve these issues.

   Additionally, we can put an artificial growth limit on this. So first week 20 issues, next week 22, etc.

4. Perverse incentives

   This is only true for core contributors, and we aren't currently operating in a byzantine environment. So this can be solved simply by a basic honor system, and simple soft rules like not solving bounties you yourself put up.

5. Effort involved

   The finder's fee of 10% (or 5% for issue creator 5% for bounty creator) hopefully solves this issue. This is the hypothesis this swarm would test.

Future work

1. Automatically put bounties on all new issues, given some conditions

2. Instead of spitballing bounty size, use issue size and priority to determine bounty size. E.g. a matrix where bounty size can be 1*3=3 (small, high prio), 3*3=9 (big, high prio).

Grant & Burn

1. A user can request funds for a certain time interval, e.g. SNT10.000 for the next 30 days.
   • Usually this request will be tied to a specific proposed project/piece of work but that should be treated as implementation detail.
2. Other people "Supporters" can pay into this contract until the threshold is reached
3. After 30 days all supporters can either do
   • A) Nothing, their stake will be paid out to the requesting user in full after 10 more days.
   • B) Burn half their stake and receive back the other half.

Burning half the money is a big statement and people won't do that lightly — it's useful to flag bad actors though. The more usual case would be just not working with the user again (which is an acceptable outcome that should not have negative consequences for either side).

Allowing supporters to delegate the burning decision to someone else could be interesting in making this work for swarms as well. Swarm lead could be delegate for other people on the team while the swarm lead still remains accountable to original supporters. This might create a weird dynamic when the swarm lead doesn't get his chunk though.