Treasury-pallet Bounty Extension #5713
Comments
|
Technical consideration that came up: Treasury Spendings are batched in the Treasury Pallet through Spending Periods. This should be taken into consideration in the specification. Pending on recommendations. Follow-up: |
|
Q: Technical consideration that came up: should we reuse: Follow-up: @xlc (Bryan) will start with something similar to |
|
Perhaps each of the Bounty Reservations could have its own deterministic Account/Address: The Treasury Pot is a hard coded system account: Each Bounty Reservation/Lock account could have a similar structure: This would solve the idea described in section 8.2 in the specification to get the public to top-up the bounty with non-treasury funds. Is this technically feasible? (@gavofyork, @xlc ) Update: Bryan mentioned |
|
A number of new
A number of new The following The following The following The following
|
Disclaimer and intro :)Disclaimer, some topics have been raised above and answered. Below is my take on new topics and some already mentioned. I do support the idea behind the bounty system, but not 100% in its current form (see below), mainly for what it lacks, but not for what it brings. I will use 'worker' as a term almost swappable with recipient expect that a worker may never receive anything. Fortunately, the bounty system is built to avoid such a case! I initially listed some questions. To move forward, I converted most of them into statements. The goal being to provide what I think could be a solution to the raised problem. ContentCancellation of active bountiesA This is obviously something we do not want to do but I think it should be possible to potentially close activated bounties under critical circumstances. In case no work was produced (see 'reservation of work' below), the council can stop the bounty immediately. In case work was produced, the curator will be handling the closing with full/partial/none payments using some of the allocated bounty funds. The curator can consult but his decision is sovereign. That means it could be beneficial to let the curator mention onchain that some work as been started/reserved. See below about that topic. TTLA bounty should have a Time To Live (TTL) ie expiry date. I don't see this date in the Type mapping above but that should be mandatory and some time in the future. This is what will help avoiding the need to cancel active bounties. TTL and sleepy curationHow do we handle the case where:
IMO, we can give the council the right to respond to an appeal in the case when a worker did:
This case will hopefully never happen. Curator issues
Sure a curator may use social recovery. But this is only an option which I don't think we can/should enforce. Data modeldescriptionThe
The short description will allow the various UIs to provide a short but human friendly summary of the delivery proofThe bounty Type should also have some kind of proof of delivery that the worker can set can freely set. It is in the interest of the worker to set it to proof the delivery before the expiry. The delivery proof is a field that can be confirmed/validated by the curator. The curator should be sovereign here and can unlock the payment even if no proof of delivery was provided. This case should be avoided though. reservation of workThe curator should be able to reserve the work for a bounty run so we avoid the case where we pay for 10 deliveries and get 100 workers. An alternative is to use the delivery of proof and limit to the first 10 valid (as confirmed by the curator) entries. Repeating bountiesProblem: Once a bounty is activated, how/who handles the sync of potentially multiple workers (not to say recipient) ? Should a bounty be limited to a single recipient? What about a bounty where we allocate say 100 KSM for 10 articles rewarded 10 KSM each. Solution: A bounty should be able to handle the previous example where we allocate X KSM for N Tasks where the payout is X/N. The one curator is in charge of managing all bounty runs. The proposer incentiveWe should incentivise the proposer as we do (it does not have to be the same amount) for the Curator in a similar way we reward the finder for a good tip. The proposer gets a reward, as the curator, per bounty run. Top upsMaking a small multi-runs bounty where top ups are allowed is a simple way to save storage and make verification and processing easier. That means we can extend the expiry of a bounty and add budget into it while preserving the description of the bounty. In that was, we should have the option to change the curator if needed. I see this especially useful for small running bounties such as producing educational content, blogs and articles, etc... |
|
Re: Curator issues, how about allow simple majority council to be act as curator to do payout / close / manage? |
|
(reviving this conversation because I feel it's important) I mentioned this when @emielvanderhoek was drafting the initial proposal, but I feel like if every bounty had to be approved by council, we aren't putting ourselves in a better situation than we are currently in - I think any curators should have free reign to create new bounties (of some minimum size, out of the balance of their own bounty) with new curators (this should be part of what the council considers when choosing a curator), as otherwise we're just changing the flow of the process of getting treasury funding, not the scalability. "sub-bounties", paired with @chevdor 's topup idea and we have a good framework around sustainable and extremely decentralized treasury usage, especially if we can get user-backed or user-matching-based topups. |
|
I don't have much opinions about this so I will wait until there is a clear agreement from people first. |
ghost
closed this as 
This specification is the result of a 4 day discussion on the Kusama Direction channel on Riot that addressed Council Governance in general and Treasury Spending in particular.
This specification extends the Treasury pallet with a new spending instrument called:
Bounties.Bryan Chen (@xlc) will be working on the PR to implement this specification. And @gavofyork has indicated to be willing to review the PR.
Treasury-pallet Bounty Extension
Kusama is a 3rd-generation blockchain with on-chain governance and an on-chain treasury. At time of writing the Kusama Treasury holds ~165.000 KSM which approximates 500.000 USD. The Treasury is controlled by the Council. In turn the Council's Members are elected through approval voting of KSM Holders, weighted by the number of tokens controlled.
The Council has two distinct Spending Instruments at its disposal to execute payouts from the Treasury.
1. Context
The Council has to date not been very successful to put the Treasury's funds to work. There have been discussions and speculation on the causes:
Item 4 will have the primary focus in the remainder of this document.
2. Problem statement
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).
There are practical limits to Council Member curation capabilities. Council Members likely do not have expertise to make a proper assessment of the activities described in Spending Proposals. Even if individual Council Members have that expertise, it is highly unlikely that a majority of Council Members have that expertise. This in one of the stagnating factors of Treasury Spending by the Council.
Initiative, ownership and responsibility originates in individuals and not in a collective. This document addresses the problem that the current Council with its current Spending Instruments is seeking to set objectives and seeking means for quality assurance for the execution.
3. Objectives
This document proposes an initial MVP design of a Budgeting System for Treasury Spendings.
The core idea this document contributes is:
This idea is implemented through a new Spending Instrument called: Treasury Bounties (or Treasury Budgets).
A Treasury Bounty is a specified body of work - or more general a specified set of objectives - that needs to be executed for a predefined Treasury Spending amount.
In contrast to existing Spending Instruments the Bounty Instrument's payout address is not known in advance. A Curator is assigned to be delegated that responsibility by the Council. It is the Curator's task to assess the result and execution of the objectives set for the Bounty.
4. Example use-cases
Example: Executing a survey with specified questions and respondents. In this case there is simply a lot of work to be done. This instrument would give guarantees for payout through the approved bounty that earmarks this future expense. Execution could simply be checked by a single Curator (such as one of the Council Members).
Example: Building a feature to Polkadot JS Apps by a reputable party. In this case past performances will provide a level of assurance that the feature will meet quality standards. This instrument would give guarantees for payout through the approved bounty that earmarks this future expense.
Example: the Council or its individual Members could create Bounty Proposals with description and budgeted amount (but without setting a Curator) to signal what work should be done and what an indication would be for the payout.
Example: If the Council entrusts the Curator with the execution of the work, this instrument would give guarantees for payout through the approved bounty that earmarks this future expense.
Example: If the Council requires additional assurances it could ask for a MultiSig Curator. This would still allow to earmark the future expense and would still allow for a separation (time and entity) between the allocation of the expenses and the curation of the execution of the work.
Example: The instrument could be used for earmarking/reserving of future expenses. This could become more useful the Treasury's funds are very low.
In general this Treasury Spending Instrument should be content agnostic should not be bounded (work or funds). Bounty Proposals should be approved on a case-by-case basis.
This Treasury Spending Instrument surely will not work in any situation. That said, it provides a useful addition to the existing instruments. The specification is simple enough to get implemented. The specification is sufficiently detailed to provide security guarantees to mitigate abuse. The instrument is sufficiently generic to allow for creative application.
5. Functional description
A simplest
Bounty Proposalwould have a:Proposer,Curator,RewardandDescription. Once aBounty Proposalgets support of aSimple MajorityofCouncil Members, it gets to be anActive Bounty. At that point theRewardgoes to aTreasury ReservationorTreasury Lock, ensuring that the amount is earmarked for this purpose only.Bounty ProposalsandActive Bountieswould live in the runtime's state.Once a
Bounty Proposalis approved and it becomes anActive BountytheCouncilshould have no authority to revoke that decision.The role of
Curatorallows theCouncilto delegate the work that requires expertise/effort that theCuratorhas.The
Curatorgets to set aPayout AddressforActive Bounties.The
Curatorgets to close theActive Bounty. Closing theActive Bountyenacts a delayed payout to thePayout Address.There should be an
Expiryto theLock/Reservation. ABountyshould have to be closed before a predeterminedExpiry. If theBountyexpires, it can no longer be closed by theCurator. TheExpired Bounty'sLock/Reservationcan then only be refunded a public call (Refund) by anyone, releasing theLock/Reservationto the Treasury.Upon regular closing of the
Bounty, the payout will be executed after a predeterminedDelay. ThisDelayshould allow for intervention through regular democracy. TheDelaycould be implemented as a runtime pallet constant and set to a fixed number of blocks (e.g. one week).Lastly there should be some way to cancel the
Active Bounty. Only theCuratorshould have that authority.6. Separation of concerns
In general the separation of concerns between Council and Curator allows the number of simultaneous Council activities to scale.
6a. Council
It is the job of the Council (and its individual members) to curate the bounty proposal:
6b. Curator
It is the job of the Curator to curate the bounty work itself (execution and deliverables).
7. Implementation considerations
Bounties are a distinct treasury spending instrument. Tips and spending proposals are not a bad instruments. There are sufficient similarities technically. That’s why it should not be too hard to get it implemented.
No they could be MultiSigs. I really want people to take responsibility, ownership, be accountable for their actions, etc. MultiSig curators should only be asked for in special circumstances.
Obviously there is risk of the
Curatorrunning off with thePayout. But again, I really want people to take responsibility, ownership, be accountable for their actions, etc. There are several ways to address Rogue Curators in the current MVP functional specification:a. Bounty's Payout Amounts do not have to be very high.
b. A Curator could be an elected Council Member who would have its reputation at stake.
c. A Curator could be a MultiSig under special circumstances.
d. The Council implicitly gets to set the Curator by approving the Bounty Proposal.
e. With a payout delay, democracy is able to intervene if needed.
I think the cap on a bounty is not a necessity. Currently the council could spend the entire treasury with one regular treasury proposal. Is this any different? A cap may have unintended consequences. It should be a simple tool to scale up useful spending by delegating curation of specialized work.
The Treasury Pot is a hard coded system account:
modlpy/trsry=>0x6d6f646c70792f74727372790000000000000000000000000000000000000000=>F3opxRbN5ZbjJNU511Kj2TLuzFcDq9BGduA9TgiECafpg29We can move the fund to another address, or simply make it reserved.
If we allow for a feature to public topping-up Bounty Proposals, there should be a distinct address for each individual Bounty. Ideally there should be a way to distinguish the Treasury component of the Bounty Proposal from the public component of the Bounty.
Bryan suggested that a
Simple MajorityofCouncil Membersis able to cancel the payout. I believe that the Council should not have this authority. By approving the Bounty Proposal the Council explicitly entrusts the Curator with the execution of the Bounty and thus grants the Curator to have its judgement within the scope of the Bounty. If the Council has the authority to intervene in the payout it would nullify this trust. A delayed payout is suggested as an alternate solution to allow for regular democracy intervention. This type of intervention does justice to the concern raised but finds a good balance with entrusting the Curator.Either the Active Bounty is successfully closed through payout or it expires and returns the Locked/Reserved funds to the Treasury. This should provide sufficient guarantees for Bounty payout upon completion of the work. Regular democracy could ultimately intervene.
The Bounties live in the state of the runtime during their life-cycle. Some considerations need to be addressed during implementation. Examples: Will a deposit be required to prevent spam? Is there a risk of state-bloat? Etc.
The Bounty Spending Instrument should be agnostic. That said, it should be a best-practice by the Council to only approve Curators that can be held accountable. Perhaps a positive judgement by the registrars could be a prerequisite. A Society tattoo could be sufficient. Ultimately this is up to the Council.
a Curator is doing an important job and a remuneration should be considered. This feature is described in section 8.1. I would even argue that the Curator Management Fee solves discussion on the merits and demerits of incentivizing membership on the Council. The Curator is without without doubt doing delegated work of the Council. The work done by the Curator results in achieving the objectives of the Council. The focus is no longer on who the Curator is but on what the Curator gets done. A Council Member could be a Curator if the task is within its expertise. That sound like incentive alignment to me.
8. Beyond the MVP
The following items do not necessarily require implementation to get to a functioning MVP of a Treasury Spending Instrument. That said especially items 1 & 2 provide very powerful additions to the Bounty Instrument.
I would favor to give a Bounty Proposal an extra attribute
Curator Feewhich could be aPermill(% of payout) orBalance(flat fee). Payout of theCurator Feecould be made dependent on aCouncil-vote. Needless to say a Curator is doing an important job and a remuneration should be considered.Perhaps the budget set by Bounty is insufficient to get the work done. A methods to have anyone make extra deposits onto the reserved/locked bounty may expedite the work.
Perhaps we can introduce the concept of allowing the Curator to specify sub-curators for sub-bounties of a given bounty. The delegation becomes recursive. This may have unintended consequences and should be left off-scope for the MVP.
Motivations of the Author
This document is written by Emiel Sebastiaan. Emiel has been involved in the Polkadot/Substrate ecosystem since the very early days and is working on the Polkascan project.
Polkascan supports the bold vision layed out by Web3 Foundation and aims to contribute to make Polkadot a success. Through Web3 Foundation grant work Polkascan has provided the ecosystem with an open-source block explorer from day one.
Polkascan has been an elected member of the Kusama Council since the very first council term. At Polkascan we believe that a public block explorer is part of critical ecosystem infrastructure. We believe that on-chain governance and on-chain treasuries are key instruments in financing public infrastructure (such as block explorers) in a sustainable way.
Polkascan will especially focus its council membership on a having a powerful active and opinionated council grounded in shared core-values. Additionally we aim to focus on sustainable treasury management that will enable sustainable growth and adoption of a prospering ecosystem and its key infrastructure.
The text was updated successfully, but these errors were encountered: