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

Your canister will be able to make request/response transactions on the ETH network. You can mask it behind IC based transactions…or you can program your canister to take in signed ETH transactions and relay them to the network.

it uses normal smart contracts on Ethereum

Ahh I see, yeah huge in that it absolutely reduces the cost of swaps on ETH by a huge factor. Maybe the web3 integrations not that big a deal.

If a Uniswap swap costs about 150,000 gas and we say an ERC20 transfer costs about (40,000 *2) then this would make the cost of transacting about half on the main chain. A significant cost-saving advantage.

Question for both @skilesare @Arthur and any of your fellow members if they want to chime in.

I wanted to ask if there are any types of proposals that your organization might abstain from voting on?

Edit: Thought of a less controversial way to ask my question

2 Likes

(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.

4 Likes

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.

2 Likes

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?

2 Likes

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

2 Likes

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.

4 Likes

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.

3 Likes

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?

4 Likes

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

3 Likes

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?

5 Likes

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.

3 Likes