Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Treasurer Track Confirmation Period Duration Modification #20

Closed
wants to merge 6 commits into from
Closed

Conversation

Leemo94
Copy link

@Leemo94 Leemo94 commented Aug 10, 2023

No description provided.

Leemo94 and others added 5 commits August 10, 2023 13:17
@rrtti
Copy link

rrtti commented Aug 10, 2023

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
Copy link
Contributor

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
Copy link

Yung-Beef commented Aug 10, 2023

  • 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
Copy link
Author

Leemo94 commented Aug 11, 2023

@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
Copy link
Contributor

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

I guess I am :)

@gavofyork
Copy link
Contributor

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
Copy link
Contributor

bkchr commented Nov 22, 2023

Created an issue to continue with this RFC: polkadot-fellows/runtimes#100

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

Leemo94 added a commit to Leemo94/runtimes that referenced this pull request Dec 11, 2023
Changes to Treasurer, Big Spender, Medium Spender and Small Spender Confirmation Periods as per: polkadot-fellows/RFCs#20
bkchr added a commit to polkadot-fellows/runtimes that referenced this pull request Jan 4, 2024
Changes to Treasurer, Big Spender, Medium Spender and Small Spender
Confirmation Periods as per:
polkadot-fellows/RFCs#20

I opted to not propose to remove the Big Spender track (it was part of
the discussion on RFC 20) as I am not sure how it would affect referenda
that are currently live on that Track.

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Bastian Köcher <info@kchr.de>
@Leemo94 Leemo94 closed this Aug 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants