Collective-Based, Multi-Asset Treasuries

I want to share how I see the Treasury evolving with respect to OpenGov and many of the challenges that people have been facing in the last year. Many of these problems have been listed in other threads, but I’m starting a new one to try to generalize some of these and offer a more holistic approach than trying to fix some of these frustrations individually.

I think a lot of concerns reduce down to two core issues:

  1. Treasury mismanagement, either by overspending or over-rejecting. This derives from a few issues:
    • Noise: People cannot sincerely evaluate the sheer number of proposals;
    • Expertise: People do not have the expertise to evaluate certain proposals, or even the expertise to know that a proposal is worth evaluating (e.g. for technical infrastructure).
  2. Single asset (DOT) limitations, and the desire for stablecoin proposals.

Collectives and Treasuries

Just like Polkadot technically pushes information (state) and functionality (specialized logic) to the edges of the system (i.e. in parachains instead of the Relay Chain), the Treasury too can push decision making out of its “core”.

I would generally propose that this gets accomplished in concert with the new collectives that are launching on Polkadot (most recently the Technical Fellowship). Other collectives that I’ve heard discussed are (by no means exhaustive):

  • Parachain Technical Fellowship
  • Ambassador Program
  • Polkadot Media
  • Anti-Scam Team

Each of these collectives could have its own Treasury that it manages via its collective origins. Of course, they would need to get funds into their Treasury, which would come from the main Treasury that is funded by DOT inflation and transaction fees.

This may sound similar to using the bounty mechanism, but these collectives, in my opinion, are superior due to their flexibility and transparency. They are flexible in that they can define multiple privilege levels (e.g. spending above X DOT could allow only higher-ranking members to vote). They are more transparent (and flexible) in their ability to change membership, which isn’t always possible (and is hardly transparent) with a multisig. Collectives are also initiated via governance, so their very existence and network mandate already has some blessing by DOT stakeholders.

So instead of the network voting on funding a local event, or a series of YouTube videos, or block explorer infrastructure, the collectives would make (probably large) proposals to the main Treasury to fund each collective’s Treasury. Then, someone who wants funding for e.g. a series of YouTube videos would make a proposal to e.g. the Polkadot Media collective, who would evaluate and award/reject the proposal.

This system would:

  1. Reduce the sheer number of referenda that are presented to all token holders, allowing them to focus more on larger ones (runtime upgrades, new auctions, funding a collective’s treasury);
  2. Maintain control over the collective (the Root origin can of course kill a collective if it’s not being used according to its mandate);
  3. Allow experts, elected by the network, to make decisions in the realm of their expertise.

What Makes a Treasury

So far, the Treasury has been a single account, on a single chain (Relay), holding a single asset (DOT) with some logic associated with how to spend that asset. I want to dive into those individual pieces a little bit.

  • Account: A single account with a single Treasury makes sense. But there’s no reason there can only be one account. There can be a “treasury-1” account, “treasury-2”, etc. That is, there can be a main Treasury account, and a separate Technical Fellowship Treasury account, and so on.
  • Chain: Just like with normal (key-based) accounts, the same account can exist on multiple chains. In the case of non-keyed accounts, each chain just needs some means of recognizing the authority to use the account.
  • Assets: The Relay Chain only deals in DOT, but other chains support many assets via a variety of pallets. If a Treasury has accounts on multiple chains, there’s no reason to prevent it from holding assets like any other account on whatever chain it is on.
  • Logic: The rules regarding budget and spending.

The logic part is primarily a governance feature; it makes sense for the logic to live alongside the origins that have the privilege to access the Treasury’s logic. Concretely, that’s wherever the associated collective (or in the main Treasury’s case, the public Referenda system) is. On a technical level, a single collective is just a set of pallets (ranked-collective, referenda, origins), and this would mean adding an instance of treasury to that set. Therefore, we would actually have multiple instances of the Treasury pallet on the Collectives chain.

From that singular location, each collective could manage its assets on multiple chains. And management here could extend beyond just approving or rejecting proposals; a collective could take an active role in allocating its Treasury to support its longer-term interests. For example, a Collective with a budget for events might want to convert some of its Treasury to a stablecoin to provide certainty in being able to cover its future costs.


This Treasury system would allow the network to push decision making into groups with expertise about the specific decisions. The decisions coming to public referenda would be proposals like, “fund the Ambassador Program for one year”, and reduce the number of small event funding proposals. Perhaps tips for PRs would go right to the Technical Fellowship Treasury.

It also gives each individual collective more flexibility in allocating its Treasury into a variety of assets, even on a variety of chains, to best meet its needs. And for proposers, it gives them a transparent group, that is accountable to the network, to which to go to defend the merits of their proposal.

Although we are early in a lot of the changes to the Treasury pallet to support a structure like this, this is the general direction I think we should go. I look forward to hearing what people think about this and any potential improvements.


Hi Joe,

Thank you for your insightful forum post. In response, I would like to introduce the Kusama OpenCommunity Governance project which addresses some of the challenges you have outlined.

  1. The Proposal Template and Guidelines is an important component of the OpenCommunity Governance Project, designed to guide proposal creators. Integrated into both the Kusama Wiki and Polkadot Treasury page, it standardizes proposal structure, ensuring comprehensive and clear submissions. Providing an outline of crucial sections - including introduction, project details, team, and budget - it promotes transparency, clarity, and improves informed community decision-making.

  2. Clearing Proposal Noise: One of the key issues you identified is the overwhelming number of proposals and the difficulty in providing sincere evaluations due to this noise. The OpenCommunity Governance project addresses this problem through our proposal audits. These audits are conducted by dedicated curators that go into each proposal detail, providing constructive feedback to proposers during the early development stages. The aim here is not to assess the quality of the proposal idea but to guide proposers in providing all the necessary and relevant information in a clear and concise manner. We believe that this process substantially improves the proposal clarity and comprehension, enabling the community to better understand the proposal and make informed voting decisions.

  3. In our Kusama OpenGov experience, we found that many proposers are often left in the dark regarding the community’s thoughts on their proposals. Our proposal auditing process ensures that proposers receive timely and critical feedback to refine their proposals, ensuring all relevant details are included and presented in an understandable manner.
    Report 1 Report 2 Report 3 Report 4

  4. Transparency: We have adopted a fully transparent approach. All our audits, including the process and results, are publicly available for review. We maintain a detailed progress tracker on Polkasembly, and all audit reports and other relevant documents are available on our Github repository.

  5. Decentralizing Audits: We are actively working towards further decentralizing the auditing process. We believe that multiple auditors from diverse backgrounds can provide a broader spectrum of feedback, and further reduce noise and refine proposals. We are actively onboarding new auditors, and I would like to extend an open invitation to interested community members.

  6. Funding Auditors: To maintain the decentralization ethos, we have moved the auditor funding process to the OpenGov tips. Each auditor needs to present their work to the community, which then approves the quality of the work through a tipping process. This model ensures that auditors are post-paid for their efforts, based on community approval.

  7. Multi-asset treasury with stablecoin reserve: In our experience with Kusama, impact by the native token price volatility, led to over 30% fluctuation between proposal submission and funding reception. When the price increases, proposals sometimes gain more funding than intended. Only a few proposers in this situation either return excess funds or compensate with extra work. A price drop can leave proposers underfunded, causing implementation issues, with many requesting additional funds. Introducing a multi-asset treasury, potentially including a stablecoin reserve, could guard against these issues. Such a measure would offer more predictable, stable funding, improving the reliability and overall quality of treasury-funded projects.

In conclusion, the OpenCommunity Governance project aims to improve proposal quality, facilitate feedback, maintain transparency, and foster decentralization. We are optimistic that these efforts will help mitigate many of the challenges that the community currently faces in the OpenGov process. We hope that this project, given its potential, can progress towards becoming a fully-fledged collective, with a diverse range of auditors on board.

Hey @CoinStudio thanks for the reply. I do think auditing plays an important part, or even just making sure proposals have a common format/information presented. I wouldn’t want a situation where people think they need to go via any one company/group to get a proposal passed in OpenGov.

I think an idea of collective-based treasuries actually expands the role of auditors. Collective-based treasuries is essentially delegation in a different form. Rather than individuals delegating based on spending amount (like OpenGov tracks), the entire network delegates based on category (e.g. “delegate to Ambassador Program for event proposals”).

