SNS deployment and upgrades | design proposal

I was looking at this line:

type UpgradeGovernanceControlledCanister = record {
new_canister_wasm : vec nat8;
canister_id : opt principal;

And it gave me some concern that we wouldn’t be able to upgrade to canisters > 2MB because of the Ingress limit. There may be something else that makes this work, but, for example, the ICP ledger canister is over 2MB and we’ve had to jump through hoops to deploy it in the past.

1 Like

As a variant of 2., we could let the SNS governance mint tokens regularly and send them to the dapp canister’s account. This would be similar to how voting rewards are now distributed in the NNS, except that the rewards would not be distributed to the voters but rather just to the dapp.

So I actually want basically what the NNS does: mint tokens and give them to users. But instead of the NNS governance canister deciding how many tokens a user gets, some other dapp canister decides.

You mentioned the NNS’s minting account is controlled by the governance canister but that the rewards go directly to the users / voters. I thought the newly minted tokens would be deposited into the governance canister’s minting account? Can you explain how that flow works again?

That would be pretty much what I want.


Thanks for bringing up this concern.
I agree that this is something we have to solve as developers should be able to deploy the canisters on regular application subnets.
To solve this, we can either ensure that the wasm module is small enough or implement some canister compression that can be used during the deployment.

In the design specifically addressed in this forum entry, SNSs would live on a special subnet and upgrade themselves to a blessed version that they pull from the SNS wasm modules canister. Here, the ingress limit is not relevant when the actual upgrades take place but rather when the new wasm modules are added to the SNS wasm module canister (but still then we need to have a solution to the problem). As this is a special subnet that anyways would have some configurations differently to other application subnets, we could also consider to have a slightly larger ingress limit in the beginning.
Of for uses on normal application subnets we still need another solution as mentioned above.


Hi Lara, why was the notify method deprecated again? I think there are some advantages to using notify that you may not want to give up. Notify can be used in conjunction with canister_inspect message to ensure that only people with a balance in the native token who would be billed a fee can call that method.

This is not the case with transfer_from and approve or other methods. I have sent you an email about the issue and would be keen to hear your thoughts.


Sure, let me try to explain how it currently works in the NNS:

There is one special ledger account, the minting account, that is controlled by the governance canister in the NNS (but each ledger allows you to specify who controls that account). You can imagine that this accounts holds the “dead tokens”. If a token is burned, it is effectively transferred to this account. If a token is minted it is effectively “taken from this account” and sent to another account.

In the NNS, the governance canister controls this account, meaning that it can decide when new tokens are minted (= sent from this account).
This currently happens in two places:

  1. when node providers are paid new tokens are minted: this means that the tokens are transferred from the minting account to the node providers’ accounts (I am not sure from the top of my head if this a transfer to their ledger account or to a neuron of whether both is allowed).
  2. when voting rewards are allocated, this is first tracked as “maturity” in the neurons. Only later the tokens corresponding to the maturity are minted, which means again that at that point the tokens are transferred from the minting account to another account. This can either be caused by spawning this maturity into a new neuron (in this case the tokens are minted and transferred to a new neuron’s account), merging the maturity (in this case the tokens are minted and transferred to the existing neuron’s account, i.e., the neuron is “topped up”), or disbursing a neuron to a target account (in this case the tokens equivalent of the maturity are minted and transferred together with the neuron’s stake to the target account).

Does this make things clearer?


Thanks, yeah this clears things up.

What I’m still unsure about is who should control the minting account. If the SNS governance canister controls it, then that is fine if you mint rewards for voting on governance proposals. But what if you want to mint (or burn) tokens in response to other activities, for example moderating user content? That doesn’t really fall under the dominion of governance. That’s why I suggested a dapp canister.

Also, should the “controller” of the minting account be a canister with no controllers? In the case of the governance canister, I believe it cannot upgrade itself? Isn’t it controlled by the NNS root canister?

1 Like

What I’m still unsure about is who should control the minting account. If the SNS governance canister controls it, then that is fine if you mint rewards for voting on governance proposals. But what if you want to mint (or burn) tokens in response to other activities, for example moderating user content? That doesn’t really fall under the dominion of governance. That’s why I suggested a dapp canister.

Yes, I see your point here. The question is also if on each distribution of rewards new tokens need to be minted right at this minute. One could also decide by vote how many tokens are minted and given to the dapp canister’s ledger account and those tokens are then, depending on the activitiy of the dapp canister, further distributed by the dapp canister to the users.
This would have the advantage that the dapp canister, that is potentially on a less secure subnet, does not have the power to mint just freely.

But I think different models are conceivable and likely for different SNSs and how tokens are used, different settings will be best.

Also, should the “controller” of the minting account be a canister with no controllers?

I am not sure what you mean here. Why should the controller of the minting account be a canister without controllers? Do you see a problem if this is not the case?

In the case of the governance canister, I believe it cannot upgrade itself? Isn’t it controlled by the NNS root canister?

Right, the governance canister cannot upgrade itself but it is controlled and can thus be upgraded by the root canister. This is true both in the NNS and in the SNS.
So in the setting that we envision, each canister will have a controller to be able to continuously evolve the canisters, although the actual control over them is decentralised, i.e., only as a result of a proposal these canisters are upgraded by their respective controller canister.


Any progress regarding SNS?

Thanks for asking!
We are making good progress and should finish a first version of the SNS, specifically the governance and root canisters, in the next weeks. These two canisters, together with the existing ledger can then already be deployed as an SNS on any application subnet!
The more automated deployment and upgrade support and the new SNS subnet (which is the subject of this thread) will be tackled within the next milestone (Carbon).

We are currently defining which other SNS features should be included in the Carbon milestone and I plan to share our ideas on the roadmap and here on the forum soon (in the next week or two).
But I hope the above gives you a bit an idea on where we are!


Will there be a token standard for tokens created by SNS?

I think it will be the NNS ledger token standard.

Minting is the engine that has made almost every single crypto go. It needs to be supported or abstracted. For example, in btc instead of minting each block reward could be a payment from the Pre minted rewards account….although this has limits and restricts some economic adjustments.

1 Like

Right. The SNSs will use the same ledger / token standard as the NNS.

1 Like

Thanks for the input!
Within the Carbon milestone for SNS, we do plan to look into rewards / minting / burning.
I expect that by the Carbon milestone, we might only have a minimal variant for rewards that can then be customised further in the future.
Once we start the rewards design process, we will share our thoughts and collect inputs here, as we know many of you have great ideas / inputs regarding this topic.


It’s interesting how the ICP ledger canister chose to implement minting & burning using transfers from & to the minting account.

I wonder why it wasn’t just implemented by directly increasing or decreasing the balances of users (and adjusting the total supply)? That seems to be the most straightforward implementation to me.

Sorry it took me a while to answer, but I wanted to check with the team working on the ledger to giver you a better answer.

Mint/Burn are actually implemented as you suggest in the sense that minting & burning directly increase / decrease the users’ balance. There is only a very thin translation layer in the send-endpoint which converts the supplied arguments to transfer/mint/burn action.
A motivation for keeping this in one endpoint was that it simplifies authorization for minting - if we had a separate mint endpoint, we would have to verify on the canister level if the caller is allowed to execute it (as potentially anyone would be able to call it). Now, the sender principal determines if a transaction is a minting transfer (meaning that no unauthorised principal can even “call” minting).


Hi all,
we are excited to share an update reagarding the SNS timeline in this new forum post!


Refinement of the Design: Should the IC enforce unique token names on the SNS subnets?

Within the design presented above, there are some remaining details to be decided. We plan to share them with you in this thread. Today, we would like feedback on whether the SNS subnets should enforce that all hosted SNSs use unique token names.

We propose not to enforce unique token names on the SNS subnet and, should this be required, later just add a list of used token names (that are not required to be unique) to the SNS wasm modules canister. If a (unique) token name registry is desired, we propose that this is realised in a separate feature and also for non-SNS ledger canisters.

Introduction to the problem

When deploying and initializing a SNS, a developer can, among other parameters, choose the token name and token symbol for the token to be used in the SNS ledger canister. Let’s focus on the token name in the rest of this post, as the discussion would be similar for the token symbol.

In the context of the above design, the question came up whether SNSs on the SNS subnets should have unique token names. That is, whether it should be prevented that an SNS can be deployed on a SNS subnet with a token name that is already used by another SNS. In this post, we would like to share our thoughts on this topic and ask you to provide feedback whether you agree with our conclusion.

Pros and Cons

We see at least the following Pros and Cons of enforcing unique SNS token names on the SNS subnets.


  1. Honest developers want unique token names. It is likely in the interest of an honest developer who deploys a SNS to use a token name that is not currently used by another (popular) project. Preventing that different SNSs have the same token name achieves this goal to some extent.

  2. Users might be able to identify projects and tokens better if they use unique names. If, in the future, there are tools that list all SNSs, it would help users to understand the different projects if none of the listed SNSs share the same token name.


  1. Uniqueness of SNS token names does not prevent token name clashes in the larger setting. SNS tokens are not used in isolation. SNS tokens will be traded, for example on decentralized exchanges (DEXs) on the IC. Even if the uniqueness of token names is enforced on the SNS subnets, the same token names can still be used on ledger canisters that run on other IC subnets. Thus, DEXs are in any case required to identify tokens with additional information, for example by the SNS ledger canister ID. This is similar to some other blockchains, where smart contract addresses are provided to identify a given token. It can thus be argued that users must anyways be trained to identify tokens not only by names but also by additional means and that enforcing unique token names on the SNS subnets does not add any value for many contexts in which the tokens are used.

  2. Enforcing unique token names complicates the design and the implementation of the SNS feature. Ensuring that SNS token names are unique requires a central place where all SNS token names are registered. This could, for example, be achieved by a SNS token name registry on the NNS subnet that maps token names to SNS ledger canister IDs.
    To ensure that two SNSs that are created simultaneously do not end up with the same token name, we would require a protocol that ensures synchronization. For example, the SNS wasm modules canister could first reserve a token name in the token name registry, then create the SNS, and in the end update the reserved name with the ID of the created ledger canister. Such an extension complicates the deployment process, as there are at least two additional cross-net message calls. This in turn makes the implementation, testing, and security reviews more involved which means that there is more risk for bugs and for a delay of feature delivery.
    In addition, it is unclear how much additional design effort would be required for such a registry. For example, one would have to decide if such a name registry should just give out names on a first-come-first-serve basis. This adds further uncertainty to the feature and thus might be better addressed in a separate feature.

  3. If a token name registry is a requested feature, it should not be exclusive to SNSs on the SNS subnet. If there is a need for a token name registry, where projects can register their token names and map them to their ledger canister IDs, it is unclear why this should only be accessible to ledger canisters that are hosted on the SNS subnet. It seems to be more in the spirit of decentralization to enable such a feature also for SNS ledger canister that are hosted on other subnets, as well as for other kinds of ledger canisters (i.e., implementing another token standard). If we accept this, then a token name registry is not required to be part of the SNS feature and should be done in a separate feature.


For the above reasons, we think that the cons outweigh the added value from enforcing unique token names on SNS subnets. If a registry of token names is of interest to the community, we suggest that this registry should be accessible to a wider range of tokens on the IC rather than just to ledger canisters on the SNS subnets. Such a token name registry should therefore be tackled in a feature that is independent of the SNSs.

Developers might still want to get an overview of token names that are already used by other SNSs and deliberately choose a new token name. This could, however, be achieved by a simpler solution: we could add to the SNS wasm module canisters, which exist on each SNS subnet, a list of already used token names. A developer who would like to deploy a new SNS with a new token name, could then read all these lists before choosing their token name.

In summary, we propose

  • not to enforce unique token names on the SNS subnet and
  • to add a list of used token names to the SNS wasm modules canister if this is a requested feature. We propose that this can even happen after the first SNS version for the Carbon milestone.

Our ask

We are looking for feedback, for example:

  • Do you agree with our conclusion?
  • Do you think that having an API to just list the SNS token names is useful?
  • Do you have other ideas or concerns regarding this topic?

As always, we are looking forward to your questions and inputs!


1.) Thank you for your hard work.

2.) what’s the current projected release date on the SNS canister?

Thanks for the question!
So the SNS will consist of multiple canisters. A first version of most of them (the governance canister, the root canister, and the ledger canister) already exist and are open sourced here.
We will further improve those canisters and also plan to add an initial token swap canister (as described in this forum post .

The SNS release where SNSs are deployed on a special subnet (see here) is targeted for the Carbon milestone.