Proposal Repeals Moratorium: Introduce a 3-Month Lockout Period After Successfully Passing Governance

[Bilbo]

You do realize that in the tale of the tortoise and the hare, the hare wins the race… right…?

[Trex]

Proposal 10983 passes! YESSSS… its good to be able to repeal bad stuff!!

[RabbiJebediah]

No it’s not, because the community and validators then don’t take care what they vote for. If there was a 3-month lockout then everyone would pay more attention to proposals. The way it’s currently set up allows yo-yo-ing of the entire chain with these changes. It makes the whole community complacent, and allows individuals and small groups to politicize the process; proposals are used as ammo by factions in their tug of war… and the entire chain suffers.

Regardless of what your personal feelings are about any proposal, it’s still bad form to repeal it after it passes.

For the truly apocalyptic scenarios, validators can always ignore the lockout agreement and push through something that can save the chain (or undo a horrible proposal). But that’s 1% of the cases - the other 99% of repeals are just about infighting.

Shalom!

[nath]

Thanks for taking the time to put this together. While I agree with the spirit of the proposal, I think it’s is flawed:

1- if this is guidance, rather than a technical control, people who are motivated to raise param changes will do so, regardless of the guidance. There is an argument that Val’s could simply abstain/no vote in such scenarios, however, this creates a dangerous precedent where proposals are not fully thought through by Val’s.

2- if it’s a technical control, it adds significant risk by stopping the community responding to market changes/vulnerability. The argument that Val’s can bypass community voting and deploy code changes also sets a dangerous precedent and should be reserved for only critical vulnerability (e.g. the chain has to temporarily shut down to protect user assets). Generally any argument that suggests validators should/could bypass governance should be immediately rejected by the community, unless the protocol itself is at critical risk of failure.

3- this proposal targets the symptom of a problem, rather than identifying and fixing its root cause. Fixing individual symptoms will inevitably result in the problem manifesting itself in some other way. The root cause is likely a much harder problem to identify/solve, so it seems the proposer has taken a lazy approach to this issue, rather than undertaking the hard work to identify and treat the root cause of this problem (sorry if that sounds harsh).

[Vendrugo]

With a 3-month of lockup, I don’t think I would bother coming to write here. I would just use Binance for trading and forget about the Lunc community

[RabbiJebediah]

Thanks for the thoughtful reply, they’re incredibly scarce around these parts.

@nath

1- if this is guidance, rather than a technical control, people who are motivated to raise param changes will do so, regardless of the guidance. There is an argument that Val’s could simply abstain/no vote in such scenarios, however, this creates a dangerous precedent where proposals are not fully thought through by Val’s.

While you cogently point out the issue here, there’s only so many safeguards we can put into place until we get to the point that the community/validators need to accept responsibility for their voting patterns. I’m very much opposed to adding too many “training wheels” to governance on a macro level, because I believe anyone casting a vote on any proposal ought to do their due diligence before committing. And we really shouldn’t be enabling lazy validators who vote willy-nilly… if anything, they should be called out and if they persist, ejected from the active set through undelegations/redelegations by anyone staking with them.

@nath

2- if it’s a technical control, it adds significant risk by stopping the community responding to market changes/vulnerability. The argument that Val’s can bypass community voting and deploy code changes also sets a dangerous precedent and should be reserved for only critical vulnerability (e.g. the chain has to temporarily shut down to protect user assets). Generally any argument that suggests validators should/could bypass governance should be immediately rejected by the community, unless the protocol itself is at critical risk of failure.

Well AFAIK there’s not way to enforce this 3-month lockout on a code level, so it’s more a signaling proposal and community guideline than anything else. Validators bypassing the agreed-upon lockout period should IMHO only be reserved for truly apocalyptic scenarios. But honestly, what’s the chance of that happening? Most of the tug-of-war happening now with proposals is due to factional infighting between various community sub-groups vying for power and control.

@nath

3- this proposal targets the symptom of a problem, rather than identifying and fixing its root cause. Fixing individual symptoms will inevitably result in the problem manifesting itself in some other way. The root cause is likely a much harder problem to identify/solve, so it seems the proposer has taken a lazy approach to this issue, rather than undertaking the hard work to identify and treat the root cause of this problem (sorry if that sounds harsh).

The root cause is human nature. I don’t think there’s a way to solve that, short of everyone agreeing to let some godlike AI run the chain. This 3-month grace period (and the proposal in general) is a bandaid, that much I agree on, but it’s the only way to solve an otherwise unsolvable problem. Because as long as we have community-controlled governance where anyone can submit proposals, for better or worse, we’ll also have these yo-yo wars where one group dislikes something that passed and seeks to nullify the victory of another. We’ve all seen it with the burn tax, and it’ll keep happening over and over again. The 3-month grace period suggested in the OP doesn’t diminish governance or take away the community’s influence/control, it only limits backpedaling and forces everyone to seriously consider how they vote on proposals (which IMHO is a good thing).

You can disagree, but I can’t think of any other solution to the aforementioned problem. If you have one I’d be more than happy to consider it.

Shalom!

[Tynos]

Totally agree. At this point lunc is very chaotic and I doubt it shows confidence to any potential big investor and developer.

[awhitehouse]

There are two main problems with this proposal (although I do like the concept): 1) There is no way to enforce this via code currently (it is not an easy nut to crack btw). 2) It doesn’t allow for rapid changes in the even of a major event that could happen.

Perhaps there is a way to leverage Agora more? Maybe there is a way in Terra and Rebel Station to force all proposals have a link to a proposal here on Agora. However, before that can be done, the proposal on Agora has to have been up for X number of time (hours? days? ??) and have received X number of likes or comments. Then if it meets those criteria it can be posted.