This takes a lot of noise away from the public referendum tracks, but also places a lot of responsibility and power into these collectives (something my original post didn’t adequately address, in hindsight). I think it would make sense for many independent groups to audit the collectives on a regular basis and provide reports about what spending proposals they have passed. For example, audits should address things like, “Is the Parachain Technical Fellowship only funding infrastructure common to all parachains, or only for parachains that have members in the PTF?”

We hope that this project, given its potential, can progress towards becoming a fully-fledged collective, with a diverse range of auditors on board.

A collective to audit collectives, now we are getting somewhere :).


Hi Joe -

Collective based treasuries make a lot of sense for the reasons you outline.

However there are two very different ways to look at the context of these collectives - domain based or direction based.

Domain based collectives focus on a loosely defined area with KPIs also ROI to the treasury that is set, reported and assessed via their organisational structures.

Direction based collectives are tightly coupled together with a shared vision, cohesive set of values and focused on a common outcome, where all share in the success, but can flex independently within their own specific project.

The issue with domain based approaches is it inevitably leads to high coordination costs, siloing of intelligence / insights and ultimately wasted spend (see thread related to delegation to ‘experts’ here).

In general a lot of this simplifies when you start with a question of ‘what does the treasury want’?

From a qualitative perspective, it wants successful parachains.
From a quantitative perspective, there need to be some objective measures of success.

Without a way to assess ROI on treasury spends, there is way to steadily focus the strategy and tighten the loops of coordination across collectives.

This also needs to become a self-sustaining system (the treasury is a business after all) - and if we assume we have stablecoins to spend, then there needs to be income returning to the treasuries.

When viewed in this manner, the treasury ultimately requires fee based income to replenish its reserves.

Over time, we can assess the performance of directions, by their return to the treasury.

By splitting Kusama (and Polkadot treasuries) into vertically integrated directions, made up of aligned collectives each creating core ‘components’ within a cohesive operating system, we open the door more strategically aligned to a model that is likely to spit out a full stack propositition in the manner Apple have specialised that bridges both software and hardware… the consumer hardware being the core ‘products’.

You can see across crypto that all blockchains are coalescing around the same issues and insights - the same is true in the eventual stack… the rebranding to NearOS / UrbitOS, EthOS, and the return of blockchain phones etc.

It should be reassuring that the same stages are playing out - the question is just what the new ‘iPod’ will be for crypto…

This approach makes a lot of sense and the collectives parachain is the perfect place for groups of people with different skills, interests, etc. to gather, make decisions across the ecosystem and do useful things like manage their assets.

As Rich mentions there can be different kinds of collectives, but whether domain or direction based it’s hard to know beforehand what “system collectives” do we ultimately need. The current system is rigid and limiting, it requires the cumbersome process of runtime upgrades to allow for new collectives to be formed and there’s a limit on how many instances a given pallet can have, we should have a simpler dynamic way to create new collectives and let the community organically arrive to that set of system collectives(if we need such status).

So what I’m missing is a pallet(or group of pallets) that allows for people to form their own collectives(simple or ranked) in a permissionless way, similar to how assets pallet can be seen as the permissionless version of multiple instances of balances pallet, in other words we need an XCM enabled DAO factory in the collectives parachain which has tons of uses beyond the need of multiple treasuries for the core system.


For kusama we’re aiming to form collectives using the proxy / identity / multisig pallets on a parachain and hook that into the treasury/stablecoins, with direction led investment returning fees to the treasury.

In the initial instance, I think we can just run with optimistic orgs using time delays for mediating roles rather than adding more complex forms of collectives and their specific governance.

This would achieve your hopes for this:

We are planning for them all to have some overarching legal protections too.

It doesn’t seem viable for collectives to not have this in place - if they are to receive treasury funds.

Yes but that is completely a different topic than this post. I do think that a “system” collective should have to go through a “cumbersome” process like on-chain governance, otherwise how could it say it represents the “system”. But I do agree with you that collective formation should be easier and allow for more experimentation as a stepping stone for collectives to build strength and reputation.

The nice thing is, it doesn’t really complicate the Treasury idea in this post. A collective can define its own origins and spend from them, and as long as other chains recognize those origins over XCM, a single collective can hold many assets on many chains.

