I’ve noticed recently that there has been a lot of concern about the Kusama Treasury’s unsustainable spending rate. As such, I’ve made this post to start moving toward a more sustainable spending rate.
I wanted to quantify the issue so I decided to query the Treasury’s balance from block 16,000,000 to block 17,224,000.
I then ran a simple linear regression on the data to create a projection:
This projection estimates that, at the current spending rate, the Treasury will run out of KSM at block ~20,600,000 which will occur around mid to late November of 2023. Here’s some important figures from this projection:
- Average revenue per block = 0.0166 KSM
- Average spent per block = 0.1134 KSM
- Average net per block = -0.0968 KSM
I think most people in the ecosystem believe that this spending rate is unsustainable. However, I believe we all want to utilize the Treasury funds whenever it makes sense. So there has to be a balance between splurging and being overly frugal.
My recommendation: let’s double the runway by reconfiguring the spending tracks. Kusama is fast-paced, and the largest driving force behind the value of the Treasury is the price of KSM. If we can give the Treasury an extra 8 months of runway, then KSM will have more chances to spike up in price; at which point, we could potentially work quickly to convert some of the KSM into a stable asset - perhaps by striking a deal with Tether.
Here’s a comparison of our current trajectory (red) vs. my proposed trajectory (green):
If we manage to keep this trajectory, the Treasury will be depleted at block ~24,000,000 which will occur around early to mid July 2024 Some important figures of my proposed trajectory:
- Average spend per block = 0.0650 KSM
- Average spend per Treasury Period (every 6 days, assuming same revenue) = 5,615.965 KSM
I propose the following configuration of gov2 spending:
|Track Name||Max Deciding||Max Spend||Decision Period||Min Approval to Confirm|
|Budgeted Tipper||10||100 KSM||14 days||50%|
|Budgeted Spender||2||2,500 KSM||14 days||66%|
|Treasurer||1||No Limit||28 days||66%|
I also propose doing the following:
- Change this value in the runtime to
0to stop sending funds from the Treasury to the Society assuming
0doesn’t break the from_perthousand function.
- Change the other spending tracks to have a max spend of
1 * QUIDand rename them to include a
deprecated_medium_spender), effectively disabling them and preventing their accidental use.
- If the ecosystem hasn’t managed to convert a good chunk of the Treasury to a stable asset by 2024, we
balances.forceTransfer120k KSM from the Society to the Treasury via the
How will these changes stop unsustainable spending?
Decreasing the number of spending referenda that can be in a
deciding state at once hard caps the rate at which the Treasury can realistically spend funds. Typically, spending referenda with a decision period of 14 days takes 10 - 14 days to confirm (approximately 2 spend periods), so the max non-treasurer spending we can expect per spend period is 6,000 KSM, which is only ~7% more spending than my recommended trajectory. We reserve a more arduous Treasurer track to facilitate special case large spends.
What happens when multiple referenda are eligible to start deciding but there’s room for only one?
The referenda with the most AYE votes is moved to deciding. This is a good way to make sure that the most desired spends start deciding first when there’s a lot of spends in the queue.
Why are these changes needed?
Currently there is virtually no hard limit to how much can be spent in a spend period, and the hive mind of KSM holders is really bad at budgeting hence our current situation. If we stay on our current course I expect the Treasury will be depleted to a few tens of thousands of KSM sometime this coming Autumn, at which point, all spends will be rejected by token holders.
Nothing is more effective at stopping spending than restricting gov2’s bandwidth for spending.
How do we implement these changes?
Check out the Github branch I made compared to release-v0.9.40. Please feel free to make PRs with your suggestions.
While I’m no expert in devops or in how the
set.code extrinsic works on Kusama, changing the gov2 tracks in the code is pretty straight forward. However, I don’t think we can rely on Parity to merge these changes. I understand there are a few technical wizards in the community willing to help turn these changes into a runtime upgrade referendum on the
root track. Essentially, if we want to stop hemorrhaging funds from the Kusama Treasury, we need to do this ourselves. So we need:
- A whale for the
- A tech wizard to prepare the referendum
I’m open to suggestions and feedback regarding my changes on Github. If I screwed up the versioning or if I missed any necessary configurations, please let me know.
It’s time to reckon with the hard fact that the only way we can slow Treasury spending is by putting hard limits on the spending tracks.
Adam Clay Steeber