Kusama Treasury Follow-up Analysis: Continued Budgeting Incompetence

Hello again everyone,

I’m back to show you all the result of the massive change in sentiment on Treasury spending that was markedly signaled by my original forum post about Treasury spending. Let’s get into the data right away.

In my previous post I plotted the Treasury’s balance from blocks 16,000,000 to 17,224,000. I have now extended this plot out to block 18,418,000:

It is difficult to see exactly where everything changed, so allow me to provide some broader visual context. In the following plot, I’ve marked the exact timestamp of my original post (i.e. block 17,286,043). I also extended the y-axis to zero and included the old projection. Most importantly, I’ve included a projection (linear regression) of the Treasury’s balance only using data from after my original post:

You might be thinking, “wow this is amazing! We’ve managed to stop the hemorrhaging! We did it!” First off, “we” didn’t do it - the millionaire overlords did. In their self-righteousness they’ve struck down nearly every spending request to the point of completely demoralizing the entire ecosystem. I have seen these completely incompetent elites strike down spends that would have greatly benefitted the ecosystem, not to mention retain highly loyal individuals. Some notable examples:

  • 178: Solidity-to-Ink! documentation/ program to help onboard Solidity devs to Ink! - a Substrate-specific smart contract language. This would have been a crucial, idependent supplement to existing documentation. Anyone who has tried to learn a new language knows the frustration behind documentation that just assumes you have all of the implied knowledge.
  • 179: Sublab’s Substrate client improvements. This would have built out extremely useful client features like the implementation of data models (as a data scientist, I can attest that most Substrate data models are very confusing and cumbersome), caching (useful for dApps), extrinsic services, mobile integration examples, documentation, testing features, and more.
  • 175/194: Will’s RPC performance monitoring. This is the most tragic in my opinion. He got overwhelming support for the project but the suborn whales exerted their power to strike these spends down. When 175 failed, 194 was made as a real honest attempt to compromise and the overlords were completely merciless. Is this how we thank the most valuable and loyal individuals in the ecosystem?
  • 201: Claudio’s media spend request. I’m not usually a fan of media spends but Claudio is a shining example of independent media. He’s not part of an organization yet he generates content and an audience that rivals that of some organizations. He’s just a nice guy and very loyal, until the whales chewed him up and spit him out. It was excruciating to watch his hopes get obliterated in real time.
  • 204: Integritee’s retroactive funding request for implementing a privacy sidechain for all substrate chains. Seriously? You rich anonymous cowards struck this one down? Isn’t privacy important? Didn’t you want people to be compensated for work already performed?

Let’s examine how ridiculous the projection is of these ultra-conservative whales’ actions. If we continue the projection of current spending (i.e. using data after block 17,286,043) this is what we’re looking at:

At this rate of spending, this projects that the Treasury will run out of funds at block 32,721,457. Do you know how far into the future that is? It’s at least 993 days, or sometime around March/ April of 2026. I understand that we want a healthy Treasury for a long time, but this is also Kusama. We have to keep in mind that not spending the Treasury has an opportunity cost. Every project we don’t fund is an innovation not explored. How do we expect to experiment with anything if we aren’t funding teams and individuals willing to experiment? How can we expect Kusama to set precedents for Polkadot if it is too fearful to take leaps of faith? The whole reason I decided to make a career in Kusama is so I could eventually prove myself worthy of Polkadot - how can anyone prove themselves worthy of Polkadot when Kusama won’t let them battle test their ideas without becoming a slave who needs to beg to the overlords for uncertain compensation?

My message to the vague, obscure, anonymous, mysterious, incompetent, millionaire whale overlords:

Your ‘just vote NAY’ policy reeks of ignorance and many of you have proven that you have no idea what good economic policy looks like for an organization like Kusama. You flaunt your massive bags by crushing the spirit of eager entrepreneurs, shooing away loyal users that are invaluable to the network. All of this might be bearable if you would actually show up in public forums to participate in nuanced discussions. Instead, you hide behind your veils of anonymity and send cryptic messages in the form of on-chain remarks or hearsay from those who know your identities. Stop pretending that you actually consider anyone’s opinions but your own. You know your power and you have shown complete incompetence in using it. The people you have shut down and the atmosphere you have generated in unbecoming of an enlightened and economically mature organization. You have turned the Treasury into a miser’s trophy. Absolutely despicable.

There is only one way to solve this: budgeted spending tracks.

Like I said in my previous post, the hivemind (now totally dominated by these rich whales) is really bad at budgeting. Before we were spending too much. Now we are spending too little. What is the solution? It’s glaringly obvious to me: make it completely impossible to spend more than what is reasonable. What is reasonable? Why don’t we split the difference:

The red line shows where we were heading before (running out at block ~20,600,000). The blue line shows where we are heading now (running out at block ~32,720,000). The green line simply splits the difference, setting the zero date at block ~26,660,000 or sometime in January/ February 2025. How can we achieve this? Like so:

Track Name Max Deciding Max Spend Decision Period Min Approval to Confirm Timeout
Small Budget 10 100 KSM 14 days 50% 28 Days
Big Budget 2 2,500 KSM 14 days 66% 28 Days
Treasurer 1 No Limit 28 days 66% 7 Days

Look familiar? Yeah, it’s the exact same table as in my previous post with altered names and added timeout values. In my previous post I said:

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

Turns out that I didn’t take into account the ~2 spend periods per decision period, so this configuration would actually spend ~3,000 KSM per spend period or 6,000 KSM per decision period. So my original configuration was actually spot on in regard to this Split the Difference policy. Here’s the math:

  • Current Treasury Balance: 282,776 KSM
  • Number of blocks until block 26,660,000: ~8,237,000
  • Budget per block: 0.03433 KSM
  • Budget per decision period of ~12 days: 0.03433 * 10 * 60 * 24 * 12 = 5,932 KSM

This will effectively budget the Treasury while queuing projects for funds rather than crushing spirits with big NAYs. We can vote AYE for everything that seems reasonable, we can compare multiple spends before they even start deciding, and the voters will prioritize funding based on approval ratio. We must utilize the preparing period in openGov to help us vet and prioritize projects.

Since I have no way of placing the decision deposit for the root track to get such a configuration deciding, I am asking anyone in the Fellowship to please reach out to me. I don’t have access to that element lobby since I’m not in the Fellowship but if I can hop on a call with someone who is on the Fellowship, I can relay all of this information and work with them on a PR. May I even be so bold to ask for someone to propose to add me as a Fellow? (Preimage has been noted: 0x32c3471cd246b200cc40744db33cf1a65309f0f7eab7ae69142b12158bccedd3). I might not be as technically inclined as some members but I believe my abilities to perform data analysis teamed with my expertise in economics may qualify me. In any case, this is a highly informed recommendation worth serious consideration. It is also imperative that we implement this policy ASAP so we can test it for Polkadot because one thing is for certain - the current configuration is not working.

Respectfully disgruntled,

Adam

Tips: GqC37KSFFeGAoL7YxSeP1YDwr85WJvLmDDQiSaprTDAm8Jj

19 Likes

I am a Polkadot fellow, and can contribute to updating the FRAME pallets and runtime configuration.

Let’s discuss in public (here) what your specific suggestions are. Can you make a post, as if you were giving a technical specification to a contractor of the work you would like done?

I will happily provide feedback, from my point of view, then we can take it from there.

12 Likes

Hi Shawn, thank you for your reply. Here is a link to a branch containing the technical changes I believe are necessary for the spending tracks. This branch compiles and the wasm runtime works in Chopsticks:

✨ Your Substrate WASM Runtime is ready! ✨
Summary generated with srtool v0.11.0 using the docker image paritytech/srtool:1.70.0:
 Package     : kusama-runtime v0.9.43
 GIT commit  : ba42b9ce51d25bdaf52d2c61e0763a6e3da50d25
 GIT tag     : v0.9.43
 GIT branch  : HEAD
 Rustc       : rustc 1.70.0 (90c541806 2023-05-31)
 Time        : 2023-06-27T19:34:30Z

== Compact
 Version          : kusama-9431 (parity-kusama-0.tx23.au2)
 Metadata         : V14
 Size             : 6.76 MB (7086814 bytes)
 setCode          : 0xfcf6a7b755d11275ee9eb515e3e5ecdab2110389085ef638201f16cea92c49e2
 authorizeUpgrade : 0xf7e6e0f3258e5f12c8104ea88b2373d824204a56e2cdca8eb1e60f5c166db3f5
 IPFS             : QmcntwW1Eg1JKg4QgUURcrPwKFk9t3811vr9YJ4maQ3B4r
 BLAKE2_256       : 0x6e53e12a7d0dd4cfcb5f5fa2256c31346bed1756eb3e3ab73449c55480fd80a8
 Wasm             : runtime/kusama/target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.wasm

== Compressed
 Version          : kusama-9431 (parity-kusama-0.tx23.au2)
 Metadata         : V14
 Size             : 1.41 MB (1482653 bytes)
 Compression      : 79.08%
 setCode          : 0x98110e1c0e050d12c8d44a7067cbf3262797b3e09b3186c263d82ec7dda83056
 authorizeUpgrade : 0x7269344a1692fea81933ea9ebcb127c75a29d34704eca386a0198c00ebca51ba
 IPFS             : QmVCcea3tvFAPUDrRWrpvJAKMaoqBRVbBN8P32nLfTvXNn
 BLAKE2_256       : 0x852ba89f5b541f5cec9632c9f2f6a5b4a331670c21515f1ddbc21a3f8d06a33c
 Wasm             : runtime/kusama/target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.compressed.wasm