From the point of view of the main Treasury, it can of course award large tranches to the “system collectives”, but also to any other collective that makes a proposal with its origin-controlled accounts as beneficiary.

1 Like

in terms of the stablecoins required for these treasury deals/tranches, how do you imagine that happens? is this contingent on stateswap and DOT being an LP etc?

Side note - was Tether’s asset ID 1984 by happy accident or intentional?

Funding sub-treasuries with yearly (or just “big” budgets may lead to undesired side effects, as the influx to the main Treasury happens continuously.

What about deprecating the main treasury entirely and replacing it with a weighted set of treasuries. The influx (fees, inflation) would then just be split among treasuries on the fly. The relay chain governance could then simply adjust the weights and add/remove treasuries. This would also be easier to handle and understand. voters can just say “I want 10% of treasury funds to go to infrastructure projects, 20% to media, 20% to Events, 30% to tech innovations…aso.”

1 Like

I think funding something by default is a big precedent and should take a long track record of stakeholder approval of that group. And there should always be a “public” (main) Treasury that people can go to to get a proposal approved (basically an appeal if their proposal with the smaller collective gets rejected).

1 Like

at some point, performance of spend by collectives will become a requirement to ensure sustainability of funding for the main treasury and indeed for their own initiatives.

pushing spend into separate and arbitrary domains (infrastructure / media / events) muddies the waters (where do you draw the line). a different approach is to vertically integrate collectives and their initatives, allowing them to split their received funding to areas they believe will have the most long term impact - across R&D, infrastructure (parachain dev), application development, media, events etc.

the simplest way to assess relative performance is then through collectives returning fees to the treaasury.

if spend is in stablecoins, then impact can be clearly assessed via fiat fees returning to the treasury - creating a positive feedback loop and allowing more experimentation.

not everything needs to return fees wtihin a collective - but the whole should have a path there - or they are not sustainable businesses, and neither is the main treasury.

Ok @joe, given that decentralized futures is the future =) I think its time to put the Collectives chain to work in the way you outlined, in the hopes that we can plan out 2024 and organize work differently. Can we have a short “here’s what you need to do if you want to set up your { Polkadot Media, Core Data/Analytics Infra, RPC Infra, Anti-Scam … } Collective” from you?

I think those of us who have been around a while are quite capable of being members of a collective and using the Collectives Chain, we don’t want to turn “Therefore, we would actually have multiple instances of the Treasury pallet on the Collectives chain” into engineering work adding those instances. I suspect you and the substrate engs could do it in your collective sleep, but the rest of us just want to be users of those pallet instances.

As far as I can tell, the Polkadot Alliance was setup but are not actively doing motions and may as well be repurposed for the PTF to save a step? Just an idea.

If there are 5-10 Collectives that we should slot out for the end of Winter, can this be done in 1 or 2 shots in eg Dec and Feb or something like that?

Indeed you can: RFC-12.


I agree with one side of this and not the other.

The idea of sub-treasuries is great. It cuts noise - as a voter can filter by what they care about. It also allows us to set separate parameters for each subtreasury. For instance, different burn rates depending on how hot we want to run each treasury, one burning at 3%, another at 20%.

I also agree with @brenzi that the funds allocated to each subtreasury should be consistent and percentage based. It’s simple, and leans into the continuity that only a system as expressive as blockchain can provide. I understand your worries about setting too big a precedence but we could always just set the rate to 0%. In addition we could always send funds in discrete amounts if we collectively choose. It’s all around flexible and simple (less upkeep from voters on fund dispersal)

If a proposal is put up to the __ collective, are they the only ones who can vote on it or can everyone?

If the answer to the question above is yes, and we can’t vote alongside the collection. I stand firmly against creating collectives. It unnecessarily cuts the granularity with which the voting system can approximate the will of it’s people and it would lead to strong avenues of corruption (kick backs and the like). Not to mention is falls prey to the classic dictatorial assumption that one person (or a few) can better decide than the statistics of large numbers can.

Overall I ask… why not just subtreasuries? In isolation, it appears to solve all the issues diagnosed and falls prey to none of the pitfalls.

Yeah, I’ve come around to this idea of just allocating some percentage of inflation at mint time.

