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?
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.
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
decidingstate 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.