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. Spending Proposals: The Council agrees by voting threshold on a Treasury payout to a predetermined recipient for an activity.
2. Tips: A more lean payout method to a predetermined recipient in which at least a majority of the council members individually provide a valuation for an activity.

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:

1. Council Member apathy
2. UI/UX problems
3. Lack of (quality) Spending Proposals
4. Difficulty to curate Spending Proposals

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:

'Delegation of the curation activity of Spending Proposals to an expert called a Curator'.

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

1. Bounty for execution of a well specified work
   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).
2. Bounty for execution of a new iteration of previous work
   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.
3. Signalling important work by the Council or its Members
   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.
4. Getting a Council to commit to a future expense
   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.
5. Flexibility to match risk appetite of the Council
   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.
6. Earmarking / budgeting scarce Treasury funds
   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 Proposal would have a: Proposer, Curator, Reward and Description. Once a Bounty Proposal gets support of a Simple Majority of Council Members, it gets to be an Active Bounty. At that point the Reward goes to a Treasury Reservation or Treasury Lock, ensuring that the amount is earmarked for this purpose only. Bounty Proposals and Active Bounties would live in the runtime's state.

Once a Bounty Proposal is approved and it becomes an Active Bounty the Council should have no authority to revoke that decision.

The role of Curator allows the Council to delegate the work that requires expertise/effort that the Curator has.

The Curator gets to set a Payout Address for Active Bounties.

The Curator gets to close the Active Bounty. Closing the Active Bounty enacts a delayed payout to the Payout Address.

There should be an Expiry to the Lock/Reservation. A Bounty should have to be closed before a predetermined Expiry. If the Bounty expires, it can no longer be closed by the Curator. The Expired Bounty's Lock/Reservation can then only be refunded a public call (Refund) by anyone, releasing the Lock/Reservation to the Treasury.

Upon regular closing of the Bounty, the payout will be executed after a predetermined Delay. This Delay should allow for intervention through regular democracy. The Delay could 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 the Curator should 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:

1. Is it something you would support as an individual council member?
2. Is the work specified?
3. Is the work worth the amount?
4. Is the curator qualified/reputable to be delegated the responsibility of curation of the bounty work itself?

6b. Curator

It is the job of the Curator to curate the bounty work itself (execution and deliverables).

7. Implementation considerations

1. Is it technically similar to current instruments (Jam)?
   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.
2. Shouldn't the Curators be MultiSigs (Jam)?
   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.
3. What about Rogue Curator risks (Bruno)?
   Obviously there is risk of the Curator running off with the Payout. 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.
4. Shouldn't there be a cap on the Budget (Bruno)?
   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.
5. How will locks/reservations be implemented with the Treasury account?
   The Treasury Pot is a hard coded system account: modlpy/trsry => 0x6d6f646c70792f74727372790000000000000000000000000000000000000000 =>
   F3opxRbN5ZbjJNU511Kj2TLuzFcDq9BGduA9TgiECafpg29
   We can move the fund to another address, or simply make it reserved.
6. Follow-up regarding topping-up feature (section 8.2)?
   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.
7. Should the Council be able to intervene in the Payout (Bryan)?
   Bryan suggested that a Simple Majority of Council Members is 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.
8. Why should the Council not be able to cancel Active Bounties?
   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.
9. Deposit considerations
   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.
10. Should there be objective criteria that a Curator should meet (RRTTI)?
    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.
11. Should the Curator get a commission?
    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.

1. Management Fees
   I would favor to give a Bounty Proposal an extra attribute Curator Fee which could be a Permill (% of payout) or Balance (flat fee). Payout of the Curator Fee could be made dependent on a Council-vote. Needless to say a Curator is doing an important job and a remuneration should be considered.
2. Topping up bounties with external funds
   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.
3. Recursion
   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.