Here’s what gets returned when you query api.consts.referenda.tracks on this runtime:

[
	[0, {
		"name": "root",
		"maxDeciding": 1,
		"decisionDeposit": 3333333333300000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 14400,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"reciprocal": {
				"factor": 222222224,
				"xOffset": 333333335,
				"yOffset": 333333332
			}
		},
		"minSupport": {
			"linearDecreasing": {
				"length": 1000000000,
				"floor": 0,
				"ceil": 500000000
			}
		}
	}],
	[1, {
		"name": "whitelisted_caller",
		"maxDeciding": 100,
		"decisionDeposit": 333333333330000,
		"preparePeriod": 300,
		"decisionPeriod": 201600,
		"confirmPeriod": 100,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"reciprocal": {
				"factor": 270899180,
				"xOffset": 389830523,
				"yOffset": 305084738
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 8650766,
				"xOffset": 18867926,
				"yOffset": 41509433
			}
		}
	}],
	[10, {
		"name": "staking_admin",
		"maxDeciding": 10,
		"decisionDeposit": 166666666665000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"linearDecreasing": {
				"length": 607142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 7892829,
				"xOffset": 15544040,
				"yOffset": -7772020
			}
		}
	}],
	[11, {
		"name": "treasurer",
		"maxDeciding": 1,
		"decisionDeposit": 33333333333000,
		"preparePeriod": 28800,
		"decisionPeriod": 403200,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"reciprocal": {
				"factor": 50836597,
				"xOffset": 132075472,
				"yOffset": 615094339
			}
		},
		"minSupport": {
			"linearDecreasing": {
				"length": 1000000000,
				"floor": 0,
				"ceil": 500000000
			}
		}
	}],
	[12, {
		"name": "lease_admin",
		"maxDeciding": 10,
		"decisionDeposit": 166666666665000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"linearDecreasing": {
				"length": 607142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 7892829,
				"xOffset": 15544040,
				"yOffset": -7772020
			}
		}
	}],
	[13, {
		"name": "fellowship_admin",
		"maxDeciding": 10,
		"decisionDeposit": 166666666665000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"linearDecreasing": {
				"length": 607142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 7892829,
				"xOffset": 15544040,
				"yOffset": -7772020
			}
		}
	}],
	[14, {
		"name": "general_admin",
		"maxDeciding": 10,
		"decisionDeposit": 166666666665000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"reciprocal": {
				"factor": 222222224,
				"xOffset": 333333335,
				"yOffset": 333333332
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 49586777,
				"xOffset": 90909091,
				"yOffset": -45454546
			}
		}
	}],
	[15, {
		"name": "auction_admin",
		"maxDeciding": 10,
		"decisionDeposit": 166666666665000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"reciprocal": {
				"factor": 222222224,
				"xOffset": 333333335,
				"yOffset": 333333332
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 49586777,
				"xOffset": 90909091,
				"yOffset": -45454546
			}
		}
	}],
	[20, {
		"name": "referendum_canceller",
		"maxDeciding": 1000,
		"decisionDeposit": 333333333330000,
		"preparePeriod": 1200,
		"decisionPeriod": 100800,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"linearDecreasing": {
				"length": 607142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 7892829,
				"xOffset": 15544040,
				"yOffset": -7772020
			}
		}
	}],
	[21, {
		"name": "referendum_killer",
		"maxDeciding": 1000,
		"decisionDeposit": 1666666666650000,
		"preparePeriod": 1200,
		"decisionPeriod": 201600,
		"confirmPeriod": 1800,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"linearDecreasing": {
				"length": 607142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 7892829,
				"xOffset": 15544040,
				"yOffset": -7772020
			}
		}
	}],
	[30, {
		"name": "deprecated_small_tipper",
		"maxDeciding": 200,
		"decisionDeposit": 33333333333,
		"preparePeriod": 10,
		"decisionPeriod": 100800,
		"confirmPeriod": 100,
		"minEnactmentPeriod": 10,
		"minApproval": {
			"linearDecreasing": {
				"length": 357142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 1620729,
				"xOffset": 3231018,
				"yOffset": -1615509
			}
		}
	}],
	[31, {
		"name": "deprecated_big_tipper",
		"maxDeciding": 100,
		"decisionDeposit": 333333333330,
		"preparePeriod": 100,
		"decisionPeriod": 100800,
		"confirmPeriod": 600,
		"minEnactmentPeriod": 100,
		"minApproval": {
			"linearDecreasing": {
				"length": 357142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 4149097,
				"xOffset": 8230453,
				"yOffset": -4115227
			}
		}
	}],
	[32, {
		"name": "deprecated_small_spender",
		"maxDeciding": 50,
		"decisionDeposit": 3333333333300,
		"preparePeriod": 2400,
		"decisionPeriod": 201600,
		"confirmPeriod": 7200,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"linearDecreasing": {
				"length": 607142857,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 7892829,
				"xOffset": 15544040,
				"yOffset": -7772020
			}
		}
	}],
	[33, {
		"name": "deprecated_medium_spender",
		"maxDeciding": 50,
		"decisionDeposit": 6666666666600,
		"preparePeriod": 2400,
		"decisionPeriod": 201600,
		"confirmPeriod": 14400,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"linearDecreasing": {
				"length": 821428571,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 14377233,
				"xOffset": 27972031,
				"yOffset": -13986016
			}
		}
	}],
	[34, {
		"name": "deprecated_big_spender",
		"maxDeciding": 50,
		"decisionDeposit": 13333333333200,
		"preparePeriod": 2400,
		"decisionPeriod": 201600,
		"confirmPeriod": 28800,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"linearDecreasing": {
				"length": 1000000000,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 28326977,
				"xOffset": 53763445,
				"yOffset": -26881723
			}
		}
	}],
	[35, {
		"name": "small_budget",
		"maxDeciding": 10,
		"decisionDeposit": 13333333333200,
		"preparePeriod": 14400,
		"decisionPeriod": 201600,
		"confirmPeriod": 28800,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"linearDecreasing": {
				"length": 1000000000,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 28326977,
				"xOffset": 53763445,
				"yOffset": -26881723
			}
		}
	}],
	[36, {
		"name": "medium_budget",
		"maxDeciding": 2,
		"decisionDeposit": 13333333333200,
		"preparePeriod": 14400,
		"decisionPeriod": 201600,
		"confirmPeriod": 28800,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"linearDecreasing": {
				"length": 1000000000,
				"floor": 500000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 28326977,
				"xOffset": 53763445,
				"yOffset": -26881723
			}
		}
	}],
	[37, {
		"name": "big_budget",
		"maxDeciding": 1,
		"decisionDeposit": 13333333333200,
		"preparePeriod": 14400,
		"decisionPeriod": 201600,
		"confirmPeriod": 28800,
		"minEnactmentPeriod": 14400,
		"minApproval": {
			"linearDecreasing": {
				"length": 1000000000,
				"floor": 660000000,
				"ceil": 1000000000
			}
		},
		"minSupport": {
			"reciprocal": {
				"factor": 28326977,
				"xOffset": 53763445,
				"yOffset": -26881723
			}
		}
	}]
]

