A Final Check on Bounties' Development

As you all know, we have been working on Bounties for a few weeks now. The final stage has come and we are now in the final benchmarking and testing period, and after a final review the code will be merged and added to one of the next runtime upgrades.

As it is now, and given some technical difficulties discussed, we have decided to take a gradual approach to the bounties development. In this sense we introduce a two-step approval mechanism:

• First, the Council approves the bounty allocation.
• Second, the Council decides on a curator to take the role for the particular earmark: once the curator accepts the position offered by the Council, the curator makes a deposit. The deposit can be used to punish them if they act maliciously, but if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back along with part of the bounty as a reward (the curator fee).

This mechanism allows the Council to delegate responsibilities and the Curator to be held accountable. Certain limits are set in place with the goal of avoiding bad behaviour: the Council is allowed to cancel any payment during the delayed payout period (the period between bounty being awarded and the reward being claimed) or unassign the curator to the earmarked funds if they do not fulfil expectations. But when the bounty is active, ONLY the curator can cancel it.

What's to come:

To increase complexity in a gradual manner, we are adding sub-bounties in the next PR in the exact way as discussed in the Direction channel a few weeks ago. Sub-bounties will allow curators to divide tasks and work with different teams as needed.

Sub-bounties added a lot of complexity to the code that needs to be tested first with simpler use-cases. Practically speaking, they can be practiced off-chain for now until familiarity with the code is reached and the new PR is ready to be pushed.

On the PR, Sub-bounties will be just bounties with a link to the parent. What we will include is a depth in the bounty. We will include a track and a limit. We should have a limit on the amount of sub-bounties, a track to link to parents (to know what belongs where) and a cap on recursion to 1 (to avoid dividing a bounty into infinite levels and becoming a PM nightmare).

You can find below a diagram with the current flow to understand better. This will be updated once sub-bounties are in place:

Current implementation : https://github.com/paritytech/substrate/pull/5715

Original idea: https://github.com/paritytech/substrate/issues/5713