SNS frontend design


  • We propose to add SNS user functionality within the NNS frontend dapp.
  • The SNS frontend within the NNS will manage the full range of functionality of user interactions with an SNS; from participating in an SNS launch, to managing SNS neurons & voting & transferring SNS tokens.
  • SNS frontend functionality is planned to be released incrementally.
  • We are prioritizing this work within the roadmap of the NNS frontend.

Background service nervous system (SNS)

A service nervous system (SNS) is an open tokenized governance system that can be used to decentralize the control of a dapp. SNSs will be provided as a service by the Internet Computer (IC) and work conceptually similarly to the Network Nervous System (NNS). While the NNS is the open governance system that controls the full Internet Computer, each SNS will control one dapp.

An SNS consists of a set of canisters, including the governance canister, which stores proposals and neurons, and the ledger canister. A motion proposal that is currently under vote proposes that the SNS launch contains an initial token distribution to ensure decentralization of SNS governance. Thus, assuming that this proposal is adopted, the SNS will at launch time also consist of an initial swap canister where participants can exchange ICP tokens for SNS tokens to provide funding for a dapp. (We refer to this forum post for more information about the initial token swap and to this forum post for more information on governance.)


One important goal of the SNSs is decentralization, that is that decisions regarding how the dapp is evolved are made by a variety of different parties, for example including dapp users and investors. Another important goal of the SNSs is to allow anyone, even small investors, to contribute to initial funding and thus support dapps.

The achievement of these goals heavily relies on many users actually participating in the initial token swap and later in the governance process. User participation in turn relies on how user-friendly the participation is.

Therefore, similarly to how users can stake neurons and participate in the NNS governance by using the NNS frontend dapp, SNSs should have a user-friendly frontend that users can interact with to provide funding to SNSs and participate in SNS governance.

In this post, we propose a high level design for the SNS frontend and present some first drafts of what the SNS frontend UI could look like. While everyone can implement a frontend for the SNS, we explain why we propose to also include an SNS frontend within the NNS frontend dapp. We also suggest a prioritization of the different user stories, that is which user stories should be supported for the Carbon milestone and which ones shortly after.


We first present how users can interact with an SNS and what kinds of user groups there are. Motivated by this, we then present a proposed design and timeline.

How users interact with the SNSs

There are the following categories of user interactions with the SNS:

  1. Initial swap participation: users send ICP to the SNS during its launch to contribute to the SNS’s funding. If the SNS launch is successful, the users receive SNS tokens, staked in SNS neurons, in return. (See this post for more details.)
  2. SNS governance participation: users that already got SNS tokens, either from the initial token swap or by other means such as exchanges, can stake the tokens in neurons and participate in governance. This includes that they can make new proposals on how to evolve the dapp governed by the SNS and that they can vote on such proposals. To successfully participate in governance, users should also be able to configure their neurons.
  3. SNS ledger transfers: users that already got SNS tokens should be able to transfer them to other accounts, such as other users or to dapp services that they can pay for.

While the initial swap participation is a one-time event for each SNS, the governance and ledger interactions continue throughout the lifetime of an SNS.

User groups and SNS entry points

There are two main groups of SNS users that one can distinguish.

First, there are the dapp users. Due to the design of the Internet Computer, anyone can interact with a dapp without the need for owning any tokens or understanding the underlying blockchain architecture. Therefore, many dapp users might not have any experience with token wallets and governance participation.

Despite the lack of this expertise, many of these users might want to participate in the SNS, for example by receiving SNS tokens as rewards for certain activities in the dapp, by paying with SNS tokens for dapp services, or by helping decide how the dapp is evolved. To make such SNS interactions accessible to dapp users, developers will likely include parts of this functionality directly in the already existing dapp frontend so that users can stay on the same web app for all interactions.

The second group of users are investors and other IC enthusiasts that already own ICP tokens and would like to use those ICP to help fund new projects and support the IC ecosystem. Many of these users already interact with the NNS frontend dapp, but are not regular users of all the dapps on the IC. Thus, it would be beneficial to have an entrypoint on the NNS frontend dapp to make SNS initial token swaps and SNS governance accessible to these users.

