Thanks for the feedback. Note that proposals are only executed if their result cannot be changed anymore even if all other voters would still vote.
Maybe with “changing their minds” you also refer to following not kicking in immediately so that people can still choose to vote directly?
This has also been discussed at some point in the context of the NNS. Note that this might require quite some changes to how wait-for-quiet works: in the current design, votes cannot be changed. Based on this, wait-for-quiet takes into account the votes for adoption and rejection and increases the voting period if the results flips back-and-forth - so if the proposal is controversial. This also holds for voting more generally: the trend of the vote is currently always clear and voters can adjust their behavior accordingly - which I think is a big advantage of the design.
One easy “solution” for ensuring that neurons can vote directly is that followed neurons can change their behavior to facilitate this for their followers: They can only cast their vote after a few days. This allows their followers to have enough time to vote directly if they wish to do so and at the same time followers can be sure that a vote will be sent if they didn’t get around to it in these days. Neurons that behave this way could be favored to be followed by other neurons.
How about we start with 5 days and try it out? We thought this is a nice compromise between having a bit more time but still being able to also wait for 2 proposals if this should be needed with the limits.
Once this is parametrised, it would also be easy to adjust these numbers again if the community thinks that with new learnings something else makes more sense.
I would also like to note that there is also the wait-for-quiet algorithm that makes sure that if the proposal is controversial it will automatically have a longer waiting period of up to 10 days. This is the main idea of wait-for-quiet: if a topic is controversial, the voting period will automatically be increased. On the other hand, if the result is very clear and there is no need to wait longer, the algorithm allows to make faster decisions.
Thanks for this idea.
As mentioned in another answer above, there are also quite some downsides to waiting with following until the end, so I think this would have to be carefully considered.
As also mentioned, followed neurons could be encouraged by their followers to wait longer with voting so they have the opportunity to case a direct vote.
Known neurons are there to ensure voters always get their rewards, not to remove their will.
I slightly disagree with the first part of this statement. Even though some neurons might use it this way, one of the main goals of following is also that a neuron can follow different experts on different topics. It is in every neuron’s interest to vote in the best long-term interest of the IC. Therefore, a neuron should always trust the followed neuron to make good decisions.
Of course it could be that there are scenarios where neurons gain more by the voting rewards and so they don’t care about whether the decisions were good or bad - but I think the design should not incentivise this kind of thinking but rather incentivise neurons to make sure whoever they delegate their vote to will make a good decision.
Thanks for this feedback. I better understand now that simply controlling time could lead to more harm than good.
After a bit of reflection I would argue that the root problem is the lack of “experts to follow”.
That is the “though nut to crack”, and if the SNS framework (and swap) can solve it, that could be a big boost in terms of success and reputation.
Think the end goal is that on any SNS swap end, it comes with 3 known neurons for voters to choose from. There is a “minimum guarantee” that is given by the SNS swap process (on the proposal it could have a field to add 3 known neurons). Later more known neurons can be onboarded.
How each project picks them up and rewards them (vested tokens), is entirely up to them. The NNS/Community can then judge if they look like independent parties and that they have the expertise to vote on the proposals.
I wouldn’t be surprised if it emerges a pattern where one known neuron is the dev team, another neuron is a reviewer/security auditor, and another one a community elected governance neuron (more for gov / treasury proposals review/consensus).
With this minimal setup, then SNSs can be more functional, more decentralized and with the right amount of tension / distributed work.
So, wrapping up, we desperately need the known neurons concept
Thanks for listening, kindly request feedback, from both Lara and community
Thanks @tiago89 for this idea!
I agree that it would be a useful goal for SNSs to get more “experts to follow”.
I see the motivation to embed this in the SNS launch process, but wonder if this is needed. Any SNS launch is approved by the NNS community, so if the “good practice” emerges that an SNS should have at least 3 initial neurons to follow, then the NNS could just reject all SNSs that do not satisfy this. However, leaving this to voting would also leave the flexibility for exceptions in case where an SNS project can convince the NNS voters that it is justified.
In terms of the “known neurons” concept: we do have it on our roadmap to also look at this for the SNSs, but don’t have a clear plan yet when this will be done.
I also think we should keep it simple and adopt one of two methods to address this:
One solution I like from another thread posted by @EmrahCoskun:
“Might I suggest considering a dynamic threshold based on average participation over the past three months, yet never dropping below 30% of the actual total voting power? It seems a fair compromise.”
or
.
I think there should be limits per weeks.
Can we get a notifications tab on the NNS tab that says something like “Your followed Neuron “blank” has voted on X proposal”. The followee can go look at it and have the ability to change their mind otherwise if no action taken then the vote is cast. Maybe cumbersome with notifications but give people the option to filter or turn them off as well perhaps. Also maybe delay the the vote 24 or so hours or until voting period ends whichever come first.
Lots of great ideas discussed in this thread. I like the last revision to the improvements for these types of proposals @lara
While we understand that the concern is mostly regarding ICP being withdrawn here, please consider scenarios where SNS projects need to distribute their own tokens from the treasury as well. For instance we may plan in the future to offer a developer incentive program where we grant tokens to other startups / projects that integrate with us. Ideally this would be done through treasury proposals but if there is too much friction here we may not be able to offer this program.
