Service Nervous System
We assume that if you are reading this page you know what a decentralized autonomous organization (DAO) is, you know that a service nervous system (SNS) is a kind of DAO that is provided on the IC, and that you want to learn how you can get a DAO for your dapp. If this is not (yet) the case, you can learn all about DAOs and SNSs here, including what advantages such decentralized governance systems have.
How to get and maintain a DAO - different options
There are at least the following options on how to get and maintain a DAO for your dapp.
1) Get a system-provided SNS, an SNS that is provided as a system functionality by the IC. In this option, developers can get an SNS DAO for their dapp by a simple call to the IC. The IC, or rather the NNS community, will maintain the SNS code and can continuously approve new improved SNS versions. Individual SNSs can nevertheless be customized by choosing parameters that can be configured to realise different forms of voting and tokenomics. In this option, SNSs are hosted on an SNS subnet. Since this subnet exclusively hosts system-provided SNSs, this simplifies the verification for end users: users can simply verify that an SNS is running on the SNS subnet and infer that the underlying code has been approved by the NNS community.
2) Self-deploy an SNS and manually upgrade it. A developer or a community can choose to deploy the SNS code, which is open source, on an application subnet. They can then choose to follow the same SNS versions than system-provided SNSs follow or they can choose to deviate from this path. In this option, the SNS community has to be more active in implementing, testing and approving SNS code versions.
3) Build your own DAO or use frameworks provided by others to build your DAO. While this is conceptually similar to the second option, we would like to emphasize that there are of course other designs than the SNS that also realize a DAO. For most of these, the implications for the communities will be similar to the second option: The DAO communities will have to maintain the DAO versions or trust a third party to do so.
These possibilities allow communities to choose between using DAOs that are provided as a service by the IC, where maintenance is as automated as possible, and DAOs that have full flexibility of how they can evolve. Because the possibilities for Options 2 and 3 are unbounded, we focus on explaining the SNS in Option 1 in more detail.
SNS canisters
The SNS consists of the following canisters: the governance canister, the ledger canister and archive canisters, the index canister, the root canister, and the decentralization sale canister that is explained in the next section.
The governance canister enables decentralized decision making. It stores proposals that are suggestions on how to evolve the dapp that the SNS governs and neurons that define who the governance participants are. Neurons facilitate stake-based voting as they contain staked SNS tokens. Everyone can become a government participant by staking SNS tokens in a neuron.
The ledger canister implements the ICRC-1 standard and contains SNS tokens, which are unique tokens for each SNS. It stores which accounts own how many SNS tokens and the history of transactions between them. As we want to keep the full ledger history but a cansiter has limited memory, the ledger canister spawns archive canisters that store the ledger block history. Moreover, wallets and other frontends will need to show all transactions that are relevant for a given account. To facilitate this and ensure that not every frontend has to implement this themselves, the index canister provides a map of which transactions are relevant for a given account.
The root canister is responsible for upgrading the other SNS canisters and the dapp canisters that the SNS governs.
SNS lifecycle
SNS launch
As already described above, the SNS canister code is maintained and approved by the IC community. In more detail, the approved SNS versions and upgrade paths are stored on an NNS canister called the SNS wasm modules canister (SNS-W). A user can set up an SNS by making a call to the SNS wasm modules canister, who takes the latest versions of the SNS canisters, initializes them with the parameters given by the user, and installs them on the SNS subnet. For this to work, the user has to provide sufficient initial cycles for the SNS canisters, namely 180T.
Moreover, to allow for beta testing and to ensure that the SNS subnet is not overloaded, in the beginning this call to SNS-W is authorized. Concretely, SNS-W will have a list of principals that are allowed to set up an SNS and this list can be updated by NNS proposals. This way, everyone can make an NNS proposal and register their principal in the list, but the NNS community has means of controlling how many SNSs should be set up how quickly in the beginning. In the long term, the plan is to drop this list.
A crucial part of launching an SNS is how it can be decentralized. That is, new tokens must be distributed to a large community to ensure proper decentralization of the voting power. There are of course many ways to do so. The first SNS version provides one simple way to achieve this: a developer can hand over the control of the dapp to a newly installed SNS, that is at that stage still in pre-genesis mode and has limited capabilities. The developer can then ask the Internet Computer to start a decentralization sale and thereby launch the SNS for them.
In this decentralization sale, initial SNS tokens are sold for ICP tokens. In the end of a successful decentralization sale, SNS tokens are owned by a large community and therefore the SNS governance control is decentralized. Moreover, the ICP that were collected in the decentralization sale provide initial funding for the SNS project. It is conceivable that alternative ways to launch and decentralize a dapp are added in later SNS versions.
The decentralization sale and how to get an SNS including such a sale are described in more detail here.
SNS management
As mentioned, these system-provided SNSs are maintained by the IC. This eliminates much of the maintenance burden from the SNS communities. However, there are still some maintenance tasks that have to be performed by an SNS community, such as deciding and voting on when an SNS should be upgraded to a new version, adjusting the SNS parameters when needed, and making sure that the SNS canisters do not run out of cycles. We especially want to emphasise the last point:
The SNS communities are responsible for individually topping up the cycles of all SNS canisters as well as all dapp canisters that are controlled by the SNS. Special care must be taken that cycles are also monitored for canisters that are automatically created. In particular, this includes the archive canisters that are automatically spawned by the ledger canister. If the archive canisters are not provided with sufficient cycles, the ledger block history may be lost.
In the future, cycles management will be simplified in a new feature that allows canister groups, where cycles can be managed across different canisters.
We plan to create separate pages where you will be able to find more details regarding how to upgrade SNS canisters, set SNS parameters, and manage cycles.