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
Comments (2)
don't particularly care for these changes, especially multistep approval and having council always determining the curator, it makes the bounty mechanism the most frictional and "managed" part of treasury. I feel like there have been conflicting goals for the Bounty extension - is it's purpose to allow usage of treasury to socially scale and allow more participants to access treasury? or is it's purpose purely a budgeting tool *for* the council? this change squarely puts it into the latter category imo. If the goal is just budgeting, this is fine, in the long-term though I'd like to see assign_curator to be something that is under the control of the "Oracles" and not council, if it must exist as a separate step. Council is quickly becoming a mechanism that can easily be used for self-enrichment.
I would caution against too much bike-shedding and wanting to please everybody. I think what we have above it great as a spending instrument as a first Phase. As we use it in practical terms, there will no doubt be a lot of adjustments. So would rather get it in (even sans sub-bounties) as a first phase so it can be used and tested in actual practice.