Discussions on improving the current treasury spending/management mechanism

Thanks for making these points @rich.

I agree with the role of curators to actually be more than mere accountants now too. Anaelle has made a similar point in the direction channel and I fully agree.

There is a lot of value in curators acting as liaisons. Helping facilitate communication with the community, other ecosystem teams and any other relevant party. Curators would be acutely aware of the progress different proposal teams are making and the problems they are facing. Acting as a facilitator to help overcome obstacles would ensure successful delivery of more projects and thus be a big value-add for proposers and the network at large.

The payout bounty structure encourages frequent updates and the goal here would be of course to structure this in a supportive manner.

All this puts significant amount of work on the payout bounty curators. A single payout bounty will definitely not be enough to process all the proposals. I would expect more groups to come together to create their own payout bounties. This is where I think we will see market forces making sure that resources are allocated efficiently.

Let us assume that we have 3 payout bounties running:

Payout Bounty C has just formed, the curators on this bounty are members with no track record or reputation. This bounty charges a very low curation fee per proposal per month.

Payout Bounty B has been around for a month and already successfully processed proposal payouts for 2 projects over the last month. The curators of this bounty have been in the community for a few months and have built up somewhat of a reputation. This bounty charges a medium curation fee per proposal per month.

Payout Bounty A has a proven track record with a lot of proposals processed. Over 1 million USD worth of funds has moved through this bounty already. The documentation tools built by the curators of this bounty are excellent. The curators are extremely well connected in the ecosystem and have a track record of helping teams overcome major obstacles in the past. This bounty charges a high curation fee per proposal per month.

We would be seeing amazing things happen here as market forces will efficiently allocate resources. Community might request bigger proposals to be processed by Payout Bounty A for example. The community is aware of the higher fees associated with processing a proposal through this bounty but believes the value added of payout bounty A to be worth the extra costs.

We may then also have a very small proposal come along with a very reputable and experienced team and a short project delivery. Community may feel that Bounty A is an overkill for this proposal and instead may prefer the project move through Bounty B or C.

I think we should establish fair compensation for the curators of the initial payout bounty but let market forces take care of things as more payout bounties emerge and start competing with one another.

1 Like

The model shown above looks more like what @sam from Imbue Network has built. Maybe Imbue Network can help with this?

With Imbue all projects present milestones, budgets and request funding from the community.
When you complete a milestone, it gets verified by those who funded the project and then a vote to release the funds this happens until its completed.

Imbue Network being a parachain also allows users to use any currency they’d like.

The model was going to start with a small council (to verify if milestones were completed) then eventually allow token holders to vote on the completed milestones.

Dotsama TV made a good explainer video on Imbue Network


Thanks for sharing this.

The Imbue idea and the payout bounty definitely are based around the same ideals. The payout bounty is an easy to implement mechanism available right now using existing tech. Imbue may complement the payout bounty system or maybe even replace it entirely when it launches.


Thanks for raising this topic which is highly important.
From my side I’m 100% in favor of using bounties from a certain amount (~$30K) if the proposal doesn’t require upfront payment (it may be necessary in some cases).

I think selection of bounty curators is the key: it is a lot of responsibilities to curate a big bounty: ensure transparency of sub-bounties payment, of the treasury management, controlling abuses and ensuring absence of conflict of interest.
A curator should assume there is a lot of work curating a big bounty, I think this is why some bounties may have been controversial: curators may not have realized the workload and as a consequence not controlling enough sub bounties distribution neither provided the sufficient reporting required.
At the end of the day, curators are the only responsible for management of funds.

Perhaps writing guidelines for curators, and defining an incentive for them is the good approach to move towards good use of bounty proposals.

As a starting point, here is what I consider a good example of bounty regular reporting.


There are a lot of valid points, if only it didn’t always end by promoting yourself :slight_smile:
Maybe as a professional proposal maker you could simply give community feedback on what was done right and what needs to be improved of your own experience?

1 Like

Thanks for this input.

Community should absolutely hold curators accountable to provide full transparency on the bounty.

