This post will dump various ideas of mine on how we can improve the treasury system of Polkadot, both on and off chain.
As a Council member on Kusama and Polkadot since the genesis election, I have reviewed, accepted, and even denied many treasury spends, and throughout my experience, I have formed opinions on what I like, and what I think can be improved.
I will be very brief here, but I think it is worthwhile to convince those of you reading this post why a focus on Polkadot’s treasury system is important.
Ultimately, the Polkadot treasury is the one way that the Polkadot network can reach its hand out into the real world, and make things happen. The treasury is quite a unique feature of Polkadot compared to the last generation of chains.
If we can make sure that the treasury is easy to access for the Polkadot community, it will ensure that we will be able to fund and support growth and development of our ecosystem.
The Polkadot treasury can be simplified to two main parts:
- The Pot - The funds available to the treasury, funded by a portion of the fees on the network.
- Spending Logic - Ways for the treasury to transfer funds from the pot to end users.
The treasury is currently has 3 spending methods:
- Tips - Easy process to spend small amounts of treasury funds. Low overhead, relatively hard to abuse.
- Proposals - A more laborious process to spend large amounts of treasury funds immediately and to a specific account.
- Bounties - The most complex treasury process, which involves multiple actors to coordinate the spending of funds for projects which are agreed upon in advance, but the recipient of the funds may not be known at the time of creation. (this is maybe a bad summary, but yeah, you can read more about it.)
Improving Proposals (Treasury V2)
Proposals were designed to be very simple, but I think that some additional complexity can greatly improve the end to end experience of creating and approving large treasury spends.
Currently, if a team opens a proposal for a treasury spend, if accepted, all of those funds are transferred to the team immediately. This is true for small projects, but also large, multi-year projects.
I have been concerned in the past that unknown teams come to the treasury and ask for a lot of money, for a huge project, and we have no idea how to evaluate if the team will actually deliver that project. We may ask the team to reduce the size of their ask, but then a team may be worried that the treasury will not commit to continuing the project once they get started.
Ultimately the proposal system right now is not actually good for allocating funds for really large projects.
I suggest we introduce some simple phases to each treasury proposal, and have teams ask to allocate funds to each specific phase:
- Starting Spend
- Reoccurring Spend
- Final Spend
For the sake of example, I will take the role of a team lead who wants to ask for 100,000 DOT to build a new mobile wallet for Polkadot, and then use this role in the sections below.
When a team asks for treasury funds, usually they will need some cash up front to get started with the project. This is what the Starting Spend can be used for.
Proposals today are basically ALL starting spend. Without having done any work, I would have asked for 100,000 DOT up front, and basically it would have been very hard to get my proposal approved.
In this case, I know I only need 10,000 DOT to get started on this project, and so I only ask for that amount as my Starting spend.
The treasury has less risk at loosing funds to people that do not deliver, and the proposer can still get the up-front capital they need to begin execution of their project.
Building a large project may take multiple months or even years. The reoccurring spend is the amount of funds the proposer will need on some reoccurring time scale to keep the project going.
For my example, I expect the project to take around 10 months, and I expect my monthly costs to amount to 5,000 DOT.
In this case, this reoccurring spend logic will be baked into the proposal, and if approved, every month, I can pull from the treasury funds my 5,000 DOT.
In order to get my next months funds, I must also submit a proof of the work done in the last month. This proof does not need to (and cannot really) be verified on chain. Instead, the team puts the data out there, and any user in the Polkadot ecosystem can read the update, and check for themselves the work being done is high quality and worthy of the monthly payments. As you can probably guess, later down we will describe a process where the updates are NOT high quality, and the governance system of Polakdot can end a proposal early, returning any unspent funds back to the treasury.
But generally, this process should be minimal and efficient for the proposing teams. Just provide proof that you have been doing what you said you would, and you can automatically pull out the funds you need to keep building month to month.
Finally, at the end of the project, the development team can potentially get a reward for their hard work done. It could be that the funds requested above were just enough to keep them afloat, but we should reward good contributors to our ecosystem with a profit for their work and hard time.
In this case, I have spent a total of 60,000 DOT for the 10 months of work and the starting spend, and thus my final reward will be 40,000 DOT for a job well done.
This will be a slightly delayed payment, where the proposer can again submit evidence that their work was completed successfully, and the public is given a period of time to review that work, and verify that the initial proposal was indeed satisfied by the work done.
If no one objects to the final spend, the my imaginary team walks away with 40,000 DOT profit on a job well done.
How Phases Effect Proposals
Now lets look at other ways this proposal could have gone, when a team asks for DOT.
Only Ask for Starting Spend
This is exactly how we treat proposals today, and should be backwards compatible if there are UI/UX already developed to optimize this.
Only Ask for Reoccurring Spend
In this scenario, I do not ask for any starting spend or final spend reward to execute my proposal. Instead, I simply ask that over the course of 10 months, I get a 10,000 DOT payment each month for the work done.
This might make sense for projects where the treasury is already comfortable with the delivery of a team, and does not feel the need to keep the “DOT profits” from the team until the final spend.
This looks very similar to “child bounties” which exist today on Polkadot.
Only Starting Spend and Ending Spend
This might make sense for projects which are short in their timeline, thus the overhead of doing regular updates for the reoccurring spend would rather just be moved to the final spend.
Only Ending Spend
If implemented cleverly, this can look very similar to the regular bounties system which exists today for the treasury, and potentially could replace it.
As you can see, based on the amount of money, the kind of proposal, the trust we have in the proposer, etc… these phases can be tuned to spend the same amount of DOT, but over a different schedule, which allows the public to audit and keep track of the work done.
Additionally, we could potentially simplify UI/UX by combining the behaviors of bounties and proposals under a single unified process.
Other Ideas for Phases
There are a million other features and nice to haves which can be added to a phase based treasury spend, and will probably need to be in the final implementation:
- Allowing post-approval adjustments of things like reoccurring spend and final spend amount.
- Giving only a fraction of the Final Spend if the final product is “okay”, but not great.
- Ways to extend the reoccurring spend time period
- Ways to pause reoccurring spend, to allow for closer public audit
- Ways to update where the spends go
- Users placing bonds against asking for funds or stopping a spend from happening
In the example above, we talked about a 10 month project, which is asking for 100,000 DOT. But practically speaking, most of us still live in a world where we need fiat to live and pay people for work.
It could be in a bull market, the 100,000 DOT over 10 months could grow a lot in USD value. However, in bear markets, it could be that your estimated monthly payments are not actually enough to keep the project going.
One way or another, I feel the treasury needs to bring some sense of a stable coin to the system.
- Have the Polkadot treasury hold and distribute a stable coin.
- Record information about the expected DOT value on chain when a proposal is proposed and passed.
- Use ideas like “gilt”.
- other ideas?
This is more of an offchain recommendation, but I do not find that any UIs today do a good job at representing the history of users who ask for funding from the treasury.
Similarly I don’t think we do a good job at making recommendations for new applicants on the size of proposals that the treasury would be comfortable to give out on a first try.
I don’t have any specific ideas here, just rough ideas.
For example, imagine the following table:
|# of Proposals Successfully Delivered||$ of Funds for Next Proposal|
I would when users as for a proposal, I should not need to hunt for their history to see if they have delivered on time, that they are asking for an amount appropriate to what they have delivered in the past, etc… It should be a part of the process that this information is presented to everyone, that users will want to build up their reputation, and that they know what is reasonable to get their proposal approved.
Follow Up + Impact
This is one of the problems that I think will be solved mostly by Proposal Phases and Reputation, but I want to call it out here as a weak point of the current treasury system.
I have reviewed and approved many different proposals on both the Polkadot and Kusama, however, I find it very hard to track or follow the specific impact of those treasury spends.
I think there is a lot of meta things we can do to improve this kind of stuff.
- Add a logo at the top/bottom of applications and websites with things like “Funded by the Polkadot Treasury”
- At certain funding amounts, expect / require teams to create videos highlighting their work.
- Tie those videos on-chain or off-chain to the proposals themselves, and the reputation of the proposers.
- Require teams to describe expected impact on the ecosystem, and measure those goals.
At the moment, there is no metadata about treasury spends on-chain. If you want to learn what a proposal, bounty, or tip is trying to do, you need to visit a third party website like Polkassembly to get that data. (tips have a small amount of data, but not that good)
I think we should look to add decentralized forms of the treasury spend metadata on-chain. So, adding some new fields to store and update some IPFS hash, which then links to the actual proposal metadata. This would allow anyone to build their own version of a treasury application, and allow us to iterate much more quickly on providing high quality user experiences.
Ideally, we could do the same thing here with the conversation around treasury spends too, but I am not sure what exactly that would look like.
I think the general consensus is that the treasury does not spend enough of its funds, but I have still yet to find a place which really paints a clear picture of what is happening with the treasury funds at a high level:
- Which team(s) has been allocated the most overall funds?
- Which teams have had the most proposals approved?
- What was the most expensive proposal approved?
- What is the ratio of approved to denied proposals?
- What percentage of the treasury is spent between spending periods?
- What categories have had the most treasury spending?
- Block Explorers
- RPC Nodes
- How much is being burnt from the treasury, and what would that look like at different spending amounts?
Once we know at a high level what is happening with the treasury, we can start to give direction and planning to it too. While I am sure that many people are very excited about funding defi projects, my guess is these kinds of proposals are over-represented compared to privacy and identity projects, which is probably a much more compelling use case of Polkadot.
I could probably keep going on, but let’s start here, and see what other improvements you all have in mind for the treasury, and what you think about my comments above.