Proposal to include cycle_dao & ICDevs as default follow-target neurons to the NNS

(Not representing Dfinity here)

I just want to add that I intend to vote accept on this proposal with my personal neurons. More leaders the better.


Copyright. :rofl:

Seriously though…I’m sure we’ll find some good neurons to follow on topics that aren’t relevant for us. Throw out some examples and I’ll try to clarify.

Hey @Arthur and @skilesare this is a really good suggestion made by @cnr. I think it should be easy for users to find your respective websites, know who is voting in your organization, know your voting mechanism, know how you determine when your neuron will vote to Approve or Reject, and know your general principles that tend to influence your decisions. Also, as pointed out by @Manu, you should make it clear to the users how you plan to make sure your neuron is a reliable followee neuron for governance proposals. Otherwise folks could miss out on voting rewards if they are trusting liquid democracy by following your neurons. It would be good to set this up before you make your respective proposals to add your neurons as named options in the NNS app.


Is there a way to do this with the current interface? I know they are working on a new one

Looks like the weights proposal went out this morning.

@Arthur and @skilesare

Now that DF and ICA are going to be removed as default followees for governance topics (as per proposal 34485 linked below), people will start looking for neurons to follow. I suspect cycle_dao and ICDevs are going to become more common followees for many neurons, but both of your organizations will represent special interests. I expect people will choose to follow you because they trust you to vote reliably and in a way that is generally consistent with their beliefs. However, there will be some proposals where people will want to have an opportunity to vote manually with their own brains.

DF and ICA enabled this manual voting by intentionally waiting until the end of a voting period before casting their vote with the majority on roadmap proposals (before Simple Majority was enabled). I don’t expect you to have the ability to allow this voting delay in a reliable way since you lead small organizations and will likely have trouble getting your members to cast votes at a certain time.

Therefore, I would like to develop a proposal in which execution of liquid democracy is delayed until the end of the voting period for all governance proposals. Hopefully it is as simple as inserting a timer in the code. The idea is to enable your neuron to vote as soon as you want, but the automatic part for follower voting to be delayed until 90% of the minimum voting period has elapsed. Would you support this type of proposal?

@diegop will folks from Dfinity please offer input on this concept? I would like to know if there is any specific wording that should be used to ensure that the proposal is easily actionable based on the mechanics of liquid democracy execution. I don’t know the nuances of how it works and don’t want to propose something that makes implementation overly complicated. I feel like this should be applied uniformly to all liquid democracy for governance proposals only.

I am open to ideas on this topic and if there is support then I will start a new forum topic in the governance category.

(Internet Computer Network Status)

1 Like

Yeah…I think it should work this way to give followers the maximum amount of time to vote their own mind. I don’t see any reason to have it not happen at the time of closing the vote. This might ‘swing’ the vote at the very end and that might be bad for ‘image’ and stability purposes, Maybe 90% is fine. How will that interact with wait for quiet?


I am not sure, I will ping NNS team (maybe @lara @dralves @jwiegley @johan have an opinion)


I like the optionality this introduces. It does give a somewhat false read on what’s going to happen once that 90% mark is reached. The majority of following neurons will continue to vote automatically, so it could easily look like a vote might fail or succeed, only to have a stampede of votes near the end of the original period. Sort of like a rubber-band that is stretched and waiting to snap. With the current scheme, the tally is more realistic as votes come in, since any following is taken into account immediately.


Delaying the application of following for governance proposals wouldn’t be that difficult to implement and I would be happy to see a motion about this and have the neuron holders decide if the benefits outweigh the added complexity.

If you want feedback on a draft, just post it here and tag us.

In the meantime, a poor man’s version of this would be to advertise a neuron or neurons that will not vote until the very end of the voting period and neuron holds that want this behaviour can follow this neuron or these neurons. Note that following is applied synchronously, i.e., when a neuron votes all followers that pass the threshold vote in the same transaction.


For the origyn governance system there is a query function that tabulates based on the current follows so one can always see how things will go as of “now.” It just runs the same logic as the finalize proposal but doesn’t execute and returns the result. It may end up being too expensive, but maybe with caching it isn’t. Perhaps this would be easy to add to the NNS?


We could easily predict what the outcome would be if all flowers follow.


I really like this idea

1 Like

