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:
- 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).
- 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:
- 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);
- Maintain control over the collective (the Root origin can of course kill a collective if it’s not being used according to its mandate);
- 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.