We conclude that to attract as many users as possible, for many dapps it is best to support SNS participation from different entry points. However, it is of course up to the different dapps to decide what they would like to support and not all developers might have the resources to add an SNS frontend integration to their dapp. Therefore, to ensure that even such dapps can get enough user interaction to successfully launch their SNS, we propose to add an SNS frontend to the NNS frontend dapp. As argued above, the NNS frontend dapp also provides a natural entry point for one user group.

Proposed frontend design for the initial token swap

We plan to first realize the functionalities required for users to participate in the initial token swap, as presented below, and then add the remaining components for SNS governance participation and ledger transactions. We first present in some more details what the user interface for the initial token swap participation could look like and then present more details on the timeline.

Figure 1

Figure 2

Two key views of the UI are demonstrated in Figures 1 and 2, which show the NNS frontend dapp in a “light skin” that will be available soon.

The NNS frontend dapp will have a new Launch Pad view where users will be able to find the current SNS launches and their deadlines (see Figure 1). This overview includes both SNS launches for which the user has already participated in the initial token swap (Project Pac-Man with 25.00 ICP in the example) and projects where they have not yet participated (Project Tetris in the example). For those SNS launches where a user has participated, the view also shows the user’s current contribution.

Initial token swaps are started by an NNS proposal. In addition to the current SNS launches that are ongoing, the Launch Pad view thus also shows a list of initial token swaps that are currently being voted on and where the user might participate in the near future (see Figure 1).

To participate in one of the current SNS launches, a user can tap on a project from the Launch Pad view. This will lead to a view with details about the project as shown in Figure 2. The view provides a detailed overview of the SNS that is launched, including its token name and the conditions of the initial token swap such as the minimum and maximum amount of ICP that a user can contribute.

A user can also learn how far the initial token swap is, that is whether it has already reached the minimum and maximum number of total ICP that it aims to collect and when its deadline will be reached. If the user agrees with the conditions, they can specify the ICP amount with which they want to participate in the initial token swap.

If the swap is successful, a new SNS neuron will be created for the user which the user will be able to find on the NNS frontend dapp.

Proposed Timeline

As mentioned above, we propose to prioritize the frontend for the initial token swap and then add the remaining components for SNS governance participation and ledger transactions. In more detail, we propose to include the frontend for the initial token swap in the Carbon milestone and add the remaining functionality shortly after.

The main reason for this are:

  • Including all of the frontend work in the Carbon milestone would delay the Carbon milestone. Therefore, we propose an incremental approach and focus on one part first which can be delivered by the time of the Carbon milestone.
  • There are two main reasons why we propose to prioritize the initial token swap over other frontend work.
    First, as argued above, many dapps will want to integrate SNS functionalities directly in the dapp frontend but they might not have enough resources to do all of it. As the initial token swap is only a one-time event and governance and ledger transactions are needed throughout the dapps’ lifetime, dapp developers might want to prioritize work on the latter two. We thus think it is important that the swap participation is covered by the NNS frontend dapp.
    Second, in the flow of SNS interactions, the users first interact with the initial token swap to obtain tokens and then interact with the governance. Thus, when the first SNSs launch, the integration with the initial token swap is the first thing that they will need.


  • Q: Does this frontend block SNS launch? If it does, by how much?
    A: This proposal does not block or delay the SNS milestone Carbon. While initial versions of the SNS canisters governance, ledger and root exist, the SNS initial token swap canister and tooling around the SNS deployment and upgrades are still ongoing work. The frontend can be built in parallel to this ongoing work, as this is mostly done by another team. As explained, to avoid delaying the deadline, we propose an iterative process that first focuses on the initial token swap for the Carbon milestone and then adds support for SNS governance and SNS ledger transfers shortly after.
  • Q: Can other people build the SNS frontend? Are the APIs and frameworks available to them?
    A: The APIs will all be publicly available and are open sourced as they are implemented on the SNS canisters. As motivated, dapps and other parties can build SNS frontend integrations themselves and we expect that many projects will integrate parts of the SNS interaction into the existing dapps. We propose to also integrate the SNS interaction to the NNS frontend as 1) the NNS frontend is a natural entry point to attract users that already have ICP that they would like to invest and 2) not all dapp developers will have the resources to do all of this by themselves.
  • Q: What happens if we do not build this?
    A: If we do not provide this functionality, we risk that the SNSs have little participation and thus little decentralization and initial funding. This is because we cannot expect that all dapp developers have the resources to integrate all SNS functionalities to their dapp by the time when the first SNSs are ready to be launched.

