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?