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!
Objective
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.
Background
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
- to initial funding for the dapp, e.g., to pay for the dapp’s cycles, and
- submit and vote on governance proposals for that dapp.
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.
Proposed design (high-level)
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.
Security
Both the design and implementation will be reviewed by DFINITY’s security team.
Alternatives considered
This feature is still in the design phase. We will discuss different alternatives for the necessary components at a later point in the process.
Backwards compatibility
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.
Risks
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.
Rollout plan
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.
Timeline
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.