conflict of interest arise
Given that proposal 70015 appears that it will pass, I would like to revisit this assessment you made for proposal 55651 and ask DFINITY to consider it with higher urgency. I agree with the increasing and decreasing assessments you made as previously indicated in my comments, but I donât agree with the neutral assessments and I now think they are more relevant to discuss. My recommendations are provided in the markup and descriptions below.
Reactivity assessment - I agree it is decreasing because all routine business proposals such as Subnet Managements and System Canister Management have a 4 day voting period and we need Absolute Majority to be executed by liquid democracy of default following of DFINITY to implement them quickly. However, I see nothing wrong with setting the voting period for these proposals to 24 hours (or whatever) and executing them when the timer runs out. Of course, this assumes DFINITY can respond within 24 hours if someone other than DFINITY submits a proposal. DFINITY will cast their vote for or against and they will always execute at the end of that shorter voting period because DFINITY owns far more than 3% of the minimum voting power required to execute a proposal by Simple Majority. Plus a lot of people will configure their neurons to follow DFINITY on these proposal topics anyway since DFINITY is the only logical choice and people want their voting rewards. There is no public review of these proposals that matters today anyway. They are all executed the moment DFINITY casts a vote due to default following and that typically happens within minutes to hours of submitting the proposals. Hence, the enhancement that is needed that changes the assessment of Reactivity for proposal 55651 seems as simple as changing the voting period for these critical proposal topics.
Long-Term Thinking - Active voters are more likely to vote in the long term best interest of the IC. Default Followees enable people who have no interest in long term thinking to share a higher fraction of the voting rewards that are intended to be allocated to people who are thinking long term. Proposal 55651 provides a better definition of minimum active participation. Hence, I donât understand how proposal 55651 can be neutral on this assessment criteria. You assessed proposal 55651 as neutral on Long-Term Thinking, but it seems to me it should be increasing.
Efficient & Scalable - The overall assessment strategy that you designed is intended to compare and contrast all the various proposals that have surfaced to address the spam issue. I see no scaling issues for proposal 55651. I would argue it is equally scalable as the current NNS governance design and that compared to other proposals that have been considered it is more scalable and easier to scale. In fact, once implemented, there is no limit to how much it can scale without any further dev intervention. You assessed proposal 55651 as neutral on Efficient and Scalable, but it seems to me it should be increasing.
Simple and Accessible - Tokenomics are intended to attract and retain participants who want to be actively involved in governance and think in the long term best interest of the IC. Proposal 55651 creates a definition of minimum active participation. All neurons that were created at genesis and in the first year after genesis were set up to follow DFINITY by default in the All Topics category, which means they automatically started receiving voting rewards without having perform any work or make any decision about governance. Itâs a completely passive configuration that the neuron owner did not choose. The definition of active participation in proposal 55651 is extremely simple. It only asks neuron owners to confirm followee selections every 6 months by pushing a few buttons. That seems simple and accessible at scale and actually achieves the intended outcome of the tokenomics of ensuring that people are intentional about their governance participation. Hence, I would argue is is an improvement. You assessed proposal 55651 as neutral on Simple and Accessible, but it seems to me it should be increasing.
Iâd be interested in knowing your thoughts given this feedback. Thank you for considering these suggestions.
3 Likes
This entire paragraph made me extremely sad 
Why do you assume that everyone who left Dfinity as a default followee in the first year, did so without any care for governance? Why are they considered passive voters and those who follow ICPMN, ICDevs, or cycle_dao arenât passive voters?
The fact they have lost potentially millions in missed rewards is a hint.
I donât think thats the case either, without periodic reconfirmation we should assume most stakers set their neurons once and forget about them, no matter who they follow.
2 Likes
A hint of what? If you are a non technical indvidual, with no mind for politics, but you still want to see the network succeed who would you have followed before moving on with your life?
A hint they donât give a damn about following the project somewhat proactively, otherwise theyâd have updated their neurons.
If you fall in this category then you should at the very least check in once every couple months to see whats going on, if you donât want to do that, Iâm sorry but you donât deserve the rewards. I donât care about politics too but I have the decency of keeping myself informed to make somewhat informed decisions and check out what my party is doing. In real life itâd be absurd to entrust someone with your vote for life, so I donât see why it should be an acceptable practice on the NNS where we have an investement at stake and get rewarded for our attention.
1 Like
We get rewarded for contributing our voting power. We can either do that manually, or by empowering a followee. All of these extra definitions and unwritten bylaws that people throw around on the forum is just conjecture until itâs been ratified by the NNS. Proposal 55651 is the first time a reset period has been defined. This implies a minimum level of participation and I think itâs good for the network; but this didnât exist when the follower settings changed.
To be clear, i agree that changing the follower settings was a necessary evil in order to help decentralize the NNS. At the time, it helped break stakeholders away from the foundation.
I am just tired of all these excuses for why it was okay. The most annoying being our attempts to label these individuals as passive or negligent simply because they may take a long-term approach to managing their investments. It also annoys me that we continue to label them and use their behaviour as justification for further change. If our only reason for suggesting a change is because âwe deserve it moreâ then Iâm probably not going to be for it.
I didnât realize a few months was equivalent to an entire lifetime.
2 Likes
If you have millions of dollars invested in an asset and canât even bother to check it out once in a while and even end up losing a considerable sum due to lost interest then I donât want your voting power in the NNS, if you canât even do whatâs best for your own interest how can I entrust you to do whatâs best for the network as a whole? We get paid for providing voting power but this situation has made it quite evident not all VP is the same
Without periodic confirmation it might as well be.
1 Like
I make the assumption that any person who is dissolving their neuron is perfectly capable of meeting a minimum definition of active participation just like everyone else. There is no effort to prevent anyone from participating in governance. Default followee configuration had utility to bootstrap the network, but it is stifling decentralization at this point. In case you have not been paying attention, DFINITY and ICA have voted on all governance proposals for well over 2 months now. They are an excellent choice for a followee, but perhaps even they should be an intentional choice made by neuron owners. We also need more named neurons, which is acknowledged and encouraged by everyone, yet nobody has stepped up to provide new options. I would still love to see The Fools Court in this role. I was very happy to learn that Psychedellic will pursue this role in their town hall recently. There are so many other people and organizations in the IC community that could do the same. Contrary to what you seem to want everyone to think, I by no means believe that active voters only follow ICPMN, ICDevs, or cycledao.
Which part makes you sad? Here is the most recent Subnet Update as an example. Proposal executed less than 1 hour after it was submittedâŚ98% of total voting power in the NNS already castâŚ3 days 18 hours left in the voting period. This is routine business executed quickly and rightly so. Any desire for the public to be able to vote on these types of proposals or review them with capacity to stop them at this stage of the IC just doesnât make sense.
Whose definition? Where did this definition come from and when did we ratify it prior to proposal 55651?
Never said there was an effort to do this.
I agree, see my earlier statement:
Not sure where this is coming from but ok, i donât disagree 
This will be up to the community to decide once weâve achieve a decent size. I am not the end all be all of TFC, nor is @Pwoseidon or @weedpatch2.
What makes me sad is that you want to change the protocol so that thereâs almost no chance for any orther organization to push back on these proposals. What if an organization with the power and competency to challenge one of these proposals chooses to do so? Your proposal would give them an extremely small window to build support and almost guarantee Dfinity the deciding vote.
Just because this is the standard today does not mean we should resign to it always being this way. We changed follower settings in order to increase decentralization; yet, we chose not to do the same for non-governance topics. It doesnât make sense.
What would happen when a bad actor controlling > 3% of the voting power submits a malicious proposal and DFINITY for some reason doesnât vote on it within that one-hour voting period? Your suggestion depends on a quorum of humans at DFINITY monitoring and voting on proposals 24/7.
Iâm in favor of Periodic Confirmation of Neuron Followees, Iâm just pointing out a problem with the one-hour voting period idea.
3 Likes
This is no different than today. You can go to the dashboard and open any subnet management proposal and see that they are executed shortly after they are submitted by Absolute Majority.
I agree. When that day comes, adjustments will need to be made. This is why we have a mutable governance system. Change is necessary and the NNS provides that flexibility. My point is that today there is no chance for any other organization to push back on these proposals, so I donât see the need for the larger voting period window. DFINITY is the deciding vote and there is nothing anyone can do about it today. Nor do I think anyone wants to do anything about it today. It will take time to get to the point where that is relevant.
Would you please clarify further? Are you suggesting follower settings should be adjusted for non-governance topics? Thatâs what proposal 55651 would do. Do you agree with that mechanism or did you have something else in mind?
This is an excellent point. The idea will need additional consideration because we cannot let that happen.
@Dylan I modified the original comment to 24 hours instead of 1 hour. Take a look and let me know if you still see a gaping issue. I suggested 24 hours since that was the original voting period for all proposals. I would think the question that needs to be considered is if we really need to be able to implement changes to these proposal types faster than 24 hours. If so, then the idea still requires additional consideration. Perhaps there is utility in limiting the neuron IDs that can submit proposal types that are of certain critical nature or maybe there is already a limitation on who can submit that code to GitHub. I think my main point is just that we should consider a much shorter Voting Period for proposals where is is important to consider Reactivity. I donât think that Voting Period needs to be the same as it is for Governance proposals.
1 Like
I think a 24-hour voting period addresses the concern that I had about bad actors, but then youâre back to the situation where you may have to wait 24 hours to pass important proposals. Thatâs better than 4+ days, but a lot longer than the current ability to pass these proposals essentially immediately. The ability to pass proposals fast is important. Imagine if some security vulnerability needs to be fixed, and every minute itâs not fixed bad things are happening.
Just thinking out loud, perhaps this concern could be addressed by changing the (proposal 55651) proposed way that the confirmation would work. For example, say that all neuron holders had to confirm their followees once a year before January 1st, but that the NNS wouldnât actually remove followees from any neurons on January 1st unless (or until) a certain threshold of voting power had confirmed their followees. You would then set that threshold in a way that virtually guarantees the effective voting power of DFINITY with following doesnât drop below 50%. In other words, a Periodic Confirmation of Neuron Followees would be implemented, but if not enough neuron holders confirmed their followees, nothing would happen. This way the functionality could be implemented without relying on the hope that neuron holders would indeed confirm their followees.
3 Likes
Though I suppose choosing such a threshold could be difficult.
1 Like
I agree 1000%. Also, I always said that dead voter (or many of them), who could be a whale, providing their vote to make a proposal to pass or not is 100% non sense, and is looking really bad for the entitre governance system. Dead voter need to be eliminated from voting, the sooner the better.
I agree that we should focus the discussion on the criterium reactive, as this is currently the main drawback of the proposal on periodic re-confirmation of followees. So essentially, how can we ensure that very urgent fixes can be implemented immediately.
One possible solution (based on a discussion with @Manu) could be to vote on granting hotfix update permission to trusted developers on a temporary basis (e.g. for 2 weeks or a month). This way the urgency of the update would be decoupled from the prior vote.
@Manu: Did I summarise your idea correctly and would you have further points to add?
3 Likes
I like that idea a lot. It probably opens up the opportunity for the public to perform more code review on non critical updates while still enabling critical hot fixes. Seems like a move toward decentralization.
2 Likes