I’m not sure why I need to keep repeating myself when it’s been explained many times before…I have no issue with cross-SNS DAO-controlled neurons. That is an excellent use case. The issue is an entire SNS controlling one of it’s own neurons.
So go build the canister that can control Followee voting and delegation for the D-QUORUM neuron like @lara already suggested you do several times now. Invite the entire SNS to participate. The people who care will participate and the people who don’t care will not be subjected to the voting process. Form a mini DAO within the DAO of like minded people who believe in your D-QUORUM initiative. Just don’t create a framework that requires everyone in the DAO to vote in these elections for one neuron.
Please note that you’re asking for something to be impossible (the DAO being able to use or dissolve any neurons that it owns). I’m simply asking to proceed with the suggestion for this to be possible. Any SNS DAO can then make of that what they will. Only one of these two stances represents the imposition of someone’s will.
Please also note that Lara had two suggestions, the first one being a native proposal topic (how else is the DAO supposed to use neurons assigned to it - the governance canister has a principal after all). Please also note that this would be very little work.
Regarding @Mico’s suggestion, it was about having a community owned neuron that anyone could contribute WTN to, the ICP rewards of which could be used to fund regular expenses, such as cycles. Another one is funding reviewers, such as @Quint. WTN has a fixed supply, and cannot be used for community grants forever. That’s not the case for ICP yield generated by a voting neuron that community members can donate an initial allocation of WTN if they so desire (the ICP will keep flowing).
There are many use cases for such a neuron. WaterNeuron is just one SNS. Please stop trying to impose your own opinion on what any and every SNS is capable of doing.
The WaterNeuron DAO does not own that neuron. You created that neuron with the WaterNeuron governance canister as the controlling principal and set the Followees to be the WaterNeuron dev team on every topic. You did this after trying to mobilize the active WaterNeuron community around the D-QUORUM WTN neuron concept without finding any interest. So you took it upon yourself to remove your own ability to control the neuron so you could start calling it a WaterNeuron owned neuron. It is now a bricked neuron that does nothing more than follow the dev team. They have no control over the neuron. The dev team is perfectly capable of creating and configuring their own neuron, which they have done. It’s disingenuous at best to call this a DAO owned neuron. Nobody wanted it except you and nobody asked you to hand it over to WaterNeuron governance canister control.
How many different ways does @lara have to ask you nicely to move on with the canister approach?
Good. So why don’t you start over with your D-QUORUM concept except this time either build a canister that has all the functionality you want to enable umpteen thousand people to control it…or simply use the functionality that already exists today with tools such as orbitwallet.com. An orbit wallet canister can control the neuron and you can set up multi-signature control for performing calls of manage_neuron methods. Come up with something that works today and roll it out to those in the WaterNeuron SNS community who want to participate. There is nothing stopping you.
I don’t have a stance on the topic, and I’m not actually going to respond beyond this, but I’m tempted to ask, so feel free to indulge or ignore; is Codegov state sponsored if it’s DFINITY funded?
This is a fair question @Accumulating.icp. Perhaps we need a NNS controlled treasury to fund public good. I wish someone would have thought about that a couple years ago. Or maybe the right answer is an inflation based remuneration model to incentivize technical proposal reviews.
Given the multi-year evidence that zero incentives produces zero contributors, perhaps it’s time to get serious about what incentives are required to motivate people and organizations to contribute to governance at the protocol level. It’s not volunteer work for sure. The grants CodeGov has received as well as the new Grants for Voting Neurons program has proven that people will do the work if their efforts are funded appropriately. Addressing funding beyond just DFINITY grants seems like a logical next step to advance decentralization.
Yes, I’m sure anyone who executes a significant portion of the vote would be in favour of a treasury controlled by that very vote, to be contributed to by all and withdrawn by some.
But maybe I’m misremembering
With that being said, I think it’s a pretty straightforward solution;
Misremembering is not the right word. Misunderstood is more accurate.
Regarding your proposal…I’m not opposed to it. I’d like to see more discussions along those lines. Without proper incentives, there will never be full decentralization.
That post was a start of a conversation. A basic topic was presented along with examples of pros and cons. The intent was to ask what people think. If you interpreted it as anything more than a proposal asking if we should talk about it further then you certainly misunderstood.
This is turning into a very productive discussion.
I personally feel that an NNS treasury would be open to abuse, particularly given the centralisation we’re seeking to address. I think the fact that the NNS can mint ICP also makes a treasury largely redundant. Inflation based renumeration makes sense though.
This is how node providers are incentivised, and it appears to have worked very well so far. Network security depends just as much on diligent voters as on reliable node providers. A lot of work goes into tracking that node providers are doing a good job, and rewarding them accordingly. That’s not currently the case for voters, largely because there’s usually no such thing as a correct vote.
I think there are other aspects of the node provider workflow that would work well though. The fact that onboarding node providers comes down to a vote, and the quality of the node provider is taken into account in context (e.g. where are the node locations, and do they sit well with current needs).
A parallel can be drawn between onboarding node providers and electing reviewers (ones who can convince the NNS that they are reliable, skilled and diligent).
I personally think it’s done such a good job that it should be formalised into the NNS, in the same sort of way as node providers are selected by the NNS and rewards periodically minted to them by the NNS. Re-elections would make the process competitive, driving reviewers to push the limits and keep sharp.
I fully agree and hope this is where we are heading. I’d like to see more people in the community talking about these kinds of governance incentives, especially if we truly value decentralization. I really like the parallels you are drawing with node provider remuneration. It’s a great model.
I agree minting ICP is redundant to a NNS treasury, but I don’t really see them as different from each other. The framework that would have to be built to incentivize public good and technical governance participation would require new work processes, NNS voting, and community oversight either way. To be honest, I don’t really care which method is used as long as technical proposal reviews and protocol level code contributions some day become an incentivized way to actively participate in NNS governance. Inflation based remuneration make a lot of sense to me and may not stir up as much discomfort as a treasury.
Even though this thread is now on a bit a different topic, I just wanted to provide the following update to avoid misunderstanding where people are waiting for a feature that we are not currently building (as this was also coming up in multiple conversations). We discussed this internally and don’t plan to prioritize changing the SNS as was proposed here.
Extensions and additions to the SNS framework are great and the SNS framework already provides a lot of flexibility to integrate them (e.g., via canisters that hold neurons, generic proposals…).
The SNS features that we have on the roadmap are in our opinion higher priority as they can only be done in governance and as they are requested by a lot of SNS projects and SNS voters.
