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.
TLDR;
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.
Pros
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.
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.
Cons
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.
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.
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.
Conclusion
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
Our ask
We are looking for feedback, for example:
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.
Hi all,
I am excited to report that we are working on implementing the last few pieces of this feature that are needed to get the SNSs going!
As we are implementing some of the details, we notice that we can slightly simplify the design compared to what we originally proposed above thanks to some improvements that happened in the meantime. We therefore wanted to share these updates with you.
Blessed version in one SNS-W on the NNS subnet.
In the original design, we proposed to hold the SNS canisters’ wasms in an SNS wasms modules canister (SNS-W) that is hosted on each SNS subnet and to hold the blessed SNS versions in the NNS registry. For upgrading the SNS to a new version, one would need to first update the registry with a new blessed version and then add the wasm of this version to all SNS-W canisters by an ingress message (and repeat this on all SNS subnets if there are multiple at some point) .
The main reason for this was that we thought that the SNS canister wasms were too big to be sent in cross-net messages from the NNS to the SNS.
In the meantime, we were able to reduce the wasms of the SNS canisters with some improvements. Therefore, we propose to now have one SNS-W canister on the NNS subnet rather than many of them accross SNS subnets. This allows that NNS proposals that bless new SNS versions also directly add the new wasm in SNS-W, without further user interaction. Also, as we only have one SNS-W canister, this simplifies synchronization across all SNS subnets (once there is the need for more than one).
As the SNS-W canister is already on the NNS subnet, we also propose to record the blessed SNSs in this canister rather than in the registry. This nicely separates concerns and allows to hold all the information relevant for SNSs in the same canister.
The type of the SNS subnet
Originally, we proposed that the SNS subnet will be a new type of subnet. We argued that this is needed as we needed some bounds that are the same as on a system subnet but other properties from an application subnet, for example that cycles must be paid for canisters.
Again, in the meantime we made some improvements that eliminated the need for special bounds. Therefore, we now propose that the SNS is of type “application subnet”. This means that it is like a regular subnet with the only difference that only blessed SNSs can be deployed on it.
This is beneficial, especially as the SNS code should anyways work on other application subnets to allow anyone to self-deploy an SNS.
SNS upgrade triggering
Finally, the original idea was that SNSs upgrade themselves, by checking on every heartbeat if there are new blessed versions in SNS-W. This would not only cause a lot of cross-net traffic but it would also take away some power from the SNS communities.
Therefore, we now suggest that the SNS communities decide, with SNS proposals, when they want to upgrade to the next blessed SNS version. The SNSs can still only be upgraded according to the blessed deployment path, which also means that the SNS communities don’t have to be concerned with too much maintanance burden, but the SNS communities can decide at which moment they would like the upgrade.
We hope all these small improvements make sense to you and are happy to answer any questions that you might have!
Hi @lara,
I’d like to make a suggestion for the new SNS front end that is coming. For prospective and existing projects with SNS tokens, I believe it makes sense to provide both a link to the website and a link to a downloadable PDF of the SNS White Paper. I also believe we should add an empty template for folks who would like to add their own SNS White Paper.
The OpenChat team has done a fantastic job of creating a great template for a SNS White Paper to provide prospective investors with the information they need to decide to invest or not. I would propose adding a template White Paper modelled on the structure of their White Paper for all future projects that prospective SNS projects can download and work from.
We need to keep the bar high and imho if projects don’t fill out the template sufficiently they should not be allowed to launch on the SNS. There are things prospective investors simply need to know to make informed decisions.
Let me know what you think.
Hi @dfisher ,
thanks for the idea.
I happily take this feedback to a discussion where we plan to think again about what exactly should be included and displayed in which way in an NNS proposal to start an SNS decentralization sale.
Regarding the template:
What I like about the template idea is that it make different projects more comparable and that it might set minimal requirements of information that is expected.
There are however a few comments / conerns that I have: