Named Neuron Proposal - Always Votes

@cryptoisgood @Accumulating.icp

The scenario of gaining more than 50% seems so unrealistic to me that it’s not really relevant. The foundation controls pretty much 100% of the voting power on other proposals. The most contested recent proposal like the community fund had only like 25% of the voting power. Big investors are really not going to follow to this neuron they are better off sending an email.

@EasySteve

In the FAQ I mention waiting till the end of the voting period is possible and that I want to go in that direction. Absolutely fine with only making the named neuron proposal only when that is the case.

Fine with waiting for a bigger voting history as well. Note that there is only 100 of ballots saved on the neuron though. To verify a bigger history we will need a third party to make screenshots or the dashboard or something for the ones that got deleted.

/// The maximum number of recent ballots to keep, per neuron.
pub const MAX_NEURON_RECENT_BALLOTS: usize = 100;

The question is would any credible devs like you be willing to put in the effort of verifying this code? I would be happy to collaborate in a public repo but this takes time and effort and we would need to await those features.

I’m personally wouldn’t like to wait for outgoing http request, threshold EDSA and the writing of that complicated code. I would also rather have neurons just be owned by canisters if people are willing to go through alternative hoops. Proposal: Remove the is_self_authenticating restriction on Neuron Ownership - #23 by domwoe

I personally feel like there is a hurry because the fact the foundation doesn’t seem to take it like a signal at all that some of these proposals like maturity modulation or Community Fund that get rejected by all community neurons and barely make it and are still being pushed through. I would like for this neuron to exist before there is another contentious proposal.

I just scanned the forum a bit and we could also create a neuron like this:

Then have the following setup

Have you me and another trusted community dev setup a 2 out of 3 following relation for the manage neuron topic and have it follow my proxy neuron with the lambda function.

This way we would have checks and balances where the most important base neuron would be controlled by established community devs. The proxy neuron would be controlled by me and the lambda function. And we would have a roadmap towards fully trustless in the feature by adding a hotkey to a canister later.

I really don’t think having it not fully trustless from the start is a major problem because any yes vote wouldn’t hold any weight from a neuron called Always Reject. I’m not looking for power as their is no power with such a neuron. So I’m happy to hand over control to more established devs so I can stay anonymous.

If you would be willing to work together on this that would be fantastic, but I can imagine you don’t have the time. I’m already a bit demotivated at this point as it is far from clear whether it would pass with this additional effort .

4 Likes

Don’t be. You are clearly dedicated and processing something important at least for you and probably more. To me, it is far from clear that it would not pass. Thank you for this wide and brand new field of thought you submitted to everybody.

Be aware that I would vote in favor of it.

4 Likes

First off don’t be de-motivated. Personally I would vote in favor of this as it is now. I was simply providing some feedback on possible areas of improvement.

All in all great work.

3 Likes

Thank you for engaging in the deliberation on your proposal. I am becoming much more comfortable with your new anonymous identity because it is clear that you are an active participant in the IC ecosystem and governance discussions. I also appreciate how thorough you have been in scoping your plans and providing the justification. It has quickly elevated your credibility. I think you are addressing my two biggest concerns by changing the neuron name and by letting the community get to know you through this deliberation.

I think you are right that there is no credible scenario right now because all protocol changes happen in proposal topics that fall under All Topics Except Governance. However, my concern in bullet point 5 above was in reference to the day that individual topics are removed from All Topics since there will likely be far less total voting power casting votes until neuron owners are incentivized to select a Followee for that proposal topic (and since DFINITY voting power is going down daily). I recognize that your rebuttal was that we have no idea how proposal topics will be decentralized. However, I’d prefer to plan for it happening the same way that Governance was partially decentralized. There have not been any other ideas that have surfaced on how to decentralize individual proposal topics and it seems likely that they will follow the same model as Governance. Working with that assumption, can you programmatically stop voting NO to proposals when that proposal topic no longer falls into the All Topics Except Governance catch all category? Can you routinely scan the NNS code and look for the proposal topics that are included with All Topics? If the proposal topic is removed, would you be willing to change your automated action so you no longer vote NO on protocol changes? It would be helpful to know that your open source code has this feature.

1 Like

I see so an example of your concern is:

  • DFINITY removes the Network Economics Proposal topic from All topics besides Governance
  • A much smaller pecentage is voting on this now
  • Such a small percentage that Always Rejects now blocks any proposal

Honestly I would be wildly against such a thing happening. Doing this with motion proposals that don’t affect anything is one thing. Doing it with a topic that actually affect the protocol in such a way that this scenario seems even somewhat likely is bananas. I would be happy to be a detractor to such an idea.

I think everybody is far too eager to make changes to the NNS that affect staking or the way voting works. In any proper democracy there are checks and balances so that you can’t just affect the way the governance system works with a simple majority. Doing what you are suggesting should never be done in a way were people who were following the foundation are unfollowed.

3 Likes

I don’t think blindly rejecting every proposal is constructive for governance, so I’m not in favor of this as a known neuron and will vote to reject.

2 Likes