I also think that the general idea is interesting and this is especially relevant if we ever choose to give different voting rewards to those who actively vote compared to those who vote by following.

However, I think a few things would have to be considered more carefully and I see one main risk with this change.
Let me start with what I think is the biggest risk:

  • I think the biggest risk is this: currently, as soon as a majority of the voting power is in favour of a proposal, a proposal is executed. I think this is very important for proposals that are urgent, for example introducing fixes to bugs. Following ensures that it is often the case that this majority is reached quite quickly for important decisions. However, if we didn’t apply following immediately it would be extremely hard to mobilise so many voters that we reach a majority. Thus, most of the time we would need to wait at least 90% of the initial voting period, which is 4 days, to be able to execute critical proposals.

Due to this I think we should be extremely careful with such a change.
I agree with @johan that a simple solution to this problem could be to promote neurons that delay their voting a bit for proposals that are not urgent.
In addition, as a neuron holder I could:

  • set following for those topics where I acknowledge that decisions might need to be done quickly (e.g., for upgrading replica and NNS canister), but not set following for other proposal topics e.g., motion proposals and other decisions.
  • plan to look at the NNS frontend dapp every few days and then vote on all proposals to get my rewards. (Note that if a proposal is decided before the voting deadline because of a majority of yes/no votes, one can still vote to get rewards until the voting period is up).
  • in busy weeks / during holidays etc, activate following for all proposal topics not to miss out on rewards

In my opinion, being able to distinguish following for urgent and less urgent topics and applying this behaviour is actually one of the main advantages of having the possibility to set following based on proposal topics.

Other things that I think should be considered:

  • The change would not be quite as simple as “inserting a timer in the code”. We would need to change the voting algorithm, since as @johan mentioned, currently whenever a vote is cast for a neuron, the following is immediately triggered for all followers of that neuron.
    Any code change comes with some efforts and risk so this must be weighted against the benefits.

  • It would have to be defined carefully how this impacts wait-for-quiet (I just saw @skilesare already mentioned this above and I agree). Wait-for-quiet considers how the voting result develops to make decisions on whether the voting deadline should be increased. Would this now consider the “real” result (i.e., withouth following) or would this consider the result taking into account the following that has not happened yet? Also, how should these rules be applied to the following in the end? Would we evaluate whether the result turned/the voting period should be increased for each vote that is cast or only after “the full block of all following votes” have been added?

  • Smaller detail with this: how is “90% of the voting time” defined if the voting period is dynamic?


Thanks for your comments @lara. I’d like to know a little more about your concerns, as well as actionable solutions, after providing a few clarifications below.

I’m envisioning this manual voting period to apply to Governance proposals only. All other proposal types do not need to be delayed. Does this address your biggest concern?

The delay timer I proposed is relative to the minimum voting period, which will now be 4 days. This value is not intended to be changed by W4Q. I may be using terminology that has specific meaning in the W4Q algorithm, but my intention is for the manual voting period to be fixed for every proposal.

If the minimum voting period (previously 24 hrs; now 4 days) changes again in the future, then this delay timer should adjust proportionally. I picked 90% somewhat arbitrarily, but it could be 80% or 60%. I just want to give people time for manual voting before their followee(s) casts an irreversible vote for them.

I would much prefer this manual voting period to be implemented by code instead of depending on people to configure their neuron to accomplish this goal. The former guarantees success. The later is likely to fail to meet the objective of this idea IMHO.

I agree that waiting until the end of the minimum voting period to execute liquid democracy will impact W4Q on many proposals. That seems like a good thing for Governance proposals. If a lot of votes are suddenly cast, especially if they swing the outcome, isn’t that a signal that the vote really should be extended by W4Q?

Do you envision the Governance proposal type being executed by Absolute Majority in the future? Does proposal 34485 (part a) make it unlikely for Absolute Majority to happen on Governance proposals? I thought the purpose was to remove default following for proposals on the governance topic and that this would have an immediate impact on the ability of any neuron, including DF and ICA, to quickly and automatically executing liquid democracy to decide a vote when they cast their vote. It seems like a logical next step toward decentralization of the IC, but it also means people will start looking for other neurons to follow automatically. All followee choices represent special interests, which is fine, but it definitely seems like the system should be configured so people can have the opportunity to vote with their own brains first.

