This is why we might want to think about the 1/3 veto as an alternative to supermajority.
1: it adds a cost to a veto, so you will need to really want to imitate it.
2. The code changes would be minimal.
3. It leaves a happy path for non-controversial proposals.
So does this basically mean that if 1/3 reject the the proposal is rejected?
If so what happens if there is 84% of total available voting power executed with 50.6% for and 33.4% against?!
No…this means that someone can initiate a veto proposal that will temporarily block the vetoed proposal(only one allowed per proposal). If it gets 1/3 voting power to endorse it then the target proposal is permanently blocked. If it expires with less than 1/3 and the target passed with >50% then the target executes.
Ok that’s kinda the same thing…I know it’s a big what if…but that proposal could get 50% of total VP for it…so how would that make sense?
You could potentially end up with a small group (equal to 1/3 VP) just aggressively vetoing everything, right?
And how would that proposal being permanently blocked actually be enforceable? What would stop people from raising other proposals and voting to accept?
I understood your first clarification, but you second clarification just made it even more complicated. I’ll stand by my main points:
Super majority shouldn’t:
This is an interesting idea. Will you please expand on the details. Have you posted this elsewhere in the past?
No…it just kind of came to me last night. I think people just want recourse if something cray-cray comes out of left field. 98% of the time we want the happy path.
Since code changes are the only way to actually do anything until it is codified into its own on-chain executable topic we have to work on that basis. We don’t want a super-majority for font changes on the NNS, but we do want to be able to block big changes when necessary.
Thus a veto buy a super-minority instead of a super majority.
Example:
Alice proposes to mint 5,000,000 ICP to be distributed to Synapse members in proposal 989898 by adding a line of rust code that mints the code in the nns ledger canister with wasm 383838838383.
Bob invokes a veto of proposal 989898. It needs 1/3 voting power(total VP) to pass.
Synapse is able to get 51% VP, but the veto gets 40% to veto. (How does this happen…maybe crazy following relationships…strange timing…etc).
There isn’t an actual difference between needing two-thirds to pass and having a 1/3 veto if everyone is online and paying attention, but in a real messy world…and one with difficult narratives, it could be much more flexible and less contentious.
Yes…a cabal of 1/3 could block everything under this scenario. But 1/3 of malicious nodes can stop the blockchain too. Maybe this isn’t a great idea, but we may have to pick if having a possible 1/3 blocker is worth the spirit of making sure some things are hard.
Voting participation displayed on the dashboard is is total voting power cast on the last governance proposal divided by the total voting power that exists in the NNS. The current voting participation value for governance is 50.82% including the vote by DFINITY (because they voted).
Simple math…
50.82% * 2/3 = 33.88%
If you want to define super majority as exceeding this 33.8% threshold of Yes votes, then I believe it is an impractically high threshold. It requires DFINITY to vote. In fact, it requires all neurons who voted on the last governance proposal to vote on an tokenomics change even if they prefer to abstain. Any large neuron that believes there should be zero changes to tokenomics can choose to follow on the Governance topic and unfollow on this new Tokenomics topic, which immediately biases the threshold to a value more stringent than 2/3.
As an example, Arthur’s neuron currently triggers 5.8% VP and follows Synapse. Synapse triggers 10.9% including Arthur’s neuron because he follows Synapse. Yet he has gone on record saying that he believes there should be no tokenomics changes. He can assert his will on the NNS by making it 5.8% more difficult to pass a tokenomics change by ensuring he never votes on the Tokenomics topics. Now imaging many genesis whale neuron adopt the same practice. They don’t have to vote No…all they have to do is Abstain because the definition of success for a Tokenomics proposal is based on the scorecard of Governance voting participation.
Hence, I see this as an impossibly high threshold for the definition of super majority. This is starting to feel more like an underhanded attempt to gatekeep NNS changes, which would be terribly disappointing. I would appreciate if you will be more explicit on your definition and where you are getting your numbers. The dashboard does not define a specific term called total available voting power. It defines Total Voting Power and Voting Participation on Governance topics.
An example of how impractical the definition so far…
33% Yes - 0 % No and the Tokenomics proposal Fails because it doesn’t exceed the 33.88% threshold that is set based on the last result of a Governance proposal.
Show me where I’m wrong and I will edit this post accordingly. I want this proposal to be practical and I want it to pass, but not if this is your definition of super majority.
This seems like an idea worth exploring further. I guess a Tokenomics proposal would need to not be implemented immediately so there is time for a veto proposal to surface. I see nothing wrong with this because I do believe tokenomics changes should be carefully considered, transparent, and take time. I’m all for practical solutions that lead to the happy path.
That’s what I thought you meant originally when we discussed this on Taggr. So 2/3 of Total Voting Power (dashboard definition) voting Yes on a Tokenomics proposal would be a 66.6% threshold that has never been achieved on any Governance proposal since it was removed from All Topics. It gets me back to my concern that this is an impossibly high threshold.
If that was your original point then why did you go on some tangent about governance voting that I never mentioned?!
Yes, it’s harder to pass than the current ~50% which only needs Dfinity + 3%. That’s kinda the point…we don’t need to rush changes.
This is why I also said 30 day voting period (with manual override throughout). This pushes more decentralization than the Dfinity +3 and requires more community engagement.
Are you against more decentralization and community engagement in order to get changes (specifically ones that impact tokenomics) passed?!
Your numbers don’t add up and they are impractical either way. My point is that you should propose something reasonable if your goal is meaningful change. Otherwise it seems you are wasting everyone’s time.
What numbers don’t add up? Dfinity/ICA have 22.6% of the voting power so they only need 3% to vote with them to pass something at current rate of ~50% for governance proposals.
I’m just saying it’d be nice if they needed a little more than 3% and it would be great if proposals required more community engagement to pass.
So what % of Total (available) Voting Power do you think is reasonable? 60%? 55%?
I gave my suggestion for a Super Majority definition in a previous comment, which is a modification based on our current definition of Simple Majority. It evaluates super majority relative to total voting power cast.
I don’t believe the threshold for approval of a Tokenomics proposal should be relative to Total Voting Power except to maintain the Absolute Majority definition that currently applies. It should be relative to voting power cast like it is today with the Simple Majority definition. I would be completely fine with changing from 50% to 2/3 majority if it is a comparison relative to voting power cast, but not if it applies relative to Total Voting Power. This distinction is really important because of the fact that we do not have full participation in governance.
It seems like a useful exercise to look at how these definitions would have applied to a few examples of past Tokenomics related proposals:
Proposal 34485: Changes to governance proposals and voting reward weights
Proposal 55651: Periodic Confirmation of Neuron Followees
Proposal 70015: Tactical fix for spam
Proposal 80970: Spam Prevention - Convert from system-based rewards to voter based rewards
Proposal 86639: Temperature Check: NNS Treasury
Good summary…I agree none of those would’ve achieved 2/3rds of total voting power…and that’s kinda the point!
But we aren’t talking about retroactively changing anything but whether going forward we should protect against unnecessary changes by requiring more voting engagement.
The penultimate point here is that it would give people more confidence in staking if they knew it would be difficult to change tokenomics in the future…
Finally, I do hope Dfinity reconsider/deprioritize the spam prevention proposal since as you mentioned we already don’t have spam!
Do more research , show more numbers or you are just blabbering with wpb all the time . Wpb think way ahead of you . While you are just blindly throwing stuff that makes little sense. Hope this can stop.
66.6% did any proposal passed that threshold before without dfinity voting ? If dfinity were to vote people will start to complain again.
I agree regarding Proposal 80970 . I would prefer that we re-evaluate the need for implementation of that proposal.
I don’t agree regarding gatekeeping NNS Tokenomics changes with these impossibly high thresholds. Tokenomics exist to incentivize participation in governance and is fundamental to decentralization for the IC. Tokenomics changes should be hard and well considered, but they shouldn’t be impossible and it should always be a decentralized decision.
I don’t see how this is gatekeeping at all…it’s ensuring the community is sufficiently engaged in order to get changes done and ensuring further decentralization from the current structure of Dfinity +3.
Also, I haven’t suggested a time frame for implementation so maybe it’s a future target as we strive to make these changes more challenging over time.
Start with 55% then 60% then 2/3rds over the next year or something…
I seriously don’t like the idea of only needing 2/3rds of 6% of the VP…I think this puts too much control with Dfinity.
Think about how hard it would be to get to 2/3rds if Dfinity voted against? You would need +45% of the voting power it would give them pretty much unlimited veto power on everything.
I fully trust Dfinity at this time but I think these checks and balances need to be in place to ensure they 1) need more than 3% to get things passed and 2) don’t have complete veto authority.
Again, as I mentioned to Austin…all this is considering that Dfinity can raise a code proposal vote on it and get 99% voting power! So this would be a paper tiger check and balance until people stop following Dfinity on code changes but this is probably years away…