Curators, as you said, should also be able to put in the effort and hours of the undertaking. Especially initially, guidelines will have to be worked out, documentation prepared and reporting interfaces built. Guiding teams to successful delivery is surely no undertaking that should be taken lightly. Responsibility of handling potential large amounts of money definitely requires a trustworthy and independent group of curators. For my candidacy to be a curator for the initial payout bounty I am looking to reserve 1h daily per proposal moving through the bounty. Maybe others with experience on curation can comment on this time expectation.

As to your point regarding up-front payments: a payout bounty would work either way.

If a project chooses to request part of the funds paid out upfront for example they would include an extrinsic for a transfer of that amount to their address in their referenda preimage. At the same time they would also include an extrinsic to transfer the remainder of the requested funds to the bounty address. Community then votes on it.

If a proposer does not want to include an upfront payment, then there would only be one transfer extrinsic in their referenda preimage, transferring the whole requested amount to the bounty. Community then votes on it.

1 Like

At a very basic level, the Imbue proposition you’ve outlined will be commoditised very quickly.

This does not mean I don’t think their network and team can be useful, or valuable, just that the low hanging technical fruit is not defensible alone.

I am not sure where direction of this topic is going but it feels like it is forking my existing approved proposal and going on a separate road with different focus. For this reason I want to clarify the direction and intention of existing proposal to prevent confusion with some of the subjects mentioned in this topic:

  • we are fully supporting the OpenGov processes and its design
  • we are not trying to introduce another “control” layer between the proposer and the community (treasury)
  • our work is intended to run in parallel with existing OpenGov processes (helping proposers form and create a clear, concise and transparent proposals)
  • our proposed curator role is responsible to audit only the quality of information presented in the proposal and not the Quality of the project/idea itself.
  • proposer have responsibility to deliver and report on the promised work and community should have a final say on it through onchain mechanism. The curator role is only to advise and remind proposers on these steps, community should have a final say on it.
  • we see the success if proposer defines clear milestones, deliverables and budget and and successfully reports and deliver the promised work
  • I support the Bounties with bounty mechanism, but I am not supporter of implementing Bounty mechanism over the community treasury proposals (introducing centralized group of people approving work and payments). Bounties Yes, Proposals as Bounty No.
  • if community thinks proposer is asking too much funding, he can always split the proposal in the smaller proposals with smaller milestones.
  • our initiative is open for everyone, any community member can apply to join the program
  • the goal of the program is to educate and provide experience to curators by being closely involved in the treasury proposals and the process

As mentioned in the first post, all info is provided here:

For those interested to join the initiative following and shaping above mentioned agenda, please read the plan and join the group of curators: #67 - Governance 2.0 Referenda Audits extension - Google Docs


Through payout bounties, the upfront payments can be largely reduced. This significantly reduces the risk for the token holders when approving proposal requests. Currently token holders seem to have moved to a more conservative position with the referenda approval. With a payout bounty token holders can have more confidence of successful project delivery when approving treasury requests. The effect of the payout bounties should thus be more (productive) investment from the treasury.

I don’t see this as a fork of your idea. I think as long as we have upfront payments there is a risk involved. Audits can help reduce the risk of these upfront payments further.

Furthermore, a requirement for a frictionless payout process is clearly defined milestones and payout conditions. This is where your effort compliments this one as well.

Curators are working for the token holders and it is in their best interest to keep token holders satisfied with their value added to the system. In my opinion curators should set standards and guidelines for reporting + encourage communication between token holders and proposers but they should not be doing this work for the projects. I see their main role as liaisons.

We are talking about a concept here and implementation is up to any and everyone out there. Anyone can start their own payout bounty at any time.

I intend to release a summary of what was said and where things are at right now and hope that clears up some of your questions too.


I agree with @bLd that curating large bounties is no easy task.

It’s easy to underrate the process when one has not been a curator. But the demands are so easily obvious once you’ve spent the first few months curating a bounty. That’s why I think bounty curators should be duly compensated so that they’re willing to dedicate more of their time to the curatorial process. I’m working on a document to help standardise the roles/responsibilities of bounty curators and proposed compensations.


The Problem