I’m really hoping to get suggestions on how to word this proposal in a way that makes it easy to implement programmatically. If you, @johan, @jwiegley, or @dralves have any suggestions then that would be appreciated. My preference is for the proposal to include specific, actionable deliverables, yet still enable creative and robust solutions that are relatively easy to implement.


Thanks for the clarifications and apologies for having misunderstood the proposal: re-reading your question I now see that it was clearly saying “governance proposals”. I think I was reading this as “proposals in the governance canister” rather than “proposals of topic governance”, this was totally my fault.

Does this address your biggest concern?

You are absolutely right, this eliminates my main concern!

If the minimum voting period (previously 24 hrs; now 4 days) changes again in the future, then this delay timer should adjust proportionally

It makes sense to me to apply this relative ot the minimum voting period. This minimum voting period is actually just a constant in the code, so it should be easy to express this relative to it and ensure that it would automatically be “adjusted” if we ever change the minimum voting period again.

One note on implementation: currently the process how votes are processed is independent of the proposal’s topic, i.e., when a vote is cast following is also triggered. If we now changed this behaviour for proposals of topic governance only, this would mean that vots are processed differently depending on proposal topics. I think this can be implemented by an extra check. I just want to point out that this makes the logic of how proposals are processed a bit more involved, which for example might make it harder to argue about and prove security properties. (Just another thing to consider in weighting the pros and cons).

If a lot of votes are suddenly cast, especially if they swing the outcome, isn’t that a signal that the vote really should be extended by W4Q?
Right, I think this could be a valid argument.

I guess I was wondering about the following scenario: Say there are many, close to 3%, yes votes and only one no-vote. However, the no-vote is coming from a neuron that has extremely many followers, so many that all the follower’s votes would add up to 50% of voting power. Now, should we view the actual result 3% yes + 1 vote no as the “trend” or the 3% yes + 50% no (that we know will take effect before the voting period ends) as the “trend”?
One could argue that everyone who knows the algorithm would know that the expected outcome is a no already. This could for example mean that if I want to vote no and follow this one neuron, I might abstain because I know my opinion will be reflected correctly. Therefore, when all the no-votes are then cast by the following that kicks in, we could consider that this is not really a “change in trend” as this was predictable. For this reason, one might argue that the voting time need not be increased in this moment.
What I mean is that we mainly want to increase the voting time to give people chances to react to new trends that might be surprising, but in that case the change in trend was predictable.
Therefore, I think it is a valid option to consider the trend with or without taking the following (even though not applied yet) into account.
Do you know what I mean? Do you think in this scenario only the effective current result should be considered as the “trend”?

Do you envision the Governance proposal type being executed by Absolute Majority in the future?

You are right. I don’t think proposals of topic governance are emergency proposals and rely on the fact taht they can be executed quickly with an absolute majority.
Of course it can still be that some of the future proposals will achieve the majority threshold, but I agree that this will be less likely and we don’t rely on this.


It seems that Governance proposals should be processed differently. Providing an opportunity for manual voting is one reason, but there seems to be other reasons that are being identified in other threads on the forum. For example, a lot of folks are talking about voting thresholds. I suppose if you start processing Governance proposals differently that other proposal types, then you can plan in advance for other types of changes that may come up for the Governance topic.

You provided a good example for why it is important to define the “trend”. I don’t think I have a strong opinion one way or the other at this time. I would probably prefer the side that is more conservative…meaning whatever enables people the best chance of casting votes in the long term best interest of the IC. I think you and your colleagues at Dfinity have been thinking about these voting mechanisms longer than anyone, so I would look for your guidance on the best definition of “trend”.

I really like the idea of displaying Current Results and Projected Results in the NNS app and on the dashboard. Current Results cannot be changed because votes have already been cast. Projected Results will change as more people and organizations cast votes. Hence, people can see the direction the vote is heading in real time…it will help them decide if they need to cast their manual vote to increase the probability of achieving their desired outcome. This seems like very important data that should be readily available.

With the feedback provided so far, I will develop a proposal and post it tomorrow as a new governance topic in the forum to begin deliberation. Some time next week I will submit the proposal to the NNS for voting. Thank you @arthur @skilesare @lara @johan @jwiegley @dralves @diegop for offering input.

1 Like

I only see one tricky thing about implementing your feature idea as stated: we don’t have “timers” in Governance, so there’s no way to say that something should happen once we reach a specific time threshold. What we do have is a canister method, invoked by a cron job, that acts as a heartbeat for the progression of proposals and the allocation of rewards.

If we attach your idea as another feature of the heartbeat, then we could aim for 75%-ish by invoking it on the 3rd day after the proposal begins.

This then happens in a governance function called run_periodic_tasks. The implementation would involve adding a call to a function here that loops through the open proposals, loops through the ballots of each proposal, and checks whether there are neurons that haven’t voted but whose followees have voted. This would necessitate building a followee graph – something we don’t currently have. Building that would be best done with a graph library (petgraph?) which could quickly identify all the “edges” representing votes that need to be auto-cast.

Not difficult, but not trivial either. Might involve a new library dependency to build the graph, so we’d have to monitor the increase in canister code, or hand-roll just the graph handling functions we need if we want to keep it really small.


@lara @johan @jwiegley @dralves @diegop @Arthur @skilesare
As I was trying to write out a proposal to pitch as a new topic in the governance category, I realized that I want to go through one more round of feedback from you here first. It’s a proposal shaped from the ideas that you all have presented in this thread. What do you think? Do you see any technical difficulties? Does it still meet the design intent of the voting mechanisms with minimal changes? A proposal framed in this way would redefine Current Voting Result and would introduce a new calculation of Projected Voting Result.


  1. Do not execute Follower votes immediately…only include votes that are cast manually in the calculation of Current Voting Result.
  2. Create a new Projected Voting Result calculation that accounts for all manually cast votes and all Follower votes that result from liquid democracy.
  3. In the Wait for Quiet algorithm, define the “trend” and make algorithmic decisions based on the Projected Voting Result.
  4. At the conclusion of the voting period, execute Follower votes. Afterward, the Current Voting Result will match the Projected Voting Result.
  5. In the NNS app and on, display both Current Voting Result and Projected Voting Result


This proposal has several implications that I think are desirable, but I’m interested in your feedback.

Current Voting Result will be based on votes that have been cast manually and are not reversible. Projected Voting Result will be a calculation of the result if all Follower votes were cast based on their Followee assignments. By definition, Projected Voting Result will change every time a vote is cast manually. This voting mechanism would force all proposals to be finalized within the 4 to 8 day window of the Wait for Quiet algorithm even if the Projected Voting Result is an Absolute Majority.

When I use the term voting period, I am referring to the total time it takes to execute a proposal vote (inclusive of the Wait for Quiet algorithm) according to the current methodology for how the voting duration is determined. This means the voting period will be anywhere from 4 days to 8 days.

Voters can see the trend of the Projected Voting Results and decide for themselves if they want to cast their vote manually. They will be able to cast their vote manually at any time throughout the entire proposal including after the Wait for Quiet algorithm extends the voting period.

Voters who are not following any other neurons who have voted can still vote at any time throughout the entire voting period.

Neurons that are configured as Followees for other neurons can cast their vote at any time throughout the entire voting period and it will not prevent individual voters from casting their votes manually.

Simple Majority and Absolute Majority will still execute automatically according to Current Voting Results, but Wait for Quiet is based on Projected Voting Result. This ensures that Absolute Majority is only decided prior to the end of the voting period by manual voting instead of liquid democracy. This also enables voters who disagree with a Projected Voting Result to cast their vote manually even if the Projected Voting Result is an Absolute Majority. When they cast their vote manually, it will change the Projected Voting Result and may or may not change the “trend” as per the Wait for Quiet algorithm.

No new timers would be introduced and this proposal maximizes the time for which every voter can vote with their own brain on each proposal, while still ensuring that they can configure Followees when they prefer to allow others to cast their vote for them.

I’m interested in applying this change to Governance proposals, but it could be applied to other proposals as well if you want proposals to be executed consistently across all proposal types. You could use different min/max voting periods for different types of proposals. It works if the min / max is 1 day / 2 days or if it is 4 days / 8 days.

What do you think? Is this feasible? Does it cause you any concerns?


This looks ideal. I don’t know about the technical challenge of implementation but it facilitates individual voting and avoids the invisible time limit followee vote. I love it actually as I usually vote personally because I have a ton of small neurons and one large one that follows cycle_dao. cycle_dao is my fallback voter