Named Neuron Proposal - Always Votes

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.


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.


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

Was @Always_Votes an anon? It looks like whatever they were using to always reject is out of cycles. I’d imagine a number of folks aren’t getting rewards:


It looks like the last vote of this neuron was 4 months ago.

Lol…ok. Man…maybe we need a better process for these things. :grimacing:

1 Like

I don’t mind submitting a proposal to rename the neuron in a similar way to what @LightningLad91 did for TheFoolsCourt to let people know it’s not an active named neuron.

This seems reasonable IMO:
Inactive (Request Removal) - formerly Always Rejects

If @Always_Votes doesn’t reply to this message in the next couple of weeks, does anyone object if I (or anyone else) submits a proposal that renames the Always Rejects neuron in this way?

The person behind this neuron seemed very familiar with ICP governance at the time. Perhaps they will see this forum topic now that it has surfaced again and be willing to rename their neuron themselves. That would certainly be the best option.

1 Like

It seems to me that currently the ‘Always Rejects’ neuron, which doesn’t vote (and which is hardly watched by anyone) is the least of the problems in terms of governance structure.
Let’s think @wpb about who should be on this official list (or not) but they isn’t on it. I mean ICA and DFINITY, which are displayed in the NNS Dapp, even though they didn’t pass the vote and aren’t even listed in the list of ‘Known Neurons’ in the NNS Governance canister!
They should be immediately removed (I mean neurons 27 & 28) from the NNS Dapp because they aren’t officially registered as ‘Known Neurons’ and (if they want further decentralization) they shouldn’t apply for inclusion by official vote. In this early stage of decentralization they have too much liquid voting power to treat they as one of the ‘possible options’ and not as an absolute.