Until now proposals have largely been funded up-front by the treasury. This has removed financial incentives for teams to deliver their projects and resulted in multiple projects never being delivered, with some teams disappearing in the process.

Proposers need to sell their KSM tokens upon receipt in order to protect their ability to deliver. With treasury payouts happening in one lump sum (sometimes several $100k), proposers reported having difficulty liquidating the KSM to FIAT (Euro, USD etc.) or stable coins.

A sale event of a large amount of tokens puts downward pressure on the KSM price, thus harming token holders.

The Solution: Payout bounties

We need to do better at protecting the treasury, make it easier for proposers to liquidate their funds and limit price impacts of the selling event. All while incentivising continued and effective communication from the proposers to the community along their journey.

The idea of the payout bounty was born in the direction channel as members of the community were brainstorming on a solution to the above mentioned problems (Credits to @Abdulbee).

Through this payout system, funds would move to a bounty holding account, as opposed to the proposer’s address directly, upon referenda approval by the community. These funds would then be paid out gradually by the bounty based on predefined milestones.

How this looks in practice

When creating a referenda, proposers include a preimage. The preimage is the code to be executed when a referenda is approved.

Status quo:
Currently this preimage includes one token transfer transaction from the treasury to the proposer’s address.

Payout Bounty:
For proposals to be processed through the payout bounty, this transfer transaction would go to the bounty’s address.

Should a proposer seek to get an upfront payment, they would include two transfer transactions in the preimage. One transaction for the amount paid upfront to their wallet and a transaction for the remainder to the bounty address.

The value of curators

Curators design reporting standards and required tooling. Their focus at every step of the way should be to make communication between projects and token holders more frequent and efficient.

Overall curators are incentivised to ensure the successful completion of all projects moving through it. Ideally they are well connected members in the community that are able to drive collaboration with other ecosystem projects to overcome obstacles for example.

Curators should report to the community on the bounty itself and provide clear overviews on the projects moving through it, which step each project is at, obstacles encountered by projects, funding surplus/deficit etc.

Effects on the different Stakeholders

Advantages for Token Holders

  • Risk of approving proposals limited to funds asked up front

  • More successful completion of projects

  • Reduced downward price pressure through smaller token selloffs

  • Frequent reporting on project progress & roadblocks

  • More oversight into treasury spends

  • More accountability by proposers

Advantages for Proposers

  • Smaller payouts = Easier conversion

  • Guaranteed USD equivalent payments at each milestone

  • Higher chance of proposal approval by token holders

  • Support + guidance by curators

  • Access to curators networks

A disadvantage of the concept is the trust imposed on the curators. A significant amount of money would be under their control. It is crucial that curators are trustworthy individuals and independent of one another. Furthermore it is vital the community maintain oversight of the bounty and all its operations.


The payout bounty is a concept that in a permissionless network can be implemented by anyone and everyone. Competition amongst multiple payout bounties should be encouraged. This gives token holders more choice between different payout bounties with varying value adds and would help us allocate resources more efficiently as a network. Community would guide each proposal to the payout bounty they deem most appropriate for it.

Everyone wishing to express their interest in a candidacy as a curator is invited to do so in this post.


Nice outline.

One thought, is how can this model work in a ‘multi-chain/patron’ world.

