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