Collective-Based, Multi-Asset Treasuries

Governance
1

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.

Summary

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.

13 Likes
2

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.

3

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 :).

3 Likes
4

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…

5

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.

6

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.

7

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.

8

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?

9

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.”

10

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).

11

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.