With Referendum 89 passing on Kusama network, the network runtime is updated to v2025. This upgrade includes [Bounties extension] (https://github.com/paritytech/substrate/pull/5715) to the treasury pallet: something the community has requested and been working on for months.

Now that we have reached this point: What is next? The first bounty use-cases should set a standard when it comes **1. Structuring a proposal, 2. Discussing it, 3. Electing a curator for it. **

Structuring a Proposal

The bounty process introduces a two-step approval mechanism: the first step involves the Council approving the allocation while the second involves the Council deciding on a curator to take responsibility and ensuring that all tasks are properly executed.

For the first step, we have developed a skeleton of what the proposal could look like (similar to a Spending proposal) with some minimum requirements the Council needs in order to understand, assess and vote on bounty proposals: you can find the template here. Your proposal does not necessarily need to look like this, but it should at least cover all points of the template.

Discussing a Proposal & Electing a Curator

After the Council approves a proposal, it's time to elect a curator: the Council can invite curators to accept the challenge of managing a portion of the treasury. If one of the candidates accepts they make a deposit that will be returned once the bounty is closed but slashed in case of curator's misbehaviour. The curator is expected to have a good track record related to the issues the bounty is trying to resolve.

The introduction of curators allows the Council to extend their authority over a portion of the treasury. The treasury can have many active bounties and curators simultaneously.

The First Use Case for Kusama Network

In the last weeks, we gathered some ideas from the community about how to use this mehcanism once ready. All ideas can be found here.

Out of all them, building a bounty UI on Apps is paramount for the success of bounties: without it, it would be difficult for users to understand how bounties work, what is their status and what are their functions. This is the reason why we would like to suggest building a bounty UI as a first use-case: design front and dev front are needed to develop and implement this.

Development-wise, a new package/app would be added to Polkadot Js Apps under the Governance tab. Before having this on Apps, we would already have at least one bounty (the one building the UI for the extension). The first deliverable, merged and deployed would display what is already on-chain. The next steps for the bounty would include the development of bounty submission buttons, close button, extend button, claim button and other functions as defined on the bounty protocol, timeframe of bounty, curator's identity and link to the proposal, among other things. By the end of the roadmap, a user should be able to make full use of the functionality to manage bounties and monitor status.

It was suggested that the curator for this particular bounty should be Jaco, given his work and full commitment to Polkadot JS App. The curator fee will be 0 KSM.

A formal submission for this bounty will be presented to council in the next days to open the discussion. Other use cases included on the sheet will be presented for discussion as well in the next days.

This post is open to feedback, questions and comments regarding the extension and the first use cases.