Kusama (or any network operating gov w/ treasury spend, currently bears the full cost of projects - it makes sense to consider co-financing arrangements with other parachains and external groups.

This way we also split milestones and share risk - for example Kusama might not be ‘first money down’, for risky R&D type projects, but could be structured in a ‘tag-along’ structure - such that Kusama funds would be committed to a project, but they would not be released, unless co-financing was found.

In this model an external group would finance the riskiest R&D stage, but then have assurances that should this lead somewhere interesting, follow-on funding is assured, and can be drawn down, without returning to the start to debate the merits, instead it would be the bounty curators, who approved the funding based on the work achieved in the R&D phase…

This brings us closer to an on-chain W3F Grants programme.


There seems to be an abyssal difference here between the original post promoting bounty mechanism as it’s meant to be (each bounty has its curators responsible for the specific bounty they curate) and this “proposal” of having a centralized single payout bounty to pay for all proposals.

Centralizing payments into a single bounty is a terrible idea that should never happen for a million of obvious reasons. I have no idea why this came to look like a proposal.


I like this initiative, it embraces the Kusama spirit of experimentation offering a low tech solution to solve several issues we experience with treasury spends, I see it more as an MVP that can help us gather feedback from the community and proposers before we deploy a more specialized fully decentralized solution.

One topic we can try to make better from the get-go that is the main concern people see with bounties in general is its centralization around curators and feeling forced to go through them as gatekeepers of the funds. Curation should be seen as a service, something proposers chose not because they have to but because they see a good value in the service and will be well regarded by the community. Also curators shouldn’t be so static instead they could be chosen dynamically for each proposal from a big pool of curators, a curation community, that is diverse enough, where experience and rank are taken into consideration and token holders can ultimately control its fate.

This kind of solution would ideally involve specialized pallets, perhaps a new instance of the ranked collective pallet and even a whole parachain specialized in curation as it is a topic that is general enough that could benefit not only governance but any other use cases(e.g. curation is an important part of Virto’s p2p marketplaces to filter out bad quality goods or services). But before deploying an army of developers the low tech solution I would suggest instead of proposing a bounty is to abuse proxies and multi-sigs.

It’s surprising how far you can get with proxies, you can set up entire organizations like that and the curation community can be formed this way initially.
One possible flow I imagine could be:

  • A proposer submits a spend proposal and as payout account sets a pure proxy provided by the curation community, their actual payment address and other metadata can be a system.remark part of the same proposal.
  • The curation community is a pure proxy(that controls other payout pure proxies of proposals) and chooses N curators for this proposal(assigned as a multi-sig) depending on the track or extra content provided in the remark(e.g. specifying its a media related )
  • Optionally the main proxy of the curation community can automate the decision process with a simple bot that is a time delayed proxy that reads data from an external source like a ranked collective abstraction built on Statemine using a uniques collection.
  • The chosen curators do their job sending payments to proposers whenever they complete their milestones.
  • Optionally curators offer the extra service of managing assets and send payments already in a stable coin of choice(e.g. USDT) so proposers don’t have to worry about it. Curators could use trading instead of fees to make a profit and be rewarded for their services.
  • Project is completed and curators are removed from the pure proxy that can be destroyed or reused for future proposals.

If bootstrapping the curation community this way proves successful and the ecosystem sees value in this approach we can later turn it into a specialized solution.


A separate payout bounty for each proposal sounds nice in theory but I suspect would be hard in practice due to the difficulty and time effort involved in finding suitable curators.

I suspect we would land somewhere in the middle between the two extremes where we would have several payout bounties processing a few proposals each?

The idea of having a curation community is certainly interesting and ties in with @bLd’s point above. Difficulty here of course being that we find enough reliable/trustworthy curators for this community.

The use of proxies also seems interesting. However, perhaps bounties still provide more oversight for token holders? This would be foregone through the use of proxies.

Thanks for this input. Very curious to hear more opinions on this!

Based on the current capacity of the community we could issue a different amount of accounts to be used for payouts. E.g. if the community is only 6 curators it issues say 2 proxies, meaning only two proposals can be processed in parallel and leaves room for randomizing the selection. As the community grows it will have room for processing more proposals in parallel, also overtime its members will have time to prove themselves and gain enough reputation so the community can consider using the services of the curation community for more serious governance tacks like big spender or treasurer.
The whole process can be made very transparent if automated with code in the form of a simple bot connected to different channels like Matrix or the governance forums. Once the idea is validated and the community is happy with the results it would be even more transparent as we can move the curator community and its selection system on-chain.

1 Like

You’re proposing a $4K monthly payment for curators of a new unnecessary bounty, how do you expect it’s going to turn?
Bounties are working fine with their own curators, you’d better look at what exists (which was the original intention of this post) to see how it works before proposing alone to reinvent the wheel.
Sorry I won’t comment more this non sense.

I am personally well convinced seeing all your suggestions and pretty well sure that your ideas: if put in place, will help foster development in the ecosystem.

Im very pleased with this well structured and transparent proposal.:100::100: