With referendum 244 upgrading Kusama’s runtime to v9320 and including OpenGov on Kusama Network, the new governance phase started.
I am opening this post for the community to include all changes, suggestions and requests they want to see in the new model: for discussion and eventual modification if approved (this can include but its not constrained to: changes in parameters, voting periods, confirmation periods, enactment periods, changes on tracks, inclusion of new tracks, among other things).
I can read that the decision period on Polkadot will last 28 days. Does that mean it will last 7 days on Kusama? That would be the most logical in my opinion.
Throwing down some questions / thoughts I have for opengov - in no particular order:
Governance delegation is clearly central to kickstarting / scaling this new system, is there any thinking yet on basic UIs for discovering delegates. If this is kinda like nominators finding validators, then how might this discovery happen? e.g. i can imagine a very basic addition to polkadotjs similar to staking tab… but this is obvs very low info.
Its chicken / egg - in order to aggregate gov delegates, we need gov delegates who can then be aggregated into some sort of discovery platform? Do we expect this will happen organically? Do we need to give it a push?
In this example, the initial discovery challenge is in the hands of gov delegates who must bring alive their story, their terms, their vision and their plans and ensure that KSM holders are made aware of this opportunity.
We can then begin to think about orgins and tracks - do we expect specialist on-chain organisations dedicated to these? Might we have some group pitching some vision or project that requires a lot of tipping - for say a creative project that has 1000 very small proposals that together manifest a larger outcome? Do we think on-chain orgs will be fluid across orgins and tracks… flexing the needs of incubated projects to match the opengov system?
This feels like a really exciting design space - to develop / experiment with and bring alive the visions of many gov delegates…
currently my own experience comes via edgeware’s on-chain governance, whereas other groups are maybe experienced in kusama council - or have bootstrapped stuff with their own funds e.g. shokunin.
So a further question - should we fund experimental governance delegates - pre delegation?
Let’s call it a ‘gov delegation incubator fund’ - kinda like the Substrate builders programme, but involving Web3/KSM and DOT in some sort of aligned funding that is focused not on parachains / tooling, but on the on-chain orgs/collectives driving in some sort of direction.
There are a very small number of groups with the experience of on-chain governance, funding and indeed talent / project development that can actually make use of Gov2 - not only the basic tools, but able to experiment with and learn about the system via active experimentation.
Anyways - thats it for now, but I think the exciting thing about opengov, is it is a whole new territory that we can and should experiment with as a blank slate - how we get this innovation, will likely require some advance support / funding from the treasuries / Web3 in a very clearly articulated strategic framework.
Not sure who setup builders programme, but would love to help figure out this for delegates…
I second @ChrawnnaCorp 's suggestion to reduce the enactment period of treasury spendings. Kusama was so far a very fast-deciding, fast-acting network. I’m very concerned about 28 days decision period with given curves and 28 days enactment period because:
I doubt that treasury spends will find more than 1% support (who cares?), so a big spend will have to wait at least ~20d to reach the threshold
big spends will suffer more severely from exchange rate uncertainty in absolute terms but also because of longer time between proposing and receiving, so waiting >20d + 28d is very risky. Stablecoins can mitigate that, but we’re not there yet
The worst thing is: even if your referendum passes, you can’t be sure you’ll really get the funds after 28 days, because the meaning of an enactment period is exactly that interventions are possible
My gut feeling for tracks 30-35 is:
decision period: 14d
confirmation period 48h is fine
support curve reaches 1% after 7d and 0.1% after 12d for big spends
enactment period: 48h
Maybe a detail in the big picture, but I’d like to mention our PR to introduce smooth exponential curves in addition to piecewise-linear reciprocal curves. Apart from computational and code simplicity, I think exponential curves are much more intuitive than reciprocal (like: “support thresholds halves every 24h”)
The decision period is max 28 days: this means a proposal will be able to be up for vote for max 28 days, but can be approved before the 28th day (by fulfilling the criteria for approval). If a proposal reaches approval and support needed before the 28th day and fulfils the confirmation period, then it is approved.
Very thoughtful, brenzi. I didn’t consider the exposure to the changing market price. Bad for the proposer one way and bad for token holders the other.
I just want to add that we should not forget the Treasurer Origin, whose support curve reaches 1% only ~7h before end of decision period. So we have to expect that a “huge” spend will take 28 days to decide. Along my reasoning above, that is just too long, even if in this case the enactment is set to 2 days (which is good)
As it is now, I wonder why anyone would choose the BigSpender route. Even if the amount is below 3.33kKsm, it looks favorable to use Treasurer Origin
At the moment on Kusama the submission deposit is 100ksm, and the decision deposit is 16.66ksm for all curves (more info on the curves can be found here).
One of the changes I’d like to propose is the reduction to at least 1/10 for the submission deposit.
Yes, wallets and applications have on their roadmap an easy UI for discovery and delegation (this for example is included in Nova’s next milestone I believe - and I am sure also on Talisman - I will get you the info for polkadot.js Apps).
We will probably need to give this a push: particularly with education and sessions in which people understand what is delegation, what does it entail and how do they do it: a call from the extrinsics tab for each track is not the most practical one, so easy UIs will help here.
I assume that the critical challenge of passing a big or unlimited treasury spend will be support, not approval.
So, if we look at the minimum support needed in the last moment possible to pass for BigSpender, we need to look at the curve at 28d-48h, where the support curve is at 0.1954652%
If we now look at the Treasurer Track, we need to look at the linear support curve at 28d-3h, which is at 50%x3/(28x24)=0.2232%
So, the threshold for support as well as approval is pretty much the same for these tracks under my assumptions. Sure, the more support we can get, the greater the difference between these tracks (BigSpender passes quicker with increasing support), but:
If we now consider the enactment period of two days for Treasurer, and 28d for BigSpender, I clearly would favor a Treasurer referendum, even for funds below 3’333KSM
Is my math somehow buggy, or am I missing something?
On first look I wonder whether we may well just end up with one treasury track, and then some differing curves dependent on the funds requested… seems at first glance that this might make things more fluid?
there’s also the question that on-chain reputation / previous delivery can become a way to fast track things.
its interesting to think through how this might end up becoming much simpler over time.
Hello everyone, lots of great discussion going on here and I thought I would throw in my 10 cents.
I’ll lay out my opinions, but I’d like to preface by saying that I do understand these initial parameters were set with the intention of testing/ protecting the system and sparking discussions like these. With that said, I think:
Adjusting the formulas for the approval and support curves should be considered after the ecosystem has decided on reasonable periods. (I like brenzi’s curve suggestion and I think it would be appropriate for specific tracks)
The decisionPeriod for all tracks is much too long for Kusama.
The enactmentPeriod is too short for admin referenda and too long for spending referenda.
The confirmPeriod is too short for admin referenda and too long for spending referenda.
The preparePeriod for all tracks are much too short (frankly, it’s underutilized).
submissionDeposit is way too high.
I don’t really understand how the Fellowship will play a role, but since it’s in its infancy I think we don’t have to worry about it too much for the time being. But that’s coming from a non-fellow, so take that with a grain of salt.
I went ahead and made some suggested changes to the referenda.tracks parameters. Keep in mind that all of my suggestions are off-the-cuff, so please let me know if my suggested configuration could be gamed. Though I did try to create a good system of checks and balances, such that things are fast and affordable but not exploitable. Overall, I tried to achieve the following:
Decrease the submissionDeposit to a more affordable amount.
Decrease the number of referenda that can be deciding in each of the spending tracks while decreasing their decisionDeposit.
Increase the decisionDeposit for more consequential referenda.
Utilize the preparePeriod for all tracks.
Speed up everything.
Make the referendum_canceller and referedum_killer tracks even speedier.
Looking forward to feedback! Honestly, I am very excited about this new system! It has a ton of potential; it’s like a 4D game of governance chess. Truly, Kusama and Polkadot were built for scalability.
