SNS initial token swap

TL;DR: We provide a high level design for a new “Initial Token Swap” canister. We explain why this is an essential part of the process of converting an existing dapp on the Internet Computer into a decentralized dapp controlled by a SNS DAO.

Background SNS

Similarly to how the Network Nervous System (NNS) is the open tokenized governance system that controls the Internet Computer blockchain (IC), service nervous systems (SNSs) are algorithmic DAOs that allow developers to create decentralized, token-based governance systems for their dapps. We refer to this article for more background on how SNSs will empower dapps to leverage the full potential of the IC.

A SNS consists of a set of canisters, including the governance canister and the ledger canister. The ledger canister 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 the principals. The governance canister stores proposals that are suggestions on how to evolve the dapp that the SNS governs and of neurons that define who are the governance participants. Neurons contain staked SNS tokens and everyone can become a participant of the open governance process by staking SNS tokens in a neuron.


To decentralize a dapp, developers can hand over the control over their dapp to a community. There are of course many ways to do so. The aim of the Internet Computer’s SNS is to allow this in a very simple way: developers can hand over the control of their dapp to the Internet Computer that will then launch an SNS for them with a governance system and a token ledger according to the specification of the developers. A crucial part of launching an SNS is how the newly created tokens are distributed and how they are staked into neurons for the SNS’s governance ensuring proper decentralization.

In this post, we provide a simple way to achieve this: we introduce the concept of an initial token swap where participants can exchange ICP tokens for SNS tokens to provide funding for a dapp. We then explain how this initial token swap can be leveraged in the launch of SNSs.

Context with other SNS projects

While the original SNS design included a token auction, the latest SNS timelines (see this forum post) did not include an initial token distribution for the Carbon milestone. The idea was that we would add this later as an additional feature.

However, it is essential for projects that the launch of their SNS distributes its voting power over many different neuron holders. As the goal of the Carbon milestone is that the SNS is ready to be used, we propose to prioritize the work to realize an open initial token distribution and to include it in the Carbon milestone.

Proposed design of the initial token swap

To ensure that tokens can be distributed to independent parties during an SNS launch, we propose an initial token swap, which is implemented by a newly introduced swap canister.

We first explain the proposed design for the swap canister and then explain how this swap canister is integrated into the flow of an SNS launch to achieve decentralization.

Swap Canister design

Each SNS will have a separate swap canister that only exists for the duration of the SNS’s launch.

  • The swap canister is set up at start with a defined amount of SNS tokens to be distributed publicly.

  • During the swap, participants can send ICP to the swap canister to contribute to the dapp’s funding.

  • At the swap’s end the collected ICP are “swapped” for the SNS tokens: the swap participants get SNS tokens and the SNS gets the collected ICP. Each user will receive their portion of the pool of SNS tokens, pro-rated by their % of the overall number of ICP contributed. For example, if the swap canister initially held 1000 SNS tokens and 500 ICP tokens were collected during the swap, then the exchange rate would be 2:1 and each swap participant would get 2 SNS tokens for each ICP token they contributed.
    The exchange rate is thus set similarly to decentralized exchanges (DEXs) based on automated market makers (AMM), where the assumption is that two pools of tokens are of equal value.

  • The swap achieves that a) a market price for the SNS token is set and b) every swap participant receives SNS tokens at that price.

To ensure that the focus of this process is on distributing dapp governance and less on speculation, all tokens will be given out in neurons with a dissolve delay of three months. This should leave enough time for the SNS community to start a token market before the first tokens are liquid.

Let’s next look into a bit more details about the initial swap canister, specifically which parameters can be set for each initial swap and how they affect the swap.

  • Maximum amount of ICP tokens: The maximum amount of ICP that the swap collects as funding. If this amount is achieved, the swap ends. Together with the next parameter, this determines a minimum and maximum SNS token price.

  • Minimum amount of ICP tokens: The minimum amount of ICP that the swap needs to collect to be considered successful. Together with the first parameter, this determines a minimum and maximum SNS token price.

  • Swap deadline: The deadline when the swap ends. As mentioned above, the swap may end before this deadline if the maximum amount of ICP tokens has been collected.

  • Minimum number of swap participants: The minimum number of swap participants for the swap to be considered successful.

  • Minimum and maximum amount of ICP per participant: The minimum and maximum amount of ICP that each swap participant can contribute. The minimum achieves that each participant has a minimum investment while the maximum guarantees that no principal can get too large of a share of the initial token distribution.