Here’s a summary of the changes:

  • Deprecates the current limited spending tracks by renaming them and setting their spending limits to 1 QUID.
  • Introduces 3 budgeted tracks with longer preparation periods and lower maxDeciding parameters to allow the ecosystem to experiment more with the preparation period in prioritizing spends.
  • The Big Budget and Treasurer tracks were given a minimum approval of 66%, but other than that all of the new spending tracks were given support and approval curves identical to the old Big Spender track.
  • All of the new limited spending tracks have decision periods of 14 days to ensure an approximate max spend rate of 6,000 KSM every 2 spend periods. This reflects my “split the difference” policy.
  • Removes the 0.2% Treasury burn per spend period. This can be restored if Society v2 starts spending enough funds to warrant this burn.

I am capable of preparing the referendum on Kusama and, as shown above, I am capable of providing the details of producing the wasm blob. If it’s going through the Whitelisted Caller track then I would need the Fellowship to approve the call. I’m not sure if I versioned it correctly so any feedback there would be appreciated. I also don’t know if my deprecation process is the best, so I’m open to suggestions on how to properly deprecate the old spending tracks. If I missed any necessary configurations, please let me know.

Note, this runtime upgrade would need to occur before 9440 and 9440 would need to have these changes merged, so I would need Parity to be on board with these changes.

Hi @asteeber,

Your branch is easy to understand, although I do have some feedback.

I think the best course of action is to actually open a PR, and lets get it through a code review and see where it goes from there.

Here is a small sample, but my proper feedback will be in the PR:

  • No need to deprecate everything. Lets just adjust small, medium, and big spender.
  • Let’s keep around tipper tracks. Tips has been in the spirit of small community payments for things like a youtube video or similar.
  • Therefore, there really shouldn’t need to be a diff on the origins.
  • Burn is an important part of adding pressure to spend treasury. It is better, to not have the burn go to the society rather than stop the burn all together.
  • You should probably not be using UNITS. This is the smallest value that can be represented (I think 10^-12 ksm). You want QUID which is equivalent to KSM.
1 Like

Thanks for sharing your perspectives @asteeber and @shawntabrizi.

I’m going to suggest that before we change these parameters, we also discuss a little more what we hope to achieve if we are ultimately to evolve this technology to become more humane, not more technocratic.

Why I love Adam’s post is that it shows off the complexity of his personality - it is analytical, critical and emotional - and underpinning it all, are his values.

@shawntabrizi you bring a different, but no less important perspective - but what is front of mind to you, is not necessarily what is front of mind to others - as has been noted elsewhere:

We all see the world through different eyes, interpret data points differently and communicate our intentions in different languages - english, spanish, rust…

This is true of every one of the 1000+ members of this forum. Collectively we are way smarter than we are individually, but it is very very hard to translate between these perspectives, without getting into arguments.

Why perspective matters to parameter changes

@asteeber you have experienced a wide range of emotions when it comes to treasury funding. You have lived the highs and endured the lows - the stress, the anxiety and the unfeeling nature of the overlords.

@shawntabrizi you have never (afaik) proposed a treasury spend, nor sustained your work by requesting funds from a collective pot, nor endured the gauntlet of this process. Until you do you cannot understand what it is like to be a community member in this context. This is not a criticism, this is an observation - and it is one that is true for all of Parity/W3F.

I have sustained my work entirely through treasury funding and my own funds for the last 3 years, helping many others do the same. This process has allowed me to see first hand how different people - both proposers and voters interpret parameters, mechanisms, language and process differently.

Suggestions

Financial models are are always wrong - the longer out we plan, the more wrong they will be.

Ultimately these models tell us what the future looks like, if nothing were to change.

For example, we are structuring a deal with external financiers, that would enable the treasury and collective to become far more potent, thus extending spending powers well into the future.

Models are useful for getting people to think about bigger pictures - to assess what matters and to allow groups to plan for the future in an educated and importantly an iterative way.

  • Suggestion 1: Adam, or others to create monthly treasury forecasts. This could easily turned into a programmatic analysis to be surfaced through a UI such as Polkassembly / Subsquare. @Jas @wliyongfeng. We are adding this to our work developing a Discourse <> Substrate <> Wordpress integration, whose aim is to better unify data, analytics, media, discussion, proposals and on/off chain triggers and performance measures within a unified UX/UI.

  • Suggestion 2: We collectively outline what support looks like for talent through the full cycle of innovation and create language within the parameters and UX/UI that better educates proposers and voters as to the type of funding they are requesting and what stage they are in a bigger process…

Small changes can make a big difference to the feeling of contributing to the collective.

Here are the current language of parameters:

Track Name Max Deciding Max Spend Decision Period Min Approval to Confirm Timeout
Small Budget 10 100 KSM 14 days 50% 28 Days
Big Budget 2 2,500 KSM 14 days 66% 28 Days
Treasurer 1 No Limit 28 days 66% 7 Days

Here is how we could make the parameters more humane - not this is not just about changing numbers, but about changing labels and also considering the implications on how we communicate this process.

Phase Queue Max spend Decision Period Approval required Timeout
Research 10 100 KSM 7 days 20% 28 Days
Proof of concept 2 2,500 KSM 14 days 40% 28 Days
Product 1 No Limit 28 days 60% 7 Days

Currently tracks condenses a lot of nuance into a single technical term - but we must be clear that different tracks correlate with different areas of governance. There is nuance.

If we see spendng tracks as phases in an innovation process we can open up more interesting design space when we consider adjustments to things like the burn (which is really a Root origin track) and see this as an example of another spendable origin whose consistent ‘drip fed’ funding is useful in a different phase.

Phase Origin Queue Max spend Decision Period Approval required Timeout
Concept research Treasury 10 100 KSM 7 days 10% 28 Days
Applied Research Treasury 100 100 KSM 7 days 20% 28 Days
Proof of concept Treasury 2 2,500 KSM 14 days 30% 28 Days
Product Treasury 10 No Limit 28 days 51% 7 Days
Base salary Burn 5 500 KSM 7 days 51% 28 Days
Mid salary Root 3 1000 KSM 7 days 51% 28 Days
Top salary Root 1 1500 KSM 7 days 51% 28 Days
Bonus Root 1 No limit 7 days Adoption based 28 Days

Once we have USDT spendable from treasury accounts we can evolve this further, giving people the option of requesting either KSM with some vesting parameters or liquid USDT.

Under certain conditions such as an ‘on-chain metric based’ bonuses, this KSM can be liquid.

Phase Origin Detail Queue Max spend Decision Period Approval required Timeout
Concept research Treasury Account A liquid USDT or vesting KSM 100 100 KSM 7 days 10% 28 Days
Applied Research Treasury Account B liquid USDT or vesting KSM 25 5000 USDT 7 days 20% 28 Days
Proof of concept Treasury Account B liquid USDT or vesting KSM 5 50000 USDT 14 days 30% 28 Days
Product Treasury Account C liquid USDT or vesting KSM 3 200000 USDT 28 days 51% 7 Days
Direction Treasury Account D liquid USDT or vesting KSM 1 1000000 USDT 28 days 60% 7 Days
Base salary Burn Liquid KSM 5 500 KSM 28 days 51% 28 Days
Mid salary Root Liquid KSM 3 1000 KSM 28 days 51% 28 Days
Top salary Root Liquid KSM 1 1500 KSM 28 days 51% 28 Days
Bonus Root Liquid KSM 1 No limit 7 days On-chain metric based 28 Days

