With the Chromium milestone coming closer (currently scheduled for May 2022), we scoped in more details the SNS features that we would like to finish by the next two milestones, Chromium and Carbon. In this post, we would like to share our ideas and get your feedback.
Before diving into the details of the roadmap, let us quickly recall some basics about the SNS.
Similar to how the Network Nervous System (NNS) governs the Internet Computer blockchain, Service Nervous Systems (SNSs) are algorithmic DAOs that will allow developers to create decentralized, token-based governance systems for their decentralized applications (dapps).
There will be one SNS per dapp.
An SNS initially consists of the following canisters: ledger, governance, root, and frontend.
As the SNS ledger canister we will use the same ledger canister as in the NNS. The ledger canister code has already been updated to facilitate that each SNS can specify its own token name etc.
According to some early feedback, we decided to release the SNS in stages, so that each intermediate version can already be used by developers. Two relevant bigger stages that have been discussed on the forum are the following.
As described in this forum post, our first goal was to implement an open governance canister that will then be used in the Service Nervous Systems (SNSs).
As described in this forum post, we then want to improve tooling and support for the deployment and upgrade of SNSs. Especially, SNSs should be provided as a system functionality, which is automatically maintained by the IC and where the SNS canisters are hosted on a new SNS subnet.
The suggested roadmap still follows these stages but adds more details regarding which features will be done. Also, we propose a tentative and rough timeline for these features.
April
A first version of the governance canister (as described in this forum post) and a first version of the root canister are ready. These canisters should be considered as an alpha version. That is, we will further increase their robustness and security after this first version.
A demo showing that the SNS is fully functional and one can interact with it over a command line tool. The demo will show
how an SNS can be deployed on a regular subnet,
how it can be initialized with initial ledger accounts and neurons, and how the SNS can become the controller of a dapp, and
how the dapp can be upgraded by the SNS, with a proposal to and voting on the SNS.
On our way to the Carbon milestone:
The new SNS subnet will be created.
We will conduct a pilot of the SNS with a few select developer groups. During the pilot, the teams will be asked to deploy their actual SNS, which is at this moment maintained by the developers on the SNS subnet, and report to us any potential bugs or missing features. This feedback will allow us to further improve the SNSs. It is important to start with a small number of such SNSs as we will likely have to troubleshoot and as we will have to upgrade these developer maintained SNSs to the SNS version that is automatically maintained by the IC, which will be some manual effort. If you are interested in participating in the pilot please contact us by filling out this form. Please do note that we will initially be selecting only 2-3 teams and may continue to add additional teams during the pilot stage. We will continue to update everyone on the results of this initial pilot and any additional opportunities for testing.
Carbon milestone - We aim to have SNSs that
are hosted on the new SNS subnet and automatically maintained by the IC (as described in this forum post)
include a first minimal version of rewards
have a first minimal frontend
We are currently working on what the minimal rewards/frontend should look like and will share concrete design proposals on the forum as soon as they are ready!
We hope that this gives you a good overview of what we have planned for the upcoming weeks and months and look forward to hearing your feedback!
Does this mean that eventually we would have a separate subnet dedicated to host only SNS canisters? Or would developers deploy their SNS canisters to the subnet where their dapp lives.
If it’s separate, is it because this subnet would have a higher replication factor to ensure more security?
Hi @chepreghy, thanks for the question!
You are exactly right. The idea is that the SNSs live on a new subnet that 1) has a larger replication factor (we plan to start with 34 nodes) and 2) only hosts SNSs that run canister wasms that have been blessed by the NNS community.
This provides more security for the SNSs that run the security critical governance and ledger canisters.
This is correct. The auction will not be part of the Carbon milestone.
I believe some groups have the idea to already set up an SNS, store most of the tokens in a special account controlled by a canister and then use the auction to distribute tokens later, once this feature exists.
Hi all, we propose to add an additional feature to the SNS Carbon release: an initial token swap. Head over to this link or join us in the community conversation on Thursday to learn more!
Apologies if this has been asked before, but what happens if SNS canisters run out of cycles? Is it the same as with any canister on the IC—it gets frozen and eventually deleted? I ask because the NNS system subnet doesn’t charge its canisters any cycles.
Yes, it is as with any “normal” canister on the IC (so unlike the NNS canisters), which means that SNS communities must be careful to ensure that the SNS canisters do not run out of cycles.
The SNS subnet is of type “application subnet”, so it behaves as any usual subnet in this regard.
I know you guys are impatient to let the community know about the potential power of sns, but I think DFINITY just need to specify the standards for sns (even including front-end) and then leave the specific implementation to the dapp developers.
In addition to risk control, this is much more developer friendly and non-intrusive. Also the surrounding ecosystem around the sns system can be developed. In fact it is currently difficult to create an ecosystem around nns pledges, and I don’t think sns should be the same.
I agree with this 100%. In fact I’d consider a proposal that projects should be up and running in “application” mode for a significant amount of time before being “promoted” to a full fledged SNS member that has any kind of direct integration with the NNS.
This frees the foundation to release the spec, help devs build and communities grow, and let’s the NNS voting community get to know a project before giving it awesome powers.
Personally and via ICDevs(although we haven’t decided at a board level) I currently would reject any project joining the SNS at the NNS level without it running in application mode for a large number of months. This is in no way a final position, just my thoughts as someone who has been navigating the building a DAO for months for Origyn and my personal horror at the thought of having it connected to my broader ICP investment until we’ve worked out the significant unknowns on our backlog…most of which I don’t think will get solutions until functionality meets with real users.
This is my personal opinion and not the opinion of Origyn or the dev board of ICDevs.
One advantage of providing a concrete implementation is to also make these tools available to developers and projects that might not have the time to implement a DAO themselves in addition to their dapp.
That being said, as also mentioned in the original SNS designs, of course all SNS code is open-sourced and everyone can modify this code to create a customised SNS or implement their own DAO from scratch. The SNS is deliberately built in a modular way, so that one could for example use the ledger but modify/replace the governance canister etc.
We also work on application subnets with higher replication factors, so that customised SNSs/DAOs can also run on secure subnets.
DFinity should continue doing what they are doing. They are now a contributor to the IC just like everyone else and they can decide what to do without undue influence. Developers will want to monetize everything in L2 at the expense of the users, so what DFinity is doing helps users get good key application infrastructure that is totally open source.