In summary, there are two parameters, the maximum amount of ICP tokens and the swap deadline, that determine when a swap ends and two parameters, the minimum amount of ICP tokens and the minimum number of swap participants, that determine whether the swap was successful. Finally, the minimum and maximum amount of ICP per participant determine what constitutes a valid participation.

If a swap is successful, neurons are created for each swap participant containing the amount of staked SNS tokens as determined by the exchange rate described above. If the swap ends but is not successful, for example because not enough ICP have been collected, all collected ICP tokens are transferred back to the swap participants.

SNS launch

Let’s now look into how an SNS can be launched, that is how a dapp’s control can be transitioned from the centralized into the decentralized state, using this initial token swap. The proposed design aims to achieve the following goals:

  • The developers handing over a dapp to an SNS community should get some voting power in the launched SNS

  • A share of the initial voting power of a launched SNS, that is initial neurons, should be owned by independent parties and the swap should be decentralized

  • A launched SNS should have some initial funding that the SNS community can use to pay contributors, pay for cycles, and pay for usage rewards

  • Prior to the swap’s end, no one can transfer SNS tokens

  • At any time, the dapp can be upgraded to evolve it and address bugs

To achieve these goals, we propose that an SNS launch goes through the following stages.

  1. Initializing the SNS: When developers initialize a SNS to which they want to hand over the control of their dapp, they choose a portion of tokens that are allocated to the developers, to the initial token swap, and to a treasury, which is an account that will be owned by the SNS governance canister and can be spent by the SNS community according to their needs. Possibly they can also specify a portion of tokens that are allocated to other predefined parties, for example to “airdrop” some tokens to known dapp users. The developers can also define the conditions for the swap, for example how many ICP tokens should at least and at most be collected (see details above).
    As the SNS is not yet decentralized, the swap canister is controlled by the NNS.
    There are only two ledger accounts with liquid tokens during the SNS launch, the treasury that is owned by the governance canister and preallocated tokens owned by the swap canister. To ensure that no one can transfer tokens, and distribute them or start token markets prematurely, all initial tokens from developers or ‘airdrop participants’ are locked in neurons. Moreover, to ensure that these initial neurons cannot modify the SNS before or during the swap and cannot transfer the treasury tokens, the SNS is deployed in a pre-genesis mode with limited functionality.

  2. Dapp control handover: Between the SNS initialization and the start of the swap, the developers hand over the control of their dapp to the SNS. As there are already initial neurons (from Step 1), the dapp can now be upgraded via SNS proposals. The initial neurons can not do other things, such as changing the SNS parameters, as the SNS governance canister is still in pre-genesis mode. As the developers were already controlling the dapp before the SNS initialization, they effectively do not have any additional privileges compared to the state before the SNS initialization.

  3. Starting the swap: The swap is started by an NNS proposal. This means that during the launch, the developers that originally controlled the dapp hand over the control of their dapp to the NNS that then initializes the swap for them. When voting on a NNS proposal to start a swap, the NNS neurons should consider whether the swap parameters make sense and, most importantly, whether the dapp’s control has been handed over to the SNS already (that is Step 2 was completed successfully). The NNS proposal thus also serves as a safeguard where the wisdom of the crowd can detect potentially malicious SNSs before they trick users into investing in them.
    If the NNS proposal is adopted, the swap is started by the NNS. If the NNS proposal is rejected, the SNS launch is aborted and the dapp’s control is handed back to the developers.

  4. Initial swap: When the swap starts, the swap canister holds the number of SNS tokens that were specified at initialization (see Step 1). End users can participate in the initial token swap by transferring ICP tokens to the swap canister.

  5. SNS genesis: When the swap ends, it is first established whether the swap was successful, e.g., enough ICP have been collected.
    If the swap was successful, the exchange rate is determined as explained above and all tokens will be given to the swap participants in neurons staked for three months. Once all neurons are created, the SNS is under decentralized control and the governance canister is set to be fully functional.
    If the swap was not successful, the decentralization attempt failed. Thus, everything will be reverted to the state before the SNS launch, including that the dapp’s control is handed back to the developers and all collected ICP are refunded to the swap participants.