Summary

We are moving in the right direction, but we need to as a collective think more holistically about the whole innovation and support process, rather than just addressing symptoms with deeper underlying faults.

I’ve begun to lay out some of this rationale here in this post Structuring support across a full innovation cycle

Current arguments within ecosystems focus attention on large ‘public good’ treasuries. Whilst influential, these entities are just one component in what can be understood as a phased innovation process that should be structured through the full life cycle of R&D, productisation and go to market, with motivations, oversight, rewards and ROI contingent on the phase and the entity involved.

1 Like

Thanks for the feedback!

@shawntabrizi I mostly agree on pretty much every point:

  • It’s nice to know that we can just rename and adjust the current tracks; makes the tracks much cleaner.
  • While I agree that tips are an important aspect for the community, the whole point of this reconfiguration is to make it impossible to spend Treasury funds at a high rate. Based on the volume of tips requested since openGov started on Kusama, I believe we can accommodate the community with strict spending limits. As such, I’ll adjust the maxDeciding parameters for the tipping tracks.
  • I’ll put the burn back for now, maybe later we can discuss how we could get the burn to go to a dead wallet or simply remove burned KSM from existence altogether.
  • UNITS are equivalent to 10^12 planck KSM and 1 QUID is equal to a quid if 1 KSM = 30 quid, see here.

I’m hesitant to create a PR since I highly doubt Parity will spend the time to merge something like this. Wouldn’t it just be better to prepare a referendum instead? Isn’t that the whole point of openGov? That way token holders can decide on this in a separate referendum instead of it being lumped together with other technical upgrades. Merging it for 9440 would be like trying to catch a fast moving train.

Here’s the comparison after implementing your feedback. And here’s the runtime info when you build the branch:

✨ Your Substrate WASM Runtime is ready! ✨
Summary generated with srtool v0.11.0 using the docker image paritytech/srtool:1.70.0:
 Package     : kusama-runtime v0.9.43
 GIT commit  : bb8a6d5edbb200900f256db6d0b1732ffeff022b
 GIT tag     : v0.9.43
 GIT branch  : adam-spending-reconfig
 Rustc       : rustc 1.70.0 (90c541806 2023-05-31)
 Time        : 2023-06-28T23:40:39Z

== Compact
 Version          : kusama-9431 (parity-kusama-0.tx23.au2)
 Metadata         : V14
 Size             : 6.76 MB (7087701 bytes)
 setCode          : 0x2112339026da757736fd9bb51ad013104bf988ca23a42585a9bc1a72637ea6dd
 authorizeUpgrade : 0x5cc02af8ecbe3e4977589b5886427ad04963b5b86208d95ee329c205f3354711
 IPFS             : QmT8vJnaYjfqaBJghvDhUHUsq1AztHQmRqtrHNop3xpMac
 BLAKE2_256       : 0xc809cc7d92529de0ca4169d0bce6e2c6a86651019ee624028c61d1ec1bd1db95
 Wasm             : runtime/kusama/target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.wasm

== Compressed
 Version          : kusama-9431 (parity-kusama-0.tx23.au2)
 Metadata         : V14
 Size             : 1.41 MB (1482833 bytes)
 Compression      : 79.08%
 setCode          : 0xd0bcea57db9632a212c5e56de8885aeff15f66678450b7b65837acf18817b800
 authorizeUpgrade : 0x872c9a3d365f8f4b0891578feaa8022211c67055af9b15d58224d5a91c3b6c75
 IPFS             : QmbtEDKs6WxRyJJqE8xwK7JHATowzdhRTpgnkbuoZhrbHJ
 BLAKE2_256       : 0x0c3598b681c6a1b8419be3287691e267f98d11a29fdf6fcbc89b81cd4216377f
 Wasm             : runtime/kusama/target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.compressed.wasm

I will most likely just propose a setCode referendum after everyone has had a chance to provide their feedback.

@rich I enjoy reading your well thought-out responses and I’d like to share my perspective with this reconfiguration. Essentially the goal is to encourage everyone to vote AYE on pretty much everything except for egregious asks. The idea is to get users to use their conviction or vote amount to prioritize spending when the deciding queue is full since proposals with the best approval will start deciding first.

I appreciate all the thought you put into categorizing tracks based on project phases, however I think this overcomplicates openGov spending. Here you are introducing a high-resolution bureaucracy which forces the entire ecosystem to meticulously comply to the categories. This will result in confusion and conflicting interpretations of the tracks. By keeping general spending tracks with no categorization beyond how much can be spent, we allow the users to implement whatever categorization that works best for them. Some users may carefully analyze spend requests using complicated business models to inform their votes. Some users may just glance at the proposal and go with their gut feeling. The point is to make it as easy as possible to understand the tracks - introducing semantics only makes things more difficult to interpret.

