Kusama Treasury Analysis & Reconfiguration

[asteeber]

Hello everyone,

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.

Analysis

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

Policy Recommendation

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 0 to stop sending funds from the Treasury to the Society assuming 0 doesn’t break the from_perthousand function.
• Change the other spending tracks to have a max spend of 1 * QUID and rename them to include a deprecated indicator (e.g. 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.forceTransfer 120k KSM from the Society to the Treasury via the root track.

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 root decision deposit
• 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.

TL;DR

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.

Respectfully,

Adam Clay Steeber

[ThomasR]

Lovely investigation !
Something has to be i agree.

Whether if it’s by changing the parameters or be more realistic and choose to spend the Treasury on the dev side only.

Don’t forget that currently the Treasury spends a looooooooooot of KSM into the events. So at a given, we’ll need to chosse between devs and events.

[RTTI-5220]

Nice work, Adam - there are some very sensible options there that I think could help a lot. If I understand correctly on the curves: the proposal is to deprecate most of them and leave budgeted tipper, budgeted spender and treasurer as managing curves for treasury (and with some changes on the curves themselves).

I think changing the value to 0 to the society is something we should do: although take into account this only happens when there is a burned portion of treasury (given the rate of spending of the treasury with OpenGov not sure if this has happened: I should check historical numbers).

Transferring part of the society pot to the treasury might be sensible, the funds are there as a historical legacy and the members cannot use the funds for other than the society game so I think a transfer can happen, leaving a portion for the society to function - I dont think the collective needs much to incentivise participation. However, I fail to see where you see 120k KSM?

[CoinStudio]

Hello everyone,

The analysis Adam presented here is excellent and highlights the need to address the unsustainable spending rate of the Kusama Treasury. I appreciate the effort put into analyzing the issue and proposing changes to improve the situation.

I really appreciate the following statement:

Nothing is more effective at stopping spending than restricting gov2’s bandwidth for spending.

I propose smaller changes compared to the Adam solution to effectively control spending. This approach would not only help manage spending more effectively by restricting gov2’s bandwidth for spending but also encourage more thoughtful consideration of proposals, allowing the best ones to be recognized and prioritized.

GitHub proposed changes to tracks.rs

These changes are only reducing the number of tracks in the decision period and leaving all other configurations unchanged:

name: "small_tipper",
			max_deciding: 200,
			max_deciding: 20,

name: "big_tipper",
			max_deciding: 100,
			max_deciding: 10,

name: "small_spender",
			max_deciding: 50,
			max_deciding: 10,

name: "medium_spender",
			max_deciding: 50,
			max_deciding: 2,

name: "big_spender",
			max_deciding: 50,
			max_deciding: 1,

By reducing the high spending budget and leaving smaller budget tracks more open, projects are encouraged to pursue smaller, milestone-driven, and delivery-based proposals where each subsequent round of funding would be contingent upon the successful completion and deliverables of the previous milestone. This ensures a more focused and efficient use of funds, ensuring that resources are allocated towards achieving specific, tangible outcomes within the ecosystem.

[tom.stakeplus]

Currently, treasury revenue is in a deficit of 400 KSM per month. Revenue is negative. If we implement tighter restrictions and controls on the tracks, it will only result in more KSM being burned than spent.

Everyone keeps focusing on the spend ignoring the fact that revenue is down almost 80% and what revenue is left isn’t enough to outpace even the burn. Even if we don’t approve any additional proposals, treasury will still be drained at a rate of >400KSM per month.

I think we need treasury savings accounts. Lock those funds away to force the community into budget management a little quicker. We can lock away 300,000 KSM, at current staking rates this would return around 2,600 KSM a month and also reduce the burn (which will reduce society income). This leaves us with 15,000 KSM + whatever is in society, and revenue around 4,600 KSM/month total. We would need to learn to live off the 15,000 KSM and the 4,600 KSM/month revenue.

IIUC, it’s possible to do this currently in the existing runtime. This would allow us to hide a huge chunk of the treasury for a rainy day while generating additional revenue, and reducing the burn. No need to wait for merges.

Make Revenue Positive Again

[RTTI-5220]

this is also an interesting idea: wondering how we would stake this and how do we control nominations @tom.stakeplus? and how do you set this up in the current runtime?

[tom.stakeplus]

Honestly, I have no idea. This was first brought up by me during the conversations regarding the IBP when I was proposing using staked funds to fund the program perpetually. It wasn’t an immediate concern at the time but it was Will P. who mentioned that this is possible. I reached out to him recently to find out more details about how exactly this would be done. I’ll update once I know, or maybe Will P. or someone else can discuss the technical aspects of implementing treasury nominations on nomination pools or how treasury staking accounts would be operated.

Regarding how to pick validators, my immediate thought was to have trusted groups from the community operate the nomination pools. IIUC, Paradox is already operating a number of nomination accounts using pure proxies for the 1KV, I don’t really see this as being any different. We could use those funds to nominate 1KV members according to some guidelines or allow the nomination operators the freedom to decide who they believe make valued members of the community.

The IBP members could operate a multi-sig to control one nomination pool or treasury staking account and nominate ourselves into the active set. It would provide a little extra revenue to the members (more time in the active set) and remove up to 24 contenders from the 1KV, allowing other 1KV members to be in the active set more often.

ChaosDAO would be a good choice to operate another multi-sig, allow them to select who they think are the best validators to support long term.

There shouldn’t be any risk to decentralization here, even if 1 person were to control every KSM in the treasury for nominations, the number of nodes that they could get into the active set would be somewhere between the number P2P.org has and the number ZugCapital has. Somewhere around 40-60 nodes total or 4-6% of the total active set.

[rich]

Nice work Adam, its great this topic is finally being actively debated.

Summary from your points:

• Current spending is unsustainable
• Therefore slow spending through hardcoded limits rather than social
• Shift into stable assets (how this might be done is an interesting secondary question)
• Stop / Repatriate KSM from Society per @RTTI-5220

Then @CoinStudio goes further:

• projects pursue smaller, milestone and delivery based proposals

And finally @tom.stakeplus presses on a different aspect of the treasury

• Revenue, aka how does the network grow its existing pot via staking and spend the proceeds.

There is a final point which hasn’t been discussed enough but plays to all of the above points which are all really sticking plasters on a deeper set of problems:

• What kind of ROI should the treasury be looking for with its funding?
• How should we value treasury spending?
• How do we attribute that value - e.g. how do we make the subjective, more objective?

This then leads onto a much bigger question - what is the treasury for?

It will really help to pause and consider this - it should be fairly uncontentious to say that the treasury exists to ensure the survival of the network.

Ultimately the largest demand drivers of KSM(or DOT) are parachains - it was their crowdloan campaigns that were the marketing of the network, and therefore the mechanism that drove the token price and created the treasury in the first place.

With parachains mostly now purchasing slots for 97%+ less than peak, this same demand driver doesn’t exist. Ultimately the security-as-a-service proposition and economic model is bound to the demand for slots and therefore the demand for KSM that is locked up.

All treasury funded marketing to date has been focused on driving general awareness, without a potent mechanism such as crowdloan behind the media. The hope has been that this ultimately translates into new and successful parachains. That’s the end goal of it all if you strip it all back.

Either this model needs reigniting - by the treasury, or there needs to be an entirely new investment model that backfills the gap and provides some new narrative for why KSM has value.

[olanod]

Hi Adam, nice to see the proposal formalized I think it makes total sense to introduce some form of budgeting to our treasury spending, no government or enterprise would last long without any control over how their finite resources are used. Limiting the bandwidth of our spends as your proposal suggests is crucial and needs to happen, but something I would consider adding already that is more important when budgeting is to accompany the spending with goals/purpose/direction/vision, with some mechanism to allocate resources where they are needed the most. Imagine you are planning a trip to Europe and decide to limit it to 5K, the limit would be pointless if you use most of your budget going in first class and don’t leave anything to even afford the cheapest hostels or go to any restaurant.

One way I would suggest we can adjust the proposal that would enable this goals based spending is by defining treasury spend tracks not based on amounts but on the category of the spend(e.g. media, events, marketing, wallets, core tech, r&d, etc.), the limits on each track should add up to match the bandwidth you proposed, we can start with a balanced division or discuss a bit more to have a general sense of what topics could have more priority based on our short term needs(e.g. do we focus on positive revenue?), it doesn’t have to be perfect but just a starting point that would be adjusted over time.
As side note, I know bounties serve a similar purpose but it’s just my personal opinion that OpenGov and its delegation system should deprecate them or we should evolve them to overcome the centralization around curators(e.g. with curated payments). Another advantage of separating tracks by domain is that delegation per track starts to actually make sense as domain experts can finally campaign for specific tracks making the most use of their expertise, a marketing expert can ask for delegations to the marketing related track(s) instead of pretending to understand a complex big spender proposal about a core technology.

If people like the idea, a couple of minor non very functional additions I would introduce with this change that builds on this notion of having goals and clear objectives similar to how companies define OKRs is to first include a scheduled remark, say in 2500000 blocks(~6months), that states our main goal for the semester and also acts as reminder to review our governance parameters and adjust them(with a new objective remark). The second change would be to add a new goal property to the TrackInfo struct that shortly describes the track but most importantly states the track’s current focus or priority, e.g. a BigEventSpender with goal: "Only sunny places with canaries", suggests voters to reject igloo parties organized by penguins

If any of this make sense I’d be happy to formalize the changes and help in any way necessary to bring this referendum on-chain, perhaps with the help of other non-parity/non-big-funded-team fellowship members whom also live off OpenGov and the treasury(@sam?). I simply think a long due milestone we need to overcome in the spirit of decentralization is for the community to propose its first runtime upgrade independent of Parity’s usual workflow. This proposal with low technical complexity and with very little risk to brick the chain can be the perfect test case.

P.S. Out of curiosity, would the linear regression look the same if counting not from block 16,000,000 but around 15,500,000 which is about the time OpenGov was introduced?

[sourabhniyogi]

@olanod

goals based spending is by defining treasury spend tracks not based on amounts but on the category of the spend(e.g. media, events, marketing, wallets, core tech, r&d, etc.), the limits on each track should add up to match the bandwidth you proposed, we can start with a balanced division or discuss a bit more to have a general sense of what topics could have more priority based on our short term needs(e.g. do we focus on positive revenue?), it doesn’t have to be perfect but just a starting point that would be adjusted over time.

Great idea – if possible, I would suggest tying this idea to @joepetrowski 's advice in setting up collectives with their own budgets:

1. create 4-10 collectives that map onto categories of existing proposals (e.g. “ux”, “events”, “indexing”, “bridges”, “tools”, “education” …). I also recommend a “r&d” one to allow diverse innovation that doesn’t quite fit into an existing TrackInfo
2. have the community approve quarterly (semesterly?) budgets each collective responsibly, cognizant of the revenue + income.
3. each collective spends their budget on their charter (e.g. events), and should be expected to aggregate reports to have budgets either stay the same, increase or decrease each quarter (semester).
4. collectives should devise mechanisms for spend recipients to be competitive with each other for some % of the collective’s spend (see how Moonbeam does it here). I believe around 30% should be reserved for newcomers, otherwise you end up with a stagnant military-industrial complex funding the same 3-5 beneficiaries and this community is supposed to be about innovation.

This ‘indirect democracy’ type solution has the community voting for budgets on tracks rather than proposals. In my country, I would like it to spend less on the military track and more on the education track, but I myself have little idea on how new military/education dollars should be spent on specific proposals – I’d like to leave it up to the military collective and education collective, who work with the budget that they are given.

In the same way, I may believe that the UX Tracks + Bridges Tracks should get more DOT or KSM at the expense of the Indexing Track. If the UX Collective rationally allocates their funds to Dotswap UIs at the expense of Wallet teams, and the Bridge Collective makes rational decisions about how to allocate between Snowfork, Centrifuge/Axelar, Darwinia, T3rn proposals (say) – but always within a certain budget, then you win sustainability in the aggregate (with budget controls) with rational decision making shifted to the individual collectives. You would expect the Bridge Collective members to be smart enough to know how evaluate bridge security solutions, the UX Collective to know how important different UIs are and seeing how they fit together, similarly for other collectives. Then, both the community and the N Collectives switch from lots of “yeah, this seems (un)reasonable, I guess… Aye! (nay)” one-off decisions to a smaller number of “ok, we have to allocate more here and less there because ___” both at the community level and within the collectives.

The expectation is that people would be making smaller numbers of more important decisions with this change. At the community level, people would be expected to have intuitions about how to shift budgets between tracks rather than proposals; At the collective level, people would be expected to to have super informed judgements about how to allocate finite budgets to specific proposals.

[rich]

Question re your points @olanod @sourabhniyogi related to the ‘domains / collectives’ question.

@sourabhniyogi

create 4-10 collectives that map onto categories of existing proposals (e.g. “ux”, “events”, “indexing”, “bridges”, “tools”, “education” …). I also recommend a “r&d” one to allow diverse innovation that doesn’t quite fit into an existing TrackInfo

If we begin with outcomes, rather than activity, do we not push towards more meritocratic and objective ways to value spend - ultimately we want to get to a place where anyone can arrive - without rep, or history and prove some effective new approach, and not have to jump through hoops pleasing the incumbents (whoever they are at that time).

imo this is what R&D funding is for per the above note - it’s for kickstarting this journey to impact.

This is what true decentralisation looks like - else we’re always pushing the can down the road.

New ideas necessarily look stupid, weird or don’t make sense to the incumbents - or they would be doing them. The exciting thing about Kusama’s potential innovation cycles is we can design for this cycle to keep turning, without creating the sort of military/media industrial complex you note Sourabh.

It makes most sense from a network scaling perspective for voters to back directions that they believe will have the most impact over time.

There can be reputational and even economic upside for those who back the directions that prove objectively to be the most successful over time (this is how we get to prediction markets/futurarchy)

Ultimately this is then driving the collective intelligence of voters towards a more educated investment mindset.

There are still many sacred cows we need to slay - if we continue to coordinate groups based on delivery of an ‘event’, or ‘a podcast’, or a ‘wallet’ (infrastructure), and those initiatives are all delivered successfully via milestones, but end up having no practical impact on the network, then is it not more wasted spend?

There is clearly a continuum here, but we should aim for collectives to be assessed directly on their network impact over time, with associated reputational upside and remuneration.

There are naturally people/projects who have benefitted from existing spending processes - there will inevitably be tensions as the impact of that work is reviewed, but this also needs to be seen as course correction - talent should be retained, ideas that don’t serve, should be thrown out.

This is not an easy process to push through - it will be delicate, people will take things personally, but there is wisdom in the adage, cut once, cut deep when it comes to organisational change.

This all roots back to a very simple question: what is the treasury for?

[GabrielJ]

This forum post is awesome @asteeber. Thanks for putting it together.

There have been a lot of separate discussions regarding treasury improvements lately and it is nice to see it all come together here and concrete solutions being put forward.

The last 2 comments above this one by @sourabhniyogi and @rich absolutely hit the nail on the head imo.

What do technical solution for the collective-based approach as well as meritocratic spends look like and how do we implement them (along with other changes proposed here)?

As @olanod mentioned it would be amazing for the community to come together to propose its first runtime update independent of Parity’s usual workflow!

Exciting times!

[ChrawnnaCorp]

You’re speaking my language ser…

from last week:

OpenGov Track Experiments - Delegating to Experts

Delegating power to those with a reputation of skill or expertise in a specific domain is a natural social phenomenon – keeping watch, baking bread, governing… we all benefit when we delegate responsibilities to those who do them best (and taking them away when they fail or lose touch). Delegation was wisely added as a feature in Polkadot’s governance system. In OpenGov, however, delegation is tied to Tracks – we can delegate our voting power to others for specific tracks only. This works wel…

[sourabhniyogi]

@GabrielJ

What do technical solution for the collective-based approach as well as meritocratic spends look like and how do we implement them (along with other changes proposed here)?

I would love to see both the community and the collectives both using the same mechanism that solves a lot of the problems identified – for me a great candidate is Gitcoin’s Quadratic Funding, where QF does seem to address the committee+innovation stagnation/whale domination/hoop pleasing/… problems. But, we need to combine QF with collectives.

My test case for Quadratic Funding (QF, or anything else) is this:

• an actual proposal P that 80% of the community would not understand (e.g. literally, a Quadratic Funding pallet) requesting 3K-10K KSM
• however, P would be considered in one or more track collectives who each have 10K KSM quarterly budgets
• each of Collectives (plural) is composed of two different kinds of people: Brahmin Whales and Untouchable Shrimps – where the Brahmin Whales put N% of their voting power behind the existing Governance Tools but Untouchable Shrimps put 100% of their voting power behind P.

Question: How is it possible with QF that a 20% minority of Untouchable Shrimps in the collectives could put 100% their voting power behind P and get P funded @ 1K-10K KSM out of the 10K KSM budget?

Claim: Someone can generate a precise answer to this question this using past Kusama governance data, using actual participation numbers from Brahmin Whales (defined in terms of KSM) and Untouchable Shrimps inside different kinds of collective make ups, and use this to guide a QF pallet design (or something else that is better) that ensures P gets funded at 1K-10K KSM for some realistic value of N.

In my country, we have a Green Party and Libertarian Party that can never make a real impact against the dominant parties (Democrats and Republicans) – literally every proposal is suffocated well before or at the 50/50 mark. QF seems to be able to be able to give the Green Party’s climate change agenda (or the Libertarian Party’s military funding reduction agenda) through collectives, but if you have only ONE collective, that collective would be stuffed by Brahmin Whales with the equivalent of Big Oil / … defeating the Green Party agenda (or the equivalent of the warmongers of the military industrial complex defeating the Libertarian agenda). And if you have multiple collectives, maybe those same entities would stuff multiple collectives – where QF doesn’t work if Brahmin Whales outmaneuver the agenda of the Untouchable Shrimps by increasing N to 100, right? But it works if those same whales have to split their vote into lots of different places. Thus, my test case + question.

The community’s default behavior will be to stuff every collective with Brahmin Whales (with PhDs, experience) – they got us here, after all, right? But the same community needs to support new ideas, and recognize that new ideas/pallets/… have to replace the old ideas/pallets/… Next generation QFs needs to bring in the concept of competing collectives and have a hedge against the excessive power of Brahmin Whales that historically dominate democracies. Then, potentially, the equivalent of the Green+Libertarian Party can actually get somewhere by having their own collectives maybe composed of Untouchable Shrimps. Then the community who actually sees the excessive power of Brahmin Whales as getting in the way of Untouchable Shrimp agenda would taking their QF voting power and reassign it to these “fringe” parties.

Having multiple collectives seems overly complicated, but we can be amazed that a bunch of young people in the late 1700s already thought about these exact “how to represent the minority” problems pretty deeply, from multi party systems right down to a disgusting number “3/5” to model the Untouchable Shrimps, super cognizant of the power of Brahmin Whales. While I use the caste system metaphor pejoratively, some Whales will support the Shrimp agenda often enough that it can work. If any blockchain community can do it, its gotta to be this one –

If real governments can put Ranked-choice voting in front of people, I believe QF could as well, to innovate past the 50/50 mark, and show the world how the Green + Libertarian Parties of the world can actually make progress despite being in the minority. The Kusama treasury can go to 0, but for whoever is building this, if it can contribute to future democracy well outside here (for Polkadot but really, any governance system), its a great ROI.

[Csaint02]

This is an outstanding post here Adam. I caught wind of this from your twitter post today and decided to see what was going on in the forum it appears that we are discussing a few different topics here:

1. Avenues of increasing revenue
2. How to effectively disperse treasury funds
3. On Chain Treasury Management

Avenues of increasing revenue

I think staking society funds is an outstanding idea and if 120K KSM is indeed there, then that makes a ton of sense to force transfer and begin making some revenue for the treasury. Staking a portion of the KSM currently in the pot is also another good consideration. I have a few thoughts on the current treasury revenue that will also bridge into the last point on broader treasury management

• Purely staking a certain percentage of the current treasury and choosing nodes as Adam has selected above
• Reserving this percentage of network KSM for new nodes onboarding into the network. Much like the 1K validator program rotates funds between new validators - however it will be more KSM and could also be a source to increase decentralization and stake for a longer period of time than the current program
• Open to other ideas on selecting nodes or onboarding new nodes to increase decentralization and inclusion of community nodes

How to effectively disperse funds

This is actively being worked on by multiple teams in multiple different ways. No doubt there will be growing pains, but things we can build from as we all see this as a significant problem. I also suggest that for many of the infrastructure plays or even some of the largest spends could be retroactively rewarded based on end delivery; we should consider a RPGF model much like Optimism has done within its ecosystem. Please read this post here to learn more. This is different from a milestone based approach. Incentives are not expected, but possible. Imo this can drive higher quality than setting your own milestones

RetroPGF Round 2 Results

On Chain Treasury Managment

I think for this, HydraDX/Basilisk is an outstanding option to trustlessly provide liquidity and recieve trading fees that can be transferred right back into the treasury. With their DCA options and OTC trader features going live soon, it can be a full suite for on-chain treasury management and uniquely DotSama (yes I said the D word).

Again, great post and I like the idea of focusing on increasing revenue as well

[jakerumbles]

I’m curious how the Kusama treasury drain will be affected once Polkadot gets gov2. There’s exponentially more funds in there and I would think many people would start submitting proposals on Polkadot once gov2 is added to the runtime.

[asteeber]

Lots of great discussion going around this topic! I think we’re all leaning toward restricting the bandwidth of the spending tracks in a runtime upgrade.

One thing @RTTI-5220 asked me in the Polkassembly post on the Kusama Treasury Staking Configuration is if I’m in contact with the runtime devs to see if these changes can be merged without breaking the runtime. To answer that, I really don’t have a foot-in with Parity or the Fellowship and nearly every PR I make on Github receives no technical feedback on whether it will work or not.

I don’t think we can rely on Parity to make any such changes. Rather, we should try to piggyback on a Parity runtime release. For example, once the Fellowship whitelists the runtime upgrade to 9410 we fork that release, include the track reconfiguration, prepare the runtime using srtools, then test the runtime upgrade with Chopsticks or something else. Then we can submit a system.setCode referendum in the root track and provide the receipts in the Polkassembly post.

It’s going to be a lot like jumping onto a moving train - Parity and the Fellowship will likely not accommodate these “trivial” changes in the spending tracks and will not wait for us to prepare a runtime before they release 9420. Since the Fellowship will likely prepare the next runtime upgrade very soon, we either do this ASAP or wait until 9420.

Track Change Recommendations

I’ve noticed a few ideas around how we change the tracks, ranging from drastic changes to modest changes. I’ll try to capture them all here (in order from less drastic to more):

Do nothing (most likely scenerio IMO)

Honestly, I don’t think the ecosystem will ever agree on how to restrict spending, so the Treasury will be drained within a year. Oh well!

Not to say we shouldn’t try! But this is how we should set our expectations to avoid giving ourselves false hope.

Coinstudio - restrict existing tracks

name: "small_tipper",
	max_deciding: 20,

name: "big_tipper",
	max_deciding: 10,

name: "small_spender",
	max_deciding: 10,

name: "medium_spender",
	max_deciding: 2,

name: "big_spender",
	max_deciding: 1,

This option simply decreases the existing tracks’ max_deciding numbers and changes nothing else. I think this would be the easiest to sell the ecosystem on.

ChrawnnaCorp - add event_spender track

name: "event_spender",
	max_deciding: 50,
	decision_deposit: 400 * QUID,
	prepare_period: 4 * HOURS,
	decision_period: 14 * DAYS,
	confirm_period: 48 * HOURS,
	min_enactment_period: 24 * HOURS,
	spend_limit: 7_777 * UNITS

This is a babystep into the domain-specific track configuration by adding an event spender track.

My recommendation - deprecate current tracks and create far more restrictive general spending tracks and stop Treasury burning

pub const Burn: Permill = Permill::from_perthousand(0);

name: "budgeted_tipper",
	max_deciding: 10,
	decision_deposit: 400 * QUID,
	prepare_period: 4 * HOURS,
	decision_period: 14 * DAYS,
	confirm_period: 24 * HOURS,
	min_enactment_period: 24 * HOURS,
	min_approval: 50%
	max_spend: 100 * UNITS
name: "budgeted_spender",
	max_deciding: 2,
	decision_deposit: 400 * QUID,
	prepare_period: 4 * HOURS,
	decision_period: 14 * DAYS,
	confirm_period: 24 * HOURS,
	min_enactment_period: 24 * HOURS,
	min_approval: 66%
	max_spend: 2_500 * UNITS
name: "treasurer",
	max_deciding: 1,
	decision_deposit: 1 * GRAND,
	prepare_period: 2 * HOURS,
	decision_period: 28 * DAYS,
	confirm_period: 48 * HOURS,
	min_enactment_period: 24 * HOURS,
	min_approval: 66%

These are some pretty drastic changes and will restrict spending more than anything else. However, I don’t think this would pass a vote.

Include a robust selection of domain-specific spending tracks

I can’t really provide the exact details of what this would look like, but essentially we work out how to configure tracks for Media, Events, Hackathons, UI, Infrastructure, Governance, Philanthropy, Business Development, R&D, Marketing, Bridge, Education, Indexing, Tools, etc. To me, this will be very difficult to deliberate on. What topics do we need? How specific/ broad do they need to be? What should the spending limits for each one be? How can we back up these decisions?

I think it would make sense to copy something like the big_spender track for each domain and essentially have no spending limit - sort of like the current configuration. However, this wouldn’t put a hard cap on spending and we’d likely see the same spending trajectory despite some points made on how recent spending isn’t reflective of our actual trajectory.

So folks, how shall we proceed? Any other ideas we should consider? How can we act now?

P.S. Who’s going to place the 3,333 KSM decision deposit in the root track to get these track changes actually voted on?

[RTTI-5220]

One thing to take into account is this “special calls” that were included on Treasurer track in the OpenGov model: they should be accommodated somehow on one of the new tracks if we want to use this mechanism - I am talking specifically about bounty approval and curator approval calls.

[Karim]

Hi everyone, just to add some context to the great analysis @asteeber shared.

We’re tracking Treasury expenditure, amongst other data points at Parity (Data team) and have also some numbers and dashboards on this exact topic. I’m sharing these to add some context to the discussion - not to change the topic.

As far as the linear regression goes, if you only account for the last 3 months of treasury expenditure, we come to the exact same conclusion (mid November 2023).

However, when running the linear regression on a longer time interval (roughly 1 year), things look a little bit different which might hint to some seasonality in the data.

This gives us a “Zero date” of roughly March 2025, when looking in a yearly cycle.

In terms of data points to help support this discussion, we’re happy to help if you tell us what data you need to have a full picture of things. We’ll share more of these dashboards & data with the community going forward.

[CoinStudio]

Hey Adam,

I appreciate the details you provided in your post. Given the importance of these discussions, I encourage you to take this work further through a treasury proposal. This would allow you to fully focus on research and experiments, ultimately enabling you to propose concrete options along with their associated risks.

I am interested to see a smaller-scale experiment with your approach. I also beleive that further research and evaluation of the option I proposed to restrict existing tracks is necessary, as it doesn’t take into account potential issues such as people spamming tracks with false proposals, which could lead to a need for changing deposit requirements. I am also quite interested to see the actual numbers regarding real ideal staking calculations and the percentages of inflation split between staking and treasuries in various scenarios.

For the reasons mentioned above, and to ensure this initiative doesnt get lost in the discussion, I am in favor of supporting this initiative in the form of a treasury proposal that will provide concrete answers.

Below is my reply to your proposal on Polkassembly:

---

As I already mentioned, I truly appreciate your dedication to moving beyond mere discussions and presenting a practical solution. It’s always refreshing to see a proactive approach in action.

I believe it would be beneficial to conduct a smaller-scale experiment on this case before fully committing to the proposal. This would allow us to gain valuable insights, assess potential risks, and make any necessary adjustments to the approach. Please have a look at the proposed steps (sent you .doc on Element):

Milestone 1: Proposal Preparation and Community Feedback

Task 1.1: Present a new proposal during the discussion phase.
Task 1.2:  Present the working budget, incorporate the research hours spent into the proposal.
Task 1.3: Request a smaller test amount of 100? KSM.
Task 1.4: Align the proposal with feedback from experienced community members like Joe, Kian and Raul.

Milestone 2: Research Expansion and Scenario Analysis

Task 2.1: Expand existing research on staking Kusama Treasury funds.
Task 2.2: Present projected trajectories under different scenarios.
Task 2.3: Go deeper into ideal staking calculations.
Task 2.4: Cross-check findings with developers and confirm the proposed calls
Deliverable 2.1: Comprehensive research report with scenario analysis and calculation validation.
Deliverable 2.2: Completed and revised proposal document, incorporating all tasks.

Milestone 3: Test Case Execution and Evaluation

Task 3.1: Stake the allocated 100 KSM from the Treasury.
Task 3.2: Monitor the staking process and document any issues or observations.
Task 3.3: Analyze the impact of staking on rewards for the rest of the ecosystem.
Task 3.4: Evaluate the success of the test case based on the project's objectives.
Deliverable 3.1: Test case execution report, including findings and recommendations for future implementation.

Milestone 4: Community Engagement and Final Reporting

Task 4.1: Share the research report and test case findings with the Kusama community.
Task 4.2: Gather feedback and address any concerns or questions.
Task 4.3: Prepare a final report summarizing the project's outcomes and recommendations.
Deliverable 4.1: Final project report, incorporating community feedback and suggested next steps.