Great thoughts!
The issue with Wyoming is that the DAO LLCs require naming each agent and listing them with the Secretary of State. You can’t be part of the dao anonymously. They may ‘fix’ this but in the meantime the SNS would need some kind of “require kyc” switch and a way to enforce that.
Are you sure? My understanding is that it’s just one registered agent to represent the DAO, which is made up of anonymous token holders.
I could be completely mistaken. I was at the Wyoming Blockchain thing a couple of weeks ago and wandered into a talk by https://twitter.com/mdkaufman307?lang=en where he was discussing this.(I think he helped craft the law). He was discussing deficiencies and things they are trying to fix and unless I got the context wrong the DAO law doesn’t override the general LLC requirement that an LLC know who its members are.
Would there be a point in enforcing a design of SNS such that an SNS implemented by a dapp stakes a fraction of the dapps’ funds in neuron(s) in NNS after financing round from investors/community? Decentralization in terms of voting power in the NNS would then increment naturally over time that way, redistributing voting power such that genesis investors voting power would become “diluted” over time? The staked ICP in neuron(s) in NNS would belong to the DAO, i.e. the community/investors of each dapp.
Hi all!
we are posting here our plan for the SNS feature. You can read the intent behind the SNS feature, the high level design idea, an estimate of the timeline etc.
This draft (updated with your feedback) will then be used in a motion proposal that will be submitted to the NNS roughly in a week to ask the community whether DFINITY should work on the SNS feature.
Looking forward to your inputs and feedback!
The service nervous systems (SNSs) are an extension of the Network Nervous System (NNS), the open tokenized governance system that controls the Internet Computer blockchain, providing governance for dapps. (We refer to this article for more background about the NNS.)
SNSs will allow developers to create decentralized, token-based governance systems for their dapps.
Currently, most dapps that are realised as a set of canister smart contracts on the Internet Computer blockchain are either controlled by some developers or have no controller at all. Both situations are undesirable. In the case where a dapp is controlled by a centralized group of developers, users of the dapp must trust these developers not to stop the service or to upgrade the canister code with some undesirable behaviour (e.g., that favors the developers). In the case where the canister has no controller, it cannot be upgraded at all, even though this might be necessary, for example to fix security bugs or to add new features.
SNSs allow developers to solve this problem by assigning to their dapp a tokenized, open governance system, called the service nervous system (SNS). Anyone can participate in the SNS governance by purchasing SNS tokens and locking them into SNS neurons. The SNS governance will then autonomously control the upgrades and changes of the dapp.
Apart from decentralization, another significant benefit of the SNS is that it tokenizes the dapp. For a dapp that has an assigned SNS, anyone in the world can purchase SNS tokens and thereby contribute
The SNS can decide to use tokens to reward early adopters and active users, which will help attract users. Furthermore, those who then possess SNS tokens are motivated to help increase the value of the tokens by attracting even more users, which will have positive network effects that are critical for the success of a dapp.
By participating in governance, developers, users, and other investors can collectively decide what new features should be implemented. As their tokens are locked in SNS neurons, they will be incentivized to vote taking into consideration the future value of SNS tokens and thus vote in the long-term interest of the dapp.
More generally, tokenization enables the introduction of new incentive systems and use cases that have the potential to set apart dapps from traditional applications.
For each dapp that would like to adopt a SNS, there is a separate SNS system.
Similarly to the Network Nervous System (NNS), each SNS contains, among others, a ledger canister and a governance canister. Unlike the NNS, an SNS also has an auction canister that will be used to distribute tokens at the initialization (design ongoing).
Also unlike the NNS canisters, SNS canisters burn cycles.
All SNSs are provided out-of-the box and ready to use by the NNS. That is, the NNS will control the canisters of all SNSs and each SNS instance will control the canisters of the dapp that it has been assigned to.
Both the design and implementation will be reviewed by DFINITY’s security team.
This feature is still in the design phase. We will discuss different alternatives for the necessary components at a later point in the process.
This feature mainly introduces new canisters and thus is backwards compatible. Additionally, the NNS governance canister would be extended with new proposal types and the NNS registry canister would have new records to store the SNS configurations. However, these canisters have been designed so that adding new proposals and registry records is backwards compatible.
This feature consists of many security critical components that require a thorough design, implementation, and security proofs and reviews. Having many dependencies always comes with the risk that the project might take longer as unforeseen challenges in one of the components are encountered.
We already started exploring design options and considerations.
If NNS neuron holders adopt the motion proposal, we will continue designing the different components.
If NNS neuron holders reject, the team will go back to the drawing board.
We expect to be able to start working on this feature in a few weeks. As this is a large feature with several components, we currently expect that it takes 4-6 months to complete.
Thanks for the summary!
I agree with most of the points, but would like to clarify that, since the design is ongoing, it has not been decided which parameters (at initialization and later) are configurable and to what extent. So I would precise some of your “will be configurable” to “might be configurable”.
I share your excitement and am looking forward to working on this!
Two reasons come to mind:
Could you elaborate on what you mean by “issue tokens”? Do you mean to distribute the SNS tokens? And do you refer to the distribution of these tokens in the initialization phase of an SNS or later (when the SNS can use tokens e.g., to pay users with a lot of engagement)?
Thank you for your reply.
My questions are:
Ok, thanks, I’ll follow up.
I would like to reiterate my concerns with the current design, it seems too rigid and will force all dapps into a needlessly specific form of initial distribution and governance.
The service nervous systems (SNSs) are an extension of the Network Nervous System (NNS)
Why do the SNSs need to be an extension of the NNS? What benefits does this provide? Why can’t each SNS be stand-alone and deployed by developers without having to go through the NNS and be maintained by the NNS?
Anyone can participate in the SNS governance by purchasing SNS tokens and locking them into SNS neurons.
There is an assumption here that all SNS tokens will be purchased. I don’t think that we should assume this is how all SNS tokens will be distributed.
Also, what if we don’t want the concept of neurons or staking/locking of tokens? What if it’s determined that a dapp can simply be governed by liquid tokens, the voting being just one function of the token? In that case the requirement to lock tokens in neurons would be unnecessary.
The SNS can decide to use tokens to reward early adopters and active users, which will help attract users. Furthermore, those who then possess SNS tokens are motivated to help increase the value of the tokens by attracting even more users, which will have positive network effects that are critical for the success of a dapp.
This focus on one type of funding mechanism, basically the traditional ICO model or liquidity mining model, I don’t think should be emphasized so much. Each dapp should make its own determination. It seems strange for this to be part of the SNS designs. I think this is leading the design in just one direction, and not allowing it to be general enough.
As their tokens are locked in SNS neurons, they will be incentivized to vote taking into consideration the future value of SNS tokens and thus vote in the long-term interest of the dapp.
This assumes the tokens will actual have a monetary value, I think it’s entirely reasonable that some dapps will have tokens that aren’t meant to have monetary value. We shouldn’t use this assumption since it might not apply to all dapps.
Unlike the NNS, an SNS also has an auction canister that will be used to distribute tokens at the initialization (design ongoing).
Not all dapps will want an auction to initialize the supply.
That is, the NNS will control the canisters of all SNSs and each SNS instance will control the canisters of the dapp that it has been assigned to.
Why is the NNS controlling the canisters of all SNSs directly? I mentioned this point above as well, seems better to allow the token holders to directly control the SNS from initial deployment.
Additionally, the NNS governance canister would be extended with new proposal types and the NNS registry canister would have new records to store the SNS configurations
I would hope that we don’t have to ask permission from the NNS to deploy an SNS. Why permission dapps like this?
The design is far too specific, and I think can be greatly simplified and still achieve its purpose.
The NNS is already not the ideal governance mechanism: Tokenomics Proposal [Community Consideration]
Many of us are trying to figure out ways to improve the NNS, and I think generally speaking we simply do not yet know what the ideal governance mechanism for the Internet Computer is. Trying to take the current NNS governance system and just copy it to all dapps I do not think is the ideal choice right now.
Agree with a lot of the points here…I think the developers need to accommodate a large range Dapps and dev teams.
I think there needs to be some sort of standardization for some amateur developers who just want a fun dapp vs a more complex sophisticated dapp which wants to monetize/decentralized the dapp and ensure it’s longevity.
Would be good to set out a list of parameters that should be fixed vs variable so the SNS can be customized within reason for each type of dapp.
Just some quick thoughts on variable:
Some other thoughts:
FWIW I agree with @lastmjs. Im not a developer but I know that I don’t have to submit a proposal to deploy a canister. AFAIK the NNS can do whatever it wants to an app canister if the community approves of it, so I don’t understand why the extra step is needed to deploy an SNS canister.
Just using Dom’s example of a poor developer sitting in a coffee shop; is that developer expected to submit a proposal and then petition the entire IC community to support their proposal? This may work while Dfinity directs the majority of VP but we will eventually move away from that, right?
Seems having the nns orchestrating provides some protections against unruly sns canisters while also providing a functional update pipeline though I agree current proposal may me a bit too rigid and create a higher barrier of entry for dapp developers.
I also suspect it would be more difficult to implement completely separately from the nns only to realize later it should have extended the nns and then try to connect it.
If it’s designed as an extension under current proposal I wonder if the nns could become more of a passive observer of a health sns network in the future?
I am hoping the SNS will be more flexible in the structure of governance tokens/sale thereof.
I see a need for some DAOs to restrict membership to parties belonging to specific class. For example a DAO on Sports Insurance may involve Coaches, Players,Insurers and Adjusters. Certain permissions will be granted based on the class of the requestor. Through a vote, entities could be made part of a particular user class.
For some DAOs, membership would have to restricted to certain classes based on the local laws. For example certain professional colleges restrict membership to board certified persons (e.g. Doctors, Dentists, etc.). It may be undesirable for governance tokens to be sold to the general public in this case.
I think it’s possible to make the solution easier. Allow the controller to generate SNS Voting Power when blocking Utility tokens of a certain project. Thus, the holders of the project tokens will be able to participate in the voting. This function should be optional, not mandatory
Good to see so many active devs and users here. Love where this community goes.
I think that in general, we should try to separate SNS from NNS. At least for DAO governance logic. Like what if one DAO want to deploy its own terms and utilities that are not in favor in NNS? What if we need different setup for a DAO than NNS have? I think having wide range of possibilities will bring developers to experiment and try new things. We cannot just have SNS as extension of NNS for so many reasons. I hope we could make this happen.
Hello everyone. Firstly, thank you @diegop, @lara, @johan and the rest of the Dfinity team for allowing the community to comment on this.
I have been following this topic ever since Dom’s tweets (refer my post here and this Dfinity article) and more so since the recent Community Conversation which I have summarised here for anyone who is short of time to read (and visualise based on an edited version of Lara’s slides).
Further, I have gone through and summarised the key issues raised in this forum (a majority of which were by @lastmjs) and during the community conversation as follows:
I have also expanded each of the above in the form of a table based on the various comments here (and in the recent community conversations) together with the case for and against each of the above suggestions. I have included some basic comments (based on what has been discussed here) for anyone here to expand directly within the table and/or directly in this forum. Hopefully this will allow the community to have a clear understanding of the merits and/or drawbacks of each suggestion raised to allow the Dfinity team to formulate a suitable plan forward for the community.
The following is a link to the published table (clean view) for reference.
Hope this will be useful for everyone 
Ahoy folks,
We have been reading and thinking a lot about the feedback from the forum, so @lara @dralves and I have decided on the following next steps:
Slow down, take the next few days to take in the feedback, make sure we grok feedback, questions, intent, etc… This may mean you will see us answering fewer questions next few days, but we are certainly actively reading and discussing. We will also share the feedback with the wider org to make sure they see it as well.
We will delay the NNS motion proposal to vote. We do not think we have truly appreciated feedback so we will delay the NNS motion proposal we were expecting for next week. This is not unusual, of course, we did a similar thing with Threshold ECDSA and one of the results from stopping to listen was that we spun out a project on sandboxing led by Helge.
This is awesome work @Alixthe, love that table.