Yes, only members of a collective can vote on referenda that are put to that collective. It does not cut into the granularity of the voting system, it only provides a first-tier filter. The existence of collective-based treasuries doesn’t exclude or remove the existence of the main treasury. If the collective denies your funding request, and you think they are wrong, then you can still go to the main treasury and ask for a vote from all DOT holders.

Not sure how multi-asset support creates these “pitfalls” (that I disagree with). It just provides more flexibility. Multi-asset proposals (particularly stablecoins) is one of the most requested features. Different collectives have different objectives/mandates and will have different treasury allocation strategies. Forcing them to only hold DOT is the pitfall, not allowing multiple assets.

1 Like

My thought here is based off the idea that a voting system is an attempt to approximate it’s constituents aggregate will (let me know if that’s not agreeable). A republic is a crude, dull knifed, attempt at this, albeit I’ll concede that that’s the best tool humanity had for a while. The issue is that due to the small size of the council relative to it’s represented population, the council has to over generalize, and niche thoughts and ideas lose their representation. And this has very detrimental affects on the psyche of the governed people.

For me this is the beauty of a delegated democracy, it allows voting blocks with very specific ideas. And anyone can find one and feel good about the one they select.

I hear what you’re saying, and I agree we should kickstart the growth of what will be naturally occurring powerful voting entities, but fully taking away people’s right to vote isn’t the answer here.

The way I see it, we create collectives, they provide technical reports, signal their intention to vote, then vote. If people think they’re doing a good job, they’ll delegate. If not, a more naturally arising entity will appear. But yes those natural entities take time and we should definitely kickstart.

Yes, my apologies. I fully support multi asset treasuries. I was referring to the pitfalls of ‘only the collective can vote’ collectives. In my mind multi-asset subtreasuries and collectives are two separate ideas and I opt for just the first.

A sufficiently big population is, yes. But that being said, I think we align, but are just coming at this from different angles. I fully suspect that, given time, delegated democracy will position certain groups in power that vote on, and have expertise in, certain areas. It’s a much lower energy state.

If we kickstart the process by creating tech fellowship-like collectives, where they’re seen as a lighthouse but not the only possible one, I’ll stand behind it.

I’m just asking for a bit of faith in the powerful delegated democracy we’ve created. And a more focused direction on helping it evolve rather than turning to republics.

Brilliant – I started drafting a Decentralized Marketing Collective:

Is this what you had in mind?

At a very high level, yes. I did a quick skim and there some some places that Alliance and Ranked Collective functionality gets mixed up. Generally, we should be looking at Ranked Collective (e.g. Ranks 1-9 (configurable!) and not “Ally, Fellow, Founder”). I disagree with a few points/decisions in it but that’s beside the point for now :slight_smile: => Yes, it’s a start.

1 Like

Ok, thank you – here are some more questions I think you’re the best to answer:

  1. I’m stuck on how to use rank to BOTH
    (a) indicate knowledge/experience in “builders helping builders”
    (b) decide a reasonable/fair payment for monthly IMPACT
    Generally any kind of demotion is humiliatingly unhuman on dimension (a), but people should be able to take a summer vacation and get their rank back to modulate (b). What are your thoughts on this?

  2. For everyone studying the collectives code on Westend like me and want to get down into the code level understanding of Salaries for (1)(b), where should we look? How should someone who wants to prototype their collective play?

  3. Competition is good, but should there be competing collectives with similarish charters competing for OpenGov spend, e.g. 5 guild-like Collectives of Content Creators (competing for OpenGov spend analogous to Direct Spending Proposals with different quality/seeding), 5+ Polkadot Builder Collectives on different Polkadot technologies (ink! vs parachain vs dapps vs 2.0 CoreXYZ/DA vs … , competing for OpenGov spend)?

  4. Is there some technical limit on the number of Collectives guiding (3)? Any reason why we can’t have 50 collectives by the end of 2024 along “decentralized futures” lines?

  5. On the Ally/Level 1 Fellow distinction, assuming a collective has a large number of people (like hundreds to thousands), what your recommended exact mechanism for someone to enter a collective permissionlessly and for someone in the ranked collective to promote them?

I think most people thinking about collectives will want to know the same kinds of things, so you can speak generally – perhaps a AMA video call in December would be appropriate. Thank you in advance for your help!