Bounty Pallet Overhaul

[joepetrowski]

We should make some changes to pallet-bounties for better usability and some new features. Here is a list of what I have in mind, feel free to add more in comments here:

• It should be possible to create a bounty and assign curators in one referendum. Right now, a successful referendum returns the bounty ID, which is needed to assign curators. This leads to a two-phase (read: minimum 2 month) setup process for a bounty on Polkadot. Besides the annoyance, this also has some unintended side effects, like people trying to take over/repurpose existing bounties instead of starting a new one.
• Child bounties should be easier to use. Right now, IDs are global, meaning the parent bounty curators cannot create and award child bounties easily (again, need to get the ID). These should be batchable.
• Bounties should support multiple assets held in multiple locations (à la multi-asset Treasury).
• Bounties should work within Collectives (this may actually already be the case, I see they are instantiable).

[ggwpez]

Maybe also include #4947

[kianenigma]

With a strong mentorship of a core FRAME dev, this should be do-able by an external developer. We can reward this well with a tip. Marking as mentor to signal this.

Ironically, we need a bounty for this..

[gui1117]

batching stuff could be achieved without global IDs by providing a new call which executes the whole batch:

• for child bounties Will explained it here: Remove sequential increment requirements for Child Bounties #4947 (comment)
• for bounties:
  • we can have a new call: propose_bounty_with_curator. and the curator would be another storage PendingCurator until bounty is accepted.
  • and propose_bounty_with_accepted_curator. implemented similarly.

[lolmcshizz]

Currently, bounties must be "extended" every 90 days - this makes sense to ensure that they are alive and still needed, however, it feels unnecessary if there are otherwise signs of activity e.g. if there have been child bounties awarded. It would be great if the 90 days could be from the last activity from the bounty.

[xlc]

The 90 days extend requirement was meant to require the curator to remark some updates about the bounty. while the bounty could indeed be active, I think it is still reasonable to expect the curator to provide some public updates to the community every 90 days. What's missing is a good UI to remark such update and make it visible to public.

[lolmcshizz]

Having this on-chain is pointless and just a source of friction - there are many other ways of providing updates. I do not see a universe where this is used in the "intended" way.

[xlc]

yeah it is unfortunate no one is using it as intended. another alternative is requiring a bounty duration when creating a bounty and requires a public proposal to renew/topup when it about to expire

[PieWol]

• for bounties:

  • we can have a new call: propose_bounty_with_curator. and the curator would be another storage PendingCurator until bounty is accepted.
  • and propose_bounty_with_accepted_curator. implemented similarly.

What would be a reason to have propose_bounty_with_curator when you can have propose_bounty_with_accepted_curator?

[PieWol]

I'd like to execute this. @kianenigma. At least starting with implementing the possibility to create a bounty with curators at the same time. the rest can follow after there seems to be consensus on what needs to change.

[xlc]

Let me explain bit more initial design decision and see if want to and how to change those:

• Curator deposit and payout delay: In order to prevent curator to just steal all the funds, there is a deposit and payout delay. The idea is that the council can slash curator and cancel a pending payout if the curator misbehaving. We don't have council anymore so people are requesting to reduce payout delay to zero. This increases the required trustness of curators. There is still a deposit but it is pointless without payout delay. We need to revisit this mechanism.
• Because we take a slashable deposit from curator, so we can't just assign people to it. It has to be a two step process to ensure a mutual agreement. This could change if there is no more deposit.

I will suggest go back to drawing board as the circumstance have been changed significantly since the initial version (Gov1 vs OpenGov) and we have lot more usages / experiences / feedbacks.

I will image steps of:

• gather requirements
• create draft implementation design
• ensure it meets requirement and easy to migrate to
• actually implement it

[PieWol]

Thanks for providing an explanation! Given that this is not only implementation I'll leave this issue be.

[muharem]

@xlc now the OpenGov can cancel the bounty and slash, I think the payout delay is still relevant. We might need to adjust the delay or the OpenGov track or/and have another body to take care of it.

[xlc]

In that case we need to find the right balance between of delay time. If too long, obviously bad, if too short, that requires OpenGov track voting time to be shorter, which could also be bad.
I think we need a proper RFC with some numbers and lot more inputs from others before a decision can be made.