In regard to:

  • Suggestion 1: Adam, or others to create monthly treasury forecasts. This could easily turned into a programmatic analysis to be surfaced through a UI such as Polkassembly / Subsquare. @Jas @wliyongfeng. We are adding this to our work developing a Discourse <> Substrate <> Wordpress integration, whose aim is to better unify data, analytics, media, discussion, proposals and on/off chain triggers and performance measures within a unified UX/UI.

I will likely perform an analysis like this every quarter to keep a pulse on the spending rate. I don’t really want to make it a formal project to ask for funding or anything, I’ll just do it every 3 months or so and if someone proposes tips for me for my analyses, that would be greatly appreciated.

2 Likes

Can you double (or triple) the number of deciding refs? The current numbers seem like an overreaction. With only 1 treasurer and 2 big spender, the cost to flood the system and prevent any spending is minimal.

1 Like

Can you add the Kusama tag to the convo?

1 Like

Fair. I think in time this phasing will evolve in line with better UX/UI and with specialist on and offchain orgs/collectives specialised in each phase.

What this process shows and encourages is that we can think outside the box a little and really question much of the current orthodoxy.

As we iterate towards being less wrong, we can improve the whole process and make it more humane.

Hi @tom.stakeplus, thanks for sharing your concern.

While the lower bandwidth does allow an attacker to easily jam the tracks, it is really only an issue when the track is empty. This is because the runtime will prioritize deciding referenda with the highest approvals. A referendum that serves only to jam the track will certainly receive an overwhelming number of NAYs and will likely timeout before it ever starts deciding, provided there are other meaningful referenda in the queue.

Even if a spending track is empty, there’s a 24-hour preparation period for the non-tipper spending tracks and a 48-hour preparation period for the Treasury track. That gives proposers some time to submit meaningful referenda that will be prioritized over spam. And if an attacker manages to jam the track with spam, we can always cancel or even kill the referendum to clear the track and potentially punish the behavior.

Absolute worse case: a track gets jammed up for 7 - 28 days before referenda are cancelled, or simply fail after their decision period. But with the ability to reap deposits with the referendum killer track, I don’t think anyone will try to jam the tracks.

1 Like

I do agree that budgeted spending tracks are a good idea. I do not agree that we are currently spending too little. First we need to identity our basic needs (A couple RPC nodes and Subscan and ??) and what those costs are. Anything less than covering basic expenses would be too little. At the current burn rate we are broke in less than 3-years. This is not a good plan. Needs to be less spent or more income to extend the mission.

"The Kusama relay chain exists as a security hub for parachains and for testing / Scaling of Polkadot’s core mechanics:

We should manage the treasury with an eye toward extending Kusama’s core mission as long as possible and eliminate spending outside of the scope of Kusama’s reason for existence.

1 Like

Pheeb, thanks for chiming in!

It’s totally reasonable to disagree that we’re spending too little. I understand my opinion in slow spending isn’t commonly shared. I am pleased to hear that you agree with the budgeted spending tracks; it’s likely the best first step in figuring out what the Treasury should spend funds on. In any case, I believe our spending initiatives can take better form in the context of more restricted tracks.

1 Like

@Pheeb we discussed this area briefly in Kusama direction related to working on a strategy and direction for Kusama and its spending, considering the outcomes we want rather than continuing to spray funds in a more generic ‘domain’ based way.

Currently the spending queue will soon be empty in Kusama - what kind of things do we want to see appear in these budgeted tracks?

In terms of “income” how do you see this resolving? Are you talking about fees? Repatriating funds to the treasury such as KappaSigmaMu pot? Diversifying?

@asteeber I think this is perhaps the one elephant in the room that isn’t discussed enough - what is Kusama for? What role does it play? What constitutes essential spending? What is not? What should we be experimenting with? What business is the network in? What are the boundaries of “Kusama”?

This was my response to the quote taken from Shawn in the original post:

For me this conversation is vital to have - to at least give the collective a chance to pause and consider the bigger picture. Pressing on without spending a little time digging into this will address an issue, without really digging deeper into the weeds.

Should we start this as a separate thread and keep this focused on the runtime parameters?

Interesting to see that on the side of ethereum, Optimism has moved to a similar model as proposed in the OP of this post:

In this threshold-based approval voting proposal, all options passing the approval threshold of 5.897M OP votes will be executed in order from most to least popular, until the total budget of 3M OP runs out. Each voter can select up to 14 options to vote for. If the quorum is not met, no options will be executed.

Basically how the process worked was:

  1. Four Themes/intents were announced for this cycle. Each theme had its own budget.
  2. Teams could apply via a proposal for grants and tag it to a theme.
  3. Each proposal that got approval from at least 4 peple with >0.25% of voting supply moved onto the next stage
  4. Now they have the above votes for each theme. Need to get over >50% participation.

Yes! Once we clearly articulate our mission statement then we can all start marching in the same direction and the people that do not want to go on that journey can leave. Once we clearly articulate our mission statement then we can apply goal directed thinking when we evaluate proposals.

The best statement of the mission I have found is:

"The Kusama relay chain exists as a security hub for parachains and for testing / Scaling of Polkadot’s core mechanics:

This is similar to what HACN has communicated. Holders opinions are ultimately expressed by their actions in the market and/or in governance.

“Income” is a simple matter of directing a larger percentage of inflation to the treasury instead of toward staking rewards. ie. Tax on stakers. Other funding sources also welcomed. It is also unclear if Kusama exists as a protectorate of Polkadot. By which I mean: Will Polkadot treasury step in and support Kusama’s critical infrastructure in a pinch? Not sure.

2 Likes

On AAG#46 yesterday you were discussing a decision deposit for a proposal to introduce spending limits, or rate limiting the spending, on Kusama.

What I am trying to understand is that if someone posts the decision deposit, which I believe is 3333 KSM, what stops a killer-whale from calling referendum killer and nuking the deposit? Strikes me as too large a risk for a rational depositor. Maybe I am missing something here.

Anyone could create a referendum killer to slash the deposit of a root track referendum, but that referendum killer would need to pass a vote for it to actually slash the deposit. Note, of all the referenda that have been proposed in openGov none of them have been a referendum killer.

However, if someone thinks this reconfiguration referendum deserves to be killed and the ecosystem votes for it to be killed despite all of my efforts to display my good faith, then all of my hope and spirit for the Kusama and Polkadot community would be obliterated. I hope people would have more sense than needlessly slashing the deposit of a root track referendum made in good faith.

4 Likes

I see Virto Team put up the deposit! Congratulations Ser. You have my support. Hope to see this one make history :grinning:

I reconsidered this and now believe Rob is Right. The process of the fellowship should be respected.

“The fellowship is designed to accept code upgrades originating from outside of its ranks both in the architecture phase (RFCs), and the implementation phase (PRs)”

I did not understand that before.

2 Likes

Sorry for the delayed response here.

I cannot agree with the way you want to approach here.

A PR must be made, and a proper review must occur. Changes must make their way back to the main Polkadot Runtime repo.

You should not try to squeeze your changes in-between runtime versions, this can only lead to issues and headaches.

I very much agree with the feedback you have received here: Best practice for community led runtime upgrade · Issue #13 · polkadot-fellows/runtimes · GitHub

A perhaps more appropriate approach would be to make a PR which places all of these values into storage, and then allows us to push and constantly update all values via governance, versus voting on just one set of numbers. However, this would be quite a technical change which has impact on performance.

In any case, the next step will always be here a proper PR and review.

Shawn, you said yourself that the changes I made are “easy to understand.” We aren’t talking about defining a process, we are talking about making very trivial changes to the runtime to put a cap on the Treasury’s spending rate. This isn’t rocket science and if implementing these in-between runtime changes for the next “official” upgrade gives the Fellowship a headache then it’s truly an incompetent organization. And like you said, a PR to push parameters into storage would be a much more arduous PR to create and review - just another way to stifle this quick and easy solution.

And look at the PR. Literally no one other than Oliver is giving it any consideration on GitHub. The irony, Shawn, that you’re here saying I should make a PR for review instead of reviewing the PR. So people should go the PR route but that’s just a way of brushing non-members off - pure false hope. The on-chain action forces the Fellowship’s hand which is a threat to its technical demagoguery which is why, across the board, members are highly critical of runtimes circumventing the Fellowship.

Instead, I’m expected to make a more complicated improvement to the runtime via PR with the hope that if it’s smart enough it’ll be considered? Hold up and let me reorient my entire life and career to learn substrate + rust lang so that I may appease the giga brains… Why wasn’t Gavin criticized when he didn’t code these parameters into storage to be determined by governance? He can operate in a hard-coded-parameters paradigm but no one else can? What a ridiculous double standard.

Everyone is acting like this non-Fellowship runtime upgrade is some crazy precedent, but it’s barely changing anything. I’ll admit it’s not a perfect solution, but does that mean it can’t be implemented even on Kusama? It works and it’s simple, is that not enough? If not then people like myself will feel totally powerless to make any suggestions that will cause real change.

P.S. I believe more complicated changes to the runtime should go the PR route to be heavily scrutinized by the Fellowship - that’s its purpose. Since my changes aren’t highly technical at all, making that point is totally moot. And I really don’t think that if referendum 235 passes that it will open the flood gates to a wave of trivial runtime upgrades because a) the decision deposit is insanely expensive and b) that’s always been an option yet no one has even attempted it.

2 Likes