Treasurer Track Confirmation Period Duration Modification

[rrtti]

This RFC proposes a change to the duration of the confirmation period for the treasurer track from 3 hours to at least 48 hours.

[gavofyork]

Given the new data we have on governance activity and social dynamics, I would actually propose a slightly deeper change:

• Removal of Big Spender track (Treasurer works perfectly well for large spends).
• Treasurer track should have much more similar dynamics to Root, with a 7 day confirmation period and a 28 day decision period and linear/near-linear approval/support curves.
• Small Spender track to get a 2 day confirmation period, 28 day decision period and similar curves to present.
• Medium Spender track to get a 4 day confirmation period, 28 day decision period and curves lying between Small Spender and Treasurer.
• Renormalize conviction lock period from 7 days to 28 days for 1x (and accordingly for other periods). Unfortunately we can't do this directly without inadvertently locking up preexisting convicted funds for longer than the advertised period. To avoid this we can reduce the amount of bonus any given period gives. Thus:

Lock time	Old factor	New factor
No conviction	0.1x	0.1x
7 days	1x	0.2x
14 days	2x	0.3x
28 days	3x	1x
56 days	4x	2x
112 days	5x	3x
224 days	6x	4x

The main idea is that below the period of 28 days (which is a watershed period given staking and proposal periods) we want to have a sub-linear factor to disincentivize actors from voting and running. At present you can vote with 66% of your voting power (say, on something which would massively disadvantage the network) and exit as stakers are only half-way through their unlock period.

It is questionable if we would want funds with less than 28 days locking to be counted at all, but I do think there's an argument here in favour of democratic inclusivity at a cost of slightly weakened economic argument. The 0.1x, 0.2x, 0.3x for no lock, 7 days and 14 days locks represents an effort to find a middle ground here.

[Yung-Beef]

• Treasurer track should have much more similar dynamics to Root, with a 7 day confirmation period and a 28 day decision period and linear/near-linear approval/support curves.

@gavofyork Root currently has a 1 day confirmation period, are you implying increasing that 7 days as well?

[Leemo94]

@gavofyork currently prepare_period, confirm_period and min_enactment_period are the same for tracks on Kusama as they are on Polkadot. For the decision_period there is a difference whereby a lot of tracks have a 28 day decision period on Polkadot, and a 14 day decision period on Kusama.

With regards to your comment above, would you also propose to apply those changed parameters to Kusama?

For example, would a 7 day confirmation period for the Treasurer track on Kusama be too long when the decision period is 14 days?

I really don't know the answer to this one, I just recall that previously there was a desire from the Kusama community/token holders to have OpenGov be a little bit faster than it's original implementation which caused a few decision periods to be reduced from 28 days to 14 days. I wonder if a similar sentiment will arise if the confirmation period was too long / conservative?

Definitely agree with you in regards to being a bit more conservative on Polkadot.

Thanks for clarifying RE: conviction locks, a few people in the community were wondering if increasing the locks on preexisting convicted funds was something that may happen.

[gavofyork]

@gavofyork Root currently has a 1 day confirmation period, are you implying increasing that 7 days as well?

I guess I am :)

[gavofyork]

With regards to your comment above, would you also propose to apply those changed parameters to Kusama?

Only talking about Polkadot here - basically just stick with the 28 day periods.

Definitely agree with you in regards to being a bit more conservative on Polkadot.

I think Polkadot would be fine at the current periods; let's not forget that it is the curves which are important more so than the period, which is really just a timeout.

Thanks for clarifying RE: conviction locks, a few people in the community were wondering if increasing the locks on preexisting convicted funds was something that may happen.

👍

[bkchr]

Created an issue to continue with this RFC: https://github.com/polkadot-fellows/runtimes/issues/100

If someone wants, they could directly create a pull request with the parameter changes.