Thank you for this. Sounds great!


Look great. I really like the design, I believe this will change the current blockchain world!!!


Great proposal and looking forward to it.

What Standard would the SNS Tokens have in terms of interoperability with other dApps?

How can developers get early access to start integrating SNS functionalities?

I think this would be a great success as a lot of developers and users have been waiting for this to come!

I think integrating other projects to the NNS is a highly risky endeavor. You will be infusing those projects with credibility that they have not/may not earn. A debacle in one my cast a shadow on the whole. If one project were to come under regulatory scrutiny the entire NNS could be suspect and we could have a Nintendo situation that affects many projects. As an ICP holder I’d be much more comfortable with separate interfaces for each project.

A discovery mechanism would be wonderful, and registering for sub domains beyond would be helpful for useability, but I don’t think I want random project x neurons sitting next to my ICP neurons.


Or a separate user interface that lets users manage all of their sns tokens/neurons in one place. Same/similar design to the nns front end, but separate domain.


This is a very good point, I fully agree!

Thanks @ohsalmeron!

It is planned that the SNS ledger canister will implement the ICRC-1 standard that is currently being worked on.

All SNS canisters are open sourced while we are developing them, so anyone has access.
You can already deploy an SNS, consisting of the ledger canister (currently the same ledger implementation as the ICP ledger canister, but it will be evolved as explained above), a governance canister (git), and a root canister (git) and start integrating with these canisters.
Of course this is work in progress, so things might be added and tooling still has to be evolved, but the core APIs for these canisters are rather clear already.
If you have additional questions or need more help with how to integrate things, please feel free to reach out to us!

Thanks for the feedback!

One thing that mitigates having non-credible projects in the NNS frontend dapp is the fact that the initial token swaps are started by NNS proposals. This means that for each SNS initial token swap, the NNS voters have the choice whether they think the project is trustworthy and will end up on the NNS frontend dapp.

The main advantage of having everything in the same frontend is usability: For participating in an initial token swap, a user has to send ICP to the initial token swap. As users already have ICP in the frontend dapp, this is a natural place to trigger this action. As the result of the initial token swap, users will receive neurons. So if we wanted SNS frontends to be in a different dapp, a user would always have to do an extra step and switch of dapps for this flow:

  1. One possibility would be that users make the ICP transfer in the NNS frontend dapp and then get the neurons in another dapp. This might be problematic as users would have neurons pop up in another dapp after some time without a clear connection to the swap participation. Moreover, I think this would not address your concern as the swaps would still have to be visible in the NNS frontend dapp for this to work.
  2. Another possibility is that users first make a transfer to a new dapp / wallet and then participate in SNS initial token swaps and receive SNS neurons there. This is less user-friendly than staying in the same dapp as users have to manage more wallets. Moreover, it would be harder for SNSs to attract users as the users holding ICP would actively have to go to a new dapp to check for new swap opportunities.

So maybe in the end it is about a tradeoff between making the SNSs as visible as possible to ensure they have a lot of participation and ensuring that projects that don’t deserve visibility are not shown or associated with the NNS frontend dapp?


I’d prefer for the SNS launchpad and neurons that are created to be accessible from the NNS dApp as you have outlined. This would make it much more user friendly as you have described. Perhaps on the neurons tab you could create subfolders for NNS and each SNS, but I’m not sure that is really needed if it is easy to identify the neurons (BTW, it would be really helpful if we could customize names of neurons instead of having to keep track by neuron ID). I like the fact that each SNS has to submit an NNS proposal, which means they have to convince the community that they are legit in order to make it to the launchpad stage.


You didn’t include it in the frontend design skins in Figure 1 and 2 above, but are there plans to show the end user their existing Community Fund balance and commitments on the screen where they sign up for the SNS token swap? That could be helpful for deciding how much to commit. Along the same lines, will it be easy to see how much ICP is in a user’s regular accounts in the NNS dApp?

When it comes to the Community Fund, will people be able to commit their future maturity to the token swap or will the only be able to commit existing maturity at the time they sign up for the SNS token swap.

1 Like

I believe there is a saying that “the road to hell is paved with good intentions.” Maybe a bit harsh, but perhaps a specific example is worthwhile?

2 months ago, how many here would have considered Luna/UST a “reliable” project?

What if I told you that one of the first ten projects approved by the community would blow up that big and saddle the entire NNS with that reputation? I hope this will not happen, but if I make decisions to on voting direct SNS to NNS integrations with the assumption that it will happen I will be much more conservative on what I vote onto the SNS.

I know I’m a bit of a contrarian here and everyone wants to push use-ability, simplicity and, load the rocket full of enough rocket fuel to get to the moon, but even the Apollo missions to #11 to accomplish the goal.

I’m very excited about the SNS components of the ledger, governance canister, token swap, ect, but personally I think I’d like to see 100 successful application level projects before I’d be comfortable directly integrating one at the NNS level. Perhaps this is too conservative, but I’d hate to see the whole ICP ship go down because one wolf in sheeps clothing gets by a community vote. The community are not experts on tokenomics and governance. Even the “experts” are still figuring this all out.

I may have missed some timeline posts here, but I’d think as a rule I’d like to see perhaps three years of operations as an application level SNS instance before integrating directly at the NNS level, but I get the impression that the broader community is expecting the to happen in a much shorter term.


I see a maximum commitment option, can’t the users with the enormous amounts of ICP create different accounts and participate in this auction multiple times?

for me i dont see any problem on the intergration of sns into the nns tho just like the view of the community that seem to think that direct integration of bitcoin doesnt pose any risk to the ICP/

n its also like you’re saying that subnet is risky for the entire chain too?cuz even parachain auction of polkadot is also integrated into their substrate portal where they use for both governing and staking/

Why would you say that? Most folks on that thread are very mindful of the direct huge risk of btc integration on ICP. Thats why many people are advocating for go-slow with significant testing.

Totally agree.

Yeah…that’s a problem.

That’s what we can do personally and hope others can follow as well (i.e. read through the project etc)

the risk of external attack will always be present/ that’s why im here to support the launch of the SNS by Dfinity unless there’s still tons of technical risk that we need to go slow/ cuz it’s seem all to be about external risk here/ we’re not cardano :eyes:

BTC and ETH integration have technical risks and I have great technical faith in the dfn team.I also have no doubt in their ability to execute the technical phases of what is proposed for the SNS. What I am concerned about are the social, existential, and edge case handling of governance with unproven projects launching in a space that is highly correlated with ICP. There is a big massive unknowns in the nuance of the governance of OpenChat than in the governance of decade old chains like BTC and ETH.

While I will root for, support and participate in the governance of these new platforms, I think there should be a proper separation of concern until they have similar track records to BTC and ETH. In my 8 years in the future reality there are many global utilities running at the NNS level. In my 8 month future that scares me to death.


How much has Luna hurt the reputation of Cosmos as a whole? I feel like not that much, people in general seem to understand failure of individual independent projects isn’t necessarily an indictment on the whole platform.


I think this may prove my point. I’m not familiar with that ecosystem very well, but how did one go about buying Luna? Did you buy Luna from a cosmos dashboard? Or was it more distributed than that? I would imagine the major place to get it was an exchange and it likely had its own management dapp? Or was there a cosmos dashboard where cosmos based governance happening at the same url?

I think my concerns boil down to experiential centralization vs decentralization. Experiential centralization can be a huge benefit to usability, but it is centralization and creates psychological connections that may not be there in the underlying tech.

It would be even better if someone besides dfinity were building this interface. It is just a really strong connection for something that has significant consequences. Perhaps supernova will bring us a third party NNS dapp that makes most of this conversation irrelevant! It isn’t a super sexy project, but would be nice to see.


So we gonna fork a new chain?