Preface
I don’t want to be involved, argue back and forth or debate - I wanted to raise this for the people here to do so
I’m raising this as I believe its the core issue that lead to the fracture of the community and addressing this will add a much needed layer of stability and remove need for trust
I don’t have the ability to put this into code but I am in sincere belief this is in major benefit for Dfinity as an organisation to lead and address this problem
Problem
Tokenomic changes have dire and extensive consequences across ICP including:
Project treasury management
Personal investments
Potential investor perception
Public perception
Investors and builders value a stable environment to build in - this is recognised by Dom clearly since I read his tokenomic change proposal early on in the year so feel we’re on the same page there
However, it is concerning that something with such dire consequences, that does not NEED changing on the regular, can be changed with such ease
While I don’t think we need to work exactly like ETH does, Tokenomics is a great example of where ETH shows us how it could be done - A Super Majority (Tried to find doc to explain this - might be able to provide later on how its done)
Potential Solution
create a new proposal type called tokenomics which will be separate from governance proposals and is only for changes to tokenomics
make the voting period on these proposals 30 days (this assumes manual overrides are in place for followed neurons)
in order to pass it requires 2/3rds of available voting power be executed
Personal and final thoughts
The above can be modified however we wish, aim is not to solutionize the problem but to give a framework to get to the final solution via discussion
If this leads down the road of - “Is this even a problem?” I don’t know what to tell you. From where I stand its the most OBVIOUS and IMPORTANT problem for ICP and Dfinity to address to encourage adoption
What I would like to see is this being driven to a conclusion with a solution that doesn’t leave the future of Tokenomics fully in the hands of Named Neurons - to return confidence current and potential stakeholders
Thank you for taking this to the forum, very well written post!
I’m generally in favor of a version of this. Haven’t yet heard arguments why this wouldn’t be a good idea, so I’d love to see discussion around the topic. The only danger I see is if the % of voting power who votes on proposals doesn’t increase, that would mean no tokenomics changes will ever be implemented, which is also not what we want.
Currently only 50% available voting power votes. I suggest coming up with thresholds that still allows for occasional tokenomics changes if the majority agrees. Let’s say at least 50% of voting power particpates of which at least 66% adopts the change.
Thank you for raising this idea in a diplomatic way @theguy. Well done.
I would support this idea, especially points 1 and 2 as written.
However, I think point 3 would cause this type of proposal to fail as written since we don’t have 2/3 of available voting power voting on Governance topics yet. If you change the content to a practical requirement then it will strengthen the proposal. I have copied the definition of Simple Majority from the dashboard and modified it to reflect a potential definition of Super Majority that hopefully meets the intent of your proposal.
Super Majority: When the voting period ends, a proposal is adopted if a super majority (more than 2/3 of the votes cast) has voted Yes and those votes constitute at least 6% of the total voting power. Otherwise, the proposal is rejected. Before a proposal is decided by Super Majority, the voting period can be extended in order to “wait for quiet”. Such voting period extensions occur when a proposal’s voting results turn from either a Yes majority to a No majority or vice versa.
What do you think?
For comparison, below are the definitions of Absolute Majority and Simple Majority that exist today…
There are two ways a proposal can be decided:
Absolute Majority: Before the voting period ends, a proposal is adopted or rejected if an absolute majority (more than half of the total voting power) has voted Yes or No on the proposal, respectively.
Simple Majority: When the voting period ends, a proposal is adopted if a simple majority (more than half of the votes cast) has voted Yes and those votes constitute at least 3% of the total voting power. Otherwise, the proposal is rejected. Before a proposal is decided by Simple Majority, the voting period can be extended in order to “wait for quiet”. Such voting period extensions occur when a proposal’s voting results turn from either a Yes majority to a No majority or vice versa.
I think this is a good idea because I believe tokenomics changes should be hard, but we also know from experience that deliberating them on the forum is not enough to adequately spread the word about a proposal that is in deliberation. Don’t get me wrong, I do think that a sizable majority of the voting body is paying attention to the forum, but a sizable majority of the community is not interested in the forum. We have many examples of ideas being discussed as short as a week and as long as several months on the forum, but when the proposal is submitted to the NNS there are many people in the community who are caught unaware. The release of a proposal through the NNS creates a heightened sense of awareness within the community and people simply need time to digest the meaning and implications of passing a proposal that results in tokenomics changes. Hence, making it a separate proposal topic and giving more time seems like a good way to ensure everyone knows what is going on and can make informed decisions. I see no need to rush decisions on tokenomics changes.
My understanding is that this is not possible for technical reasons. Seems strange that something so simple isn’t possible but hey it’s what a very senior Dfinity dev that worked on the NNS told me.
Before diving into pros and cons I think we need to have a technical person explain what we can and can’t do and why.
I hat being the downer in the room, but until we get our ducks in a row about how this damn thing actually works, we are going to keep talking in circles.
Tokenomics changes are code changes at the replica or system canister management level.
we have topics for those.
They take 50% to charge.
The system cannot decipher between a tokenomics change and the change in the font color in NNS.ic0.app
If you change these to 2/3 you are changing all code changes to 2/3 and increasing stall points for everything.
Enabling what you are proposing likely requires a fundamental reorganization of what the NNS is. It isn’t impossible, but we need to cast it at the right level of magnitude. The dfinity devs have a much clearer view of how all this works, so I’m happy to be corrected, but I would classify changing voting thresholds to 2/3 in order of magnitude of “blowing it all up and starting from scratch” level of effort. (Or raise the bar on all proposals to 2/3 which would be easy but likely a different kind of discussion).
I think this is a great idea on it’s own so we’re not having the same type of proposals popping up all the time to counter previous proposals. For example a front-end design can be proposed and passed, but then there should be a period of time where it’s not revisited again, unless there is a breaking change perhaps, because it is in a certain category.
Yes…that would work well. Most of the tokenomics proposals have been more substantial than that though. Moving stuff to on chain governance is a good pathway, but not immune to fools like me that come and rearrange the deck chairs.
I think it’s a chicken or an egg kind of thing. If you put all the tokenomics on to a canister that can only be changed by 2/3 majority, then the system, the queries that canister could be changed to point to a different canister by 50% vote.
This is the same pattern that caused the spam issue . Anytime you make something worth more or harder than something else you drastically complicate how your system works.
A better solution might be some kind of bicameral system; or maybe an emergency veto that only requires 1/3 to invoke. That way the happy path is always still 50%, but if something does jump up and have significant changes in it 1/3 of the vote can block implementation.
This would give one third of the NNS power to block any advancement, but we kind of already have that ratio built into our node providers.
There is a precedent for changing the definition of majority voting on the NNS. From genesis until sometime around the end of Oct 21 all proposals were decided by Absolute Majority. Some time in Nov 2021 DFINITY implemented the Simple Majority criteria (proposal ?) and shortly afterward increased the wait for quiet mechanism (proposal 33658) from 1 day to 4 days minimum voting period. All of these changes were needed and I don’t think it required starting from scratch.
There is also precedent for the idea of creating new proposal categories. Replica Version Management and SNS & Community Fund were both created within the last several months. In both cases, the neuron Followee assignments were configured to match the Governance topic configuration by default so people would not be caught off guard without having a Followee configured.
I don’t see why a new proposal topic can’t be created for tokenomics proposals (and possibly other parameters that should be hard to change) that uses an Absolute Majority / Super Majority mechanism while all other proposal topics continue to use the Absolute Majority / Simple Majority mechanism. I would love to hear someone from the DFINITY NNS team comment on the viability of this concept.
It is clear that DFINITY is the only organization that can implement this type of proposal, so it would be best if they are involved in the discussion early anyway. There is no point in the community spending a lot of time and energy on this deliberation unless DFINITY is willing to engage and signal their willingness to put it on their roadmap if it passes. In other words, before submitting this proposal, it would be best to know that there is a path to code implementation (even if the timeline cannot be detailed at this stage).
I like it. When you say 2/3 of available voting power, do you mean of the voting power actually used to vote, or do you mean of total available that could possibly vote? Only concern is that Dfinity gets an even larger role in this issue, since 2/3 will almost certainly require their approval.
Regardless, I support the proposal. Tokenomics changes should be deliberate and debated.
I don’t mean to imply that there wouldn’t be things we could still use, but the founding assumptions would need to be different. As I mentioned…there is no issue if you want to impose 2/3 across the board. The dilemma is when you want to impose 2/3 on one category but code change is still 50%.
I get point #5 which was why I was initially suggesting limiting to just tokenomics proposals but you raise a good point wrt to code changes requiring a simple 50% majority.
Could we just make it 2/3rds across the board with some sort of emergency contingency?
I mean let’s be honest, a vast majority of people follow Dfinity for all things not governance so in theory and practice they have an emergency contingency already… I’ve seen Dfinity raise a code change proposal vote on it which then gets all the follower vote triggered and the proposal is executed within an hour… below is an example…which took a little over two hours from being raised to being executed…best part is… it received 99.4% !
The NNS always reports voting statistics in terms of total voting power, so it adds confusion if you try to redefine terminology. The available voting power is total voting power, not the voting power that is cast on Governance proposal topics. The amount of voting power that is cast on Governance topics changes with every vote. It seems you may be trying to impose an impossibly high standard, which is a non-starter for me. Please bring this back to a more sensible concept. For example, DFINITY should be able to abstain from a proposal on tokenomics and it should still be possible for it to pass. This would happen when DFINITY wants the community to decide a proposal, which has happened often. There should not be a minimum threshold that can only be met when DFINITY casts their vote. Setting a minimum threshold based on prior voting participation rates does not make sense to me. I recommend you take the existing definition of Simple Majority and modify parameters (without changing definitions) it to match your intent.
You seem to not understand what I’m saying so instead of asking to clarify you assume it’s the worst possible interpretation and then start arguing against that
This is the same concept previously discussed.
total available voting power is on the dashboard
I just added the term available because that’s the available VP at a point in time which does not consider ICP not staked etc…as neurons age or ICP is locked/unlocked that number changes
need 2/3rds of this dashboard number executed not in support of
since Dfinity/ICA is 22.6% of the available you’d need 66.7% of the remaining 77.4% which is possible even if it would be difficult but that’s kinda the point, right? However I would hope that Dfinity would support if +50% of the community did.
Also, I added the 33.4% adopted because it might make more sense to do it that way rather than 2/3rds because imagine a minority of people abstaining to prevent it reaching 2/3rds when it’s received +50% of total available voting power.
