They are only signaling proposals to gather the community’s opinion on the matter so there’s no rush to implement. I expect them to be implemented (if voted) in a slow time tbh.
I hate to say it, but I really don’t think so. If validator was not in a rush, he would have posted the idea first prior to posting the proposals live; giving plenty of time for discussion. Not too many people even knew these proposals were up for a vote.
Since this was txt only and NOT a parameter request, any attempt to fast-track this can still be a “No” vote. People are not planning here at all.
Maybe not, but can’t blame them either for doing so seeing the state of the power distribution at present.
It could not be a parameter proposal because the cap value afaik is not exposed as an API parameter. Should there be a positive outcome (5% or 10%) it will have to be coded and deployed in a new software classic-core release.
It would be really nice to have this capability/feature exposed as a parameter
Both passed quorum but none has a Yes majority. Doesn’t look like 5% is going through; 10% might do but is a lot further to the goalpost since a lot chose to abstain.
Strange. Must have cached data or something? Showed as passed for me earlier. I didn’t take a screenshot, so guess Station will gaslight me on this one. Ok… we will see how this unfolds.
The ID linking to wallets should remain confidential within the station, only viewable by the linking code - keeping our activities private, as they should be.
glad these are not going through. Guys - we need the validators to save our bacon! let’s delay the validator slaying until we have cashed in our first million yes?
Note: the wallet is not the ID tag. The ID is the ID, and by being unique, may be applied to as many wallets as owned, application of which to each wallet is controlled by the owner of the ID.
Also, — and thank you @godoal and others for reading and commenting, this is what makes the community strong — the point of the thought experiment isn’t to prove the validity of 1 ID to 1 human. The point is to ask: if we assume this point to be true, what are the negatives to implementing this type of governance?
If we could actually accomplish this, validators still run the chain, utility is still present, staking and rewards still present, but governance simply couldn’t be attacked without collusion, so What 2nd or 3rd or 4th order effects could impact the chain by making a change like this?
Yeah looks like its showing pass. A bit strange though given 52.31% either say no or no with veto while only 43.79% say yes. Maybe I don’t understand the voting system then but if it passes it passes against the will of the majority.
Am a bit confused about it as well tbh.
The proposal clearly says to vote YES/NO but some people vote No with Veto and even Abstain. If we take the proposal literally then YES is about to win but if we were to use the governance voting rules NO is about to win…
@pj20 It will pass. No with veto doesn´t count to the majority condition explained there. For yes there are more votes then for no. This is more then 50 % condition reached. Also quorum is 40 % so data are outdated btw.
I don’t think it is that complicated. It must be clarified if the governance rules are still valid or not.
IMO, the rules are still valid since a change in governance would have been requested officially as a proposal, and of course the official documentation would have been updated accordingly (the link from my previous comment is from the official documentation).
The proposal was worded in a way to suggest the accepted conditions are different from those used in the governance rules. Yet most people voted using the governance rules, hence the mess…
Even though being in favor of YES I am inclined to say this proposal has failed to pass as it stands since YES has not reached 50%.