I like the idea, good lateral thinking, so I will vote to accept, though not sure I will follow. The conversation does bring up the fact that established named neurons now have some interest in blocking other named neurons to the extent that they are competitors for followers.
Perhaps we need a separate named neuron vote category which is reward-free, so nobody loses for not voting on it, but also accepts only individual votes rather than automatic ones. That will prevent block voting and level the playing field a little.

2 Likes

If I assume the best case scenario, stakeholders would only follow this neuron when they’ve lost faith in the network. This could be an interesting way to gauge sentiment. It would be interesting to see how quickly this neuron gains or loses VP over time.

2 Likes

@bjoern

Is the neuron from this post How to create a decentralized community neuron still available? I would love to just use that one instead of going through all those steps.

3 Likes

I will update the script to only vote at the end of a voting period before making my proposal so everybody can vote manually.

2 Likes

Indeed, no one has claimed that neuron so far.

TBH I am not entirely sure about the gains from having this decentralized setup for your proposed neuron:

  • The decentralized setup primarily makes sense if your organization consists of multiple people and you want to make changes to the setup of the neuron by threshold voting. If you control this neuron through a single other neuron, there is really no advantage in doing so.
  • If your neuron votes automatically through a script on AWS, then the voting (which seems to be the important part here) is centralized anyway, even if you had multiple people controlling the neuron.

To me, this seems to be a case where the “right” setup seems to be:

  • Have a canister control the neuron.
  • Instead of hosting the script on AWS, build the same functionality in that canister.
  • Give up central control over your canister by (a) blackholing it, (b) putting it under DAO control, or (c) letting the canister control itself.

That said, if you think this is the proper setup for your neuron, I don’t mind sending you the one I created. Just send me the id of the neuron that you want to control it with, and I’ll configure it so it’s from then on exclusively controlled by your neuron. (And you can then again change the setup so that it’s controlled by multiple independent neurons.)

Note that the NNS frontend dapp currently does not support neuron management proposals, so you’d need to be able to use your existing neuron from dfx or ic-repl in order to send management proposals.

Have a canister control the neuron .

Is the foundation going to enable this without using EDSCA and outgoing requests soon?

I was thinking the community neuron that you created could function as the basis for a decentralised ownership in the future.

So initially I would be the only followee on the manage neuron topic and it uses AWS lambda, but I think this way it is possible to make it progressively trustless in the future by:

  • adding more neurons to “Manage Neuron” topic making it act as a sort of neuron multisig
  • Change the following of other topics to a blackholed voting canister later.

Would this be possible?

They haven’t really commented yet . :eyes:

1 Like

That is possible.

A neuron cannot literally follow a canister, but the canister could be registered as a “voting hot key” for the neuron so the canister could cast votes.

It is possible to change the “voting” neuron to being fully controlled by the canister in the future: create another neuron that is controlled by said canister, then set up “voting” neuron management to follow the canister’s neuron, so the “canister” can control the voting neuron indirectly. It’s just a bit more complex than it would need to be, and each manage neuron proposal costs 0.01 ICP, but that shouldn’t really matter since I’d expect hardly be any changes to the neuron configuration in your scenario.

The proposal here:

Is indeed from me. I wanted to bring this named neuron fully onchain first, but decided that perfect is the enemy of good.

I think taking the noise out of motion proposals is by far the most important purpose of Always Rejects. And since motion proposals don’t affect the protocol directly it seems safe to have the automation running on centralised infrastructure.

If I ever vote Accept you can disregard the voting power that came with it. I updated the FAQ on my website but couldn’t edit the forum post anymore.

2 Likes

Thank you for naming your neuron Always Rejects instead of Always Votes. I appreciate your reasoning behind why you want this named neuron and the compromises you are making so it can happen now. Makes total sense. I could never follow a neuron whose purpose is to always reject, but I also don’t think it’s my place to stand in the way of anyone else who is attracted to the voting policy you are offering. I will vote to accept your named neuron proposal.

More details of my opinion can be found in my post in the Synapse realm on Taggr.

https://taggr.top/#/post/9609

4 Likes

Thank you Wenzel! I appreciate you being open to other named neurons with political differences

1 Like

In the proposal it says

I decided in the end that I would rather have the automation run every couple hours so that if something goes wrong I still have days to make sure the neuron votes on everything.

I think this use case that you give:

This neuron also originally had the purpose to offer a way for people to default reject unless they want to vote Accept manually themselves.

is very useful but impossible if the neuron votes already after a couple of hours. If you automate it through a canister then (I guess) you can achieve automatic voting towards the end of the voting period.

I can update the automation later to check the proposal time and only vote after 3 days. However I think voting on every proposal is the most important promise for most people. I would want to add some extra redundancy before going that route as I would only have a day to notice if something went wrong.

I don’t really have the time right now to put in that extra effort. In the meanwhile I think the current setup could still be valuable as people seem way too eager at the moment to change tokenomics and are making the wildest proposals.

Which recent tokenomic proposal do you consider wild?

There are no current tokenomics proposals.

The last one that passed was proposal 80970 and it was well deliberated over a reasonable timeframe and passed 49.4% approve to 0.4% reject. Hence, it doesn’t seem the governing body thought it was very wild.

1 Like