Reopening the discussion on Bounties and Treasury spending issues! Open questions
Let's go back to the past discussion on how to use the Treasury effectively.
Treasury-pallet Bounty Extension #5713 (https://github.com/paritytech/substrate/issues/5713) tries to tackle the issue with spending instruments. At the moment, the Council has two distinct Spending Instruments at its disposal to execute payouts from the Treasury but these do not scale and council members do not have time, expertise or interest in activating the mechanism.
In order for a Council to be successful, it should have a general direction and thus have (strategic) objectives. At the very least a Council should work from a coherent set of core-values. When a Council puts its Treasury's funds to work to achieve those objectives, execution of that work should be effective (and ideally efficient).
Extension #5713 proposal offers an initial option for "budgeting" the Treasury funds, at least in a more ad-hoc way for now. Thanks to previous discussions we can summarise some open questions on the design:
- A
BountyActivatedbounty should be cancellable by the council? Yes / No. - Should Time to Deliver be set up on the design? this would allow avoiding with the problem of a "sleepy"curator - Yes/No.
- It should be a best-practice by the Council to only approve Curators that can be held accountable: how to avoid "bad"curators or lost of access to address?
3.a. should the curator be a Multisig? Yes/No.
3.b. should a curator have a verified identity? Yes/No.
3.c. should a curator be part of the council? Yes/No.
3.d. should the council be able to change curators? Yes/No.
3.e. the idea of sub-bounties: should curators have the capacity to create sub-bounties? Yes/No.
Please keep in mind the goal is to solve scalability with regards to Treasury spending. With a clearer agreement on these topics we will be able to move this experiment further, maybe add new elements and start using these funds for Kusama's benefit.
Please add your answers to the questions above and any other point I am missing for this discussion, I am sure there are more open questions and these are only a few.
Current implementation : https://github.com/paritytech/substrate/pull/5715
Comments (25)
Thanks for bringing this up again. Here my initial responses: 1 No, otherwise it might result in a huge risk for bounty hunters/grants (suddenly the bounty no longer exists, but they already finished almost everything). Instead see number 2 2 Yes, it’s always helpful to set a timeline. The timeline itself could be rather generous, but it ensures that in 10 years from now someone isn’t able to claim tokens which are worth millions of dollars for somethings useless 3 On-chain identity + potentially curators need to stake a certain amount 3.a. Doesn’t need to be (for smaller grants), but could be 3.b. Yes, otherwise it’s fairly easy to attack the system (receive bounty and evaluate the work) 3.c. Curator could be part of the council, but don’t need to be 3.d. Yes 3.e. Depends on the definition of a sub-bounty. For now, I wouldn’t integrate this.
I think this is unnecessary - cancellation can be performed by a curator by setting payout address to the treasury address. The story here changes if there are "curator fees" that go to the curator on payout, but that's not currently present.
I think it's unnecessary if the curator can be changed manually to avoid the problem this solves. I don't think it's undesirable though, but maybe unnecessarily complex.
Modifiable curator - after all the curator is basically what the council is approving - so giving them authority to modify in the case of a malicious curator or loss of account access is a good way to make the curator more accountable.
a. cannot be (simply) enforced onchain, I would argue is not a necessity to enforce offchain. (No)
b. Probably, in order for bounty-claimers to have a contact address? (Yes)
c. Maybe? This shouldn't be an enforced condition, neither should it exclude someone from being a curator if they are a councilor.
d. Yes, council should, but the curator should also be able to hand over responsibility to someone else - this makes other things like loss of access to curator account or cancellation of bounties or protection from malicious curators easier.
e. Yes, as long as they are of some absolute minimum size (so the number of potential sub-bounties is capped, and only bounties above a certain size/scope can be split into sub-bounties).
Edit: to clarify the idea of sub-bounties because I've largely been the one pushing it - the idea is that a curator, instead of paying out a bounty immediately, can create a new bounty with a portion of the budget of their current bounty with its own curator. Ideally this allows less concentration on decision making on the part of the Council, as ideally they'd approve several "mega bounties" with broad goals, and curators that are composed of multisigs of domain experts, and have them act as mini-treasuries on their own.