Future directions

In the beginning we presented the challenges to be solved in a SNS launch. We see the initial swap canister as a first tool to address those challenges. Later, additional or alternative tools can be provided resulting in a toolkit to launch SNSs, a SNS launch pad.

One example of such a possible extension is the community fund, for which we will share a first design proposal in the coming days.


We consider this to be a security critical feature. For example, different tokens (SNS tokens and ICP tokens) are involved and it must be ensured that swap participants get SNS neurons if and only if they correctly deposited ICP into the swap.

We already reviewed the design with DFINITY’s security team and plan to have thorough security reviews with their help once the implementation is done.

Alternatives considered

  • We could launch the first version of the SNS without an initial token distribution. As argued above, such a feature is required for projects that want to start an SNS. We therefore think it is important to include this feature as part of the Carbon milestone.
  • We could have chosen to use an auction, rather than a swap, for the initial token distribution. Such an auction would have to a) establish the market price of SNS tokens and b) should be such that everyone has to pay the same price (otherwise some participants would get an unfair advantage). Many existing auction mechanisms do not satisfy both of these requirements so it is unclear what such an auction would look like in detail. The suggested initial swap provides all the required properties without introducing additional complexity. In addition to a simpler design, another reason why the swap might be easier to understand for end users is that it closely resembles token swaps used in decentralized exchanges, which many users are familiar with.

Procedure Motion proposal & Updated SNS timeline

As already argued above, we propose that this feature is added to the Carbon milestone.

Regarding the introduction of this feature, we propose to proceed as follows:

  1. This & next week: Discussion on this forum post regarding the proposed design
  2. Thursday June 9th: Community conversation
  3. Next weeks: Motion proposal to vote on the above design (potentially updated with feedback from 1 & 2)

Is Swap Canister open sourced yet, and please share more details of community fund usage


Thanks for the question!
It is not yet, but it will of course be open sourced when implemented.
Yes, as mentioned we plan to share a community fund design soon.


By Carbon Milestone do you mean that we will have our first live, launched SNS event with a dapp in mid Q3 2022?

1 Like

join community conversation about SNS initial token swap here:


Wonderful proposal. This will go a long way in eliminating scam tokens and creating the much sought after trust in token launches.


I love that this a separate piece of infrastructure. Could one use this for continual funding over time? Say you wanted to release 70% if your tokens 7% at a time over ten months? Or even in a continual inflation with burn model once a month forever?


The idea of the SNS controlling a single treasury still seems complicated to me. Imagine each time the SNS wants to pay a developer that’s working on the dapp it needs to submit a proposal.

I wonder whether it makes sense to have two treasuries. One smaller treasury that the developer team controls that it can use for daily operations and another bigger treasury that the SNS controls. Every so often the smaller treasury can submit a proposal to access funds from the larger treasury.

Am I making sense? These dapps still need to have developers that are working to develop them and paid for their work. I can’t imagine how decentralized governance would work for paying for daily operations. That is still very confusing to me.


Yh you’re making sense, I don’t think a mini treasury would require proposals if it’s in the form of a neuron? (Only the dissolve delay would need to have expired) It would be cool if we can set neurons with different dissolve delays and also automatically proportion allocations on a monthly cycle.

1 Like

Hi @dfisher, if you mean when we will have the first SNS live on the IC, this is of course not fully up to us (some developers need to choose to decentralize their dapp), but by Carbon we aim to have everything in place so that anyone can do so. Does that make sense?

1 Like

Glad you like the proposal!
So the goal of the initial token swap are, among others, that the SNS is decentralised afterwards and that a token price is established. Likely, for follow-on swaps the goals would be a bit different (the SNS is already decentralised and maybe you would rather want to sell tokens on a fixed price…). So depending on the needs it seems that it might make more sense to have a slightly different setup for follow-on sales, but we might of course be able to reuse some of the code if we wanted to add this later.

For continual inflation do you mean continuing to sell tokens? If so, I think the same answer applies.
Another tool for this could also be the voting rewards?


Thanks for the feedback!
I see your concerns, but think this is actually in line with the design.
The idea is just that the treasury is the most generic form of funding that the SNS can have and it is owned by the SNS governance. This should allow every SNS to define what they need in more detail,
The SNS can then, rather than paying for small things in many small transactions, also make bigger transactions to allocate some of the funding to someone else who can then make smaller payments.

For example:

  • the SNS community can decide to trust a developer to do regular payments. They can then decide to transfer some funding from the treasury to an account owned by the developer who can subsequently use these funds.
  • the dapp can be implemented such that it gives rewards for certain actions in the dapp. To be able to pay such usage rewards from the treasury, the SNS community can approve a proposal that sends some funding to an account that is owned by the dapp cansiter. The dapp canister can then take care of the subsequent fundings.

Does that make sense?
So I think your idea with different distinguished “buckets of tokens” that are reserved for different things is possible. It just always requires one SNS-approved transaction to create a new bucket / top up the bucket if it is empty. But by not predefining the number of buckets or who owns them in the SNS code and just having one “treasury” we allow each SNS to define what kind of buckets they need and who they should be controlled by.


I asked this during the community conversation, but I’m going to ask it again so it doesn’t get forgotten:

If the proposed design is adopted, all tokens will be either locked in neurons or owned by the treasury account post-swap. However, some tokenized dapps have utility tokens that are actually needed to perform functions in the dapp. To that end, it’s important that a portion of the initial post-swap token supply is liquid. What can be done to ensure that is the case?

1 Like

I’d also be curious about the team’s plans to support pre-existing tokens.

For example, ORIGYN recently was the first project to launch its own token on an IC-hosted DEX (Sonic). If a project like that wanted control to be turned over to an SNS, would that be possible? Would they skip the initial token swap? Will SNS support ICRC-1 once it’s made available or other token standards?


Yes thank you. Makes sense!

1 Like

Good question!
We always said that the SNS will just use the existing NNS ledger. However, with the ongoing discussion on the standard, we are not sure what the ledger would look like in the end. So we have to correct that statement to: The goal is that the SNS will have a ledger that eventually supports whatever is the outcome of ICRC-1. This is definitely the goal!

Now supporting more than one ledger implementation is not planned for the Carbon milestone but can of course be reconsidered later. There are multiple things to consider here:

  1. are the other ledger implementations compatible with the governance canister (e.g., it relies on subaccounts for the neurons)
  2. what is the right number of ledger implementations to support on the “IC-maintained SNSs”? What I mean here: everyone can of course always take the open sourced SNS canisters, fork them, and make them compatible with alternative ledgers. However, the code of the SNSs on the SNS subnet is maintained by the IC community over NNS proposals. This community has to make sure that the different canisters in one deployment (governance, ledger, root) are compatible and that upgrading from one deployment to another is well tested. Adding alternative ledger canisters will complicate this maintenance work considerably. So the tradeoff will probably be between being inclusive to many alternative options vs. keeping the upgrade paths maintainable.

Thanks for bringing up this point! We acknowledge that this could be an important requirement.

Maybe the initial release might not have all of this flexibility that we’d like yet, but in future releases we can certainly add more flexibility & options to the design introduced above.

Our current thinking is that maybe the swap participants as well as the initial (developer) neurons could get a basked of neurons with different dissolve delays that allows for projects to release liquidity of tokens in a controlled manner. This could include neurons with zero dissolve delay which would mean that the tokens can still not be used during the swap (as at this stage the governance canister is in a state that does not allow to dissolve neurons), but it would allow to have liquid tokens right when the SNS launch is finished as then the neurons can be dissolved right away.
So I think this would address your requirement.

I think it makes sense that an NNS proposal is needed to create an SNS on the main IC network.

It does limit experimentation though. Are there ways to experiment with setting up our SNS and fine-tuning settings before actually going live?


recording of talk can be found here: Community Conversations | SNS Initial Token Swap - YouTube


The design is now up for voting in a motion proposal:

If you like it, please consider supporting it with your vote and spread the word!

1 Like