SNS deployment and upgrades | design proposal

Roadmap
21

Also, +1 on minting & burning tokens.

I.e., would you just require some fixed operation (such as rewards in the NNS) that can mint, or are you looking for something like a method “mint X tokens now” that can be called by the governance canister, or even something that just automatically mints a certain number of tokens per time period to some account ?

I think both are valuable. In fact, the heartbeat “cronjob” feature of the IC is pretty unique and could lead to interesting tokenomics.

At least for me, I’d like a variable token supply mostly for token rewards. The alternative is a fixed token supply, where token rewards (e.g. for posting valuable content on a social dapp) are provided by a treasury account. I think that’s much more limiting and even risky, as you can’t predict how many users and thus rewards your dapp will have to give out. With a variable token supply, you could vary inflation based on user activity, time, etc.

Just like NNS rewards, I expect a variable token supply to be more useful for most dapps. After all, it’s a generalization of a fixed token supply.

or are you looking for something like a method “mint X tokens now” that can be called by the governance canister

I think this is an interesting question.

Let’s say a dapp wants to algorithmically reward a user with X tokens for something they’ve done. Which approach is better?

  1. The SNS ledger canister exposes a “mint token” method that only the dapp canister can call. (The governance canister wouldn’t call it because the tokens are minted as a result of some business logic algorithm, not a governance proposal.) The dapp canister then calls that method, which mints X tokens and directly deposits the tokens into the specified user’s account.

  2. The SNS ledger canister exposes no custom method, and instead algorithmically mints tokens, depositing them into the account of the dapp canister (i.e. the reward pool or “treasury”). The dapp canister can then choose to transfer X of the newly minted tokens to the user.

Approach 1 is less safe, as the dapp canister could get hacked and then mint a bunch of tokens into the account of the hacker by calling the “mint token” method.

Approach 2 is less flexible, as the SNS ledger canister now needs to implement the algorithm to decide which users get how many tokens. What if that algorithm needs to be updated? Upgrading the ledger canister is possible via SNS governance proposals (the same way the dapp canister would be upgraded), but it’s arguably more risky to upgrade a highly sensitive ledger canister than a dapp canister.

What do you think? I’m not sure which is better.

2 Likes
22

Thanks, that’s helpful!

23

Thanks for explaining more.

How does the NNS control the SNS wasm module canister? Is it when a new deployment is blessed?

No. When a new deployment is blessed, any principal can upload the (already blessed) wasm to the SNS wasm module canister. Since the SNS wasm module canister will check the registry and only allow versions that are already blessed there, this requires no interaction with the NNS (this was deliberately designed in this way).

However, we want a controller for the SNS wasm module canister in case we need to evolve it. We aim to keep the canister simple, but it can always be that we missed something or find a bug. For this case, to update the SNS wasm module canister, we need someone to control it and orchestrate such upgrades. As with other system cansiters, we propose that the NNS, more specifically the NNS root canister, is the one to do this.

Does this clarify things?

I had assumed you would share the ledger design proposal on the forum.

In the context of the SNS I would say the most important information is that we plan to use a ledger that is almost the same as in the NNS for the first version. If this is something that people would like to discuss, I guess here could be a good place.
If you are more interested in discussing the detailed improvements that are done on the ledger, then I can try to loop in the right people who can elaborate on this a bit more.

24

As with other system cansiters, we propose that the NNS, more specifically the NNS root canister, is the one to do this.

Ah interesting, this is new information. Yeah, it makes more sense.

If you are more interested in discussing the detailed improvements that are done on the ledger, then I can try to loop in the right people who can elaborate on this a bit more.

I think that would be helpful! Sorry for any trouble, but it would be a shame if SNS tokens aren’t compatible with any of the DEX solutions being built by the community.

2 Likes
25

Hi @jzxchiang ,
so the idea would really be to use a ledger that is very similar to the ICP ledger for the SNSs. I think this is the most important point regarding how DEXs can integrate with the resulting SNS ledgers.

I talked to the team working on improving the ledger. The most important things that will be improved to make the ledger that we have more fit for other uses are:

  • one can give the token a name
  • one can decide on the fee on initialisation.

Later, I think the plan is also to remove notify() and use alternative ways to pay for services instead. Note that for staking tokens into neurons, where we originally used notify, we already changed to such an alternative protocol.

I hope this helps!

2 Likes
26

Thanks for the interesting ideas.

Let me maybe first provide a bit more context. You might already know this, but it might also be helpful for other readers.
So the ledger canister specifies and account that is the “minting account”. Whoever controls this account can mint new tokens. If tokens are burned, they are also sent to this account.
In the NNS, this account is the NNS governance canister’s account. This allows the governance canister to mint new tokens when rewards are paid.
I think this would still be an elegant solution for paying e.g., voting rewards in the SNS.

One can also imagine just adding a method on the governance canister that generalises this existing concept: a proposal that calls this method could then mint any tokens (from the governance canister) and send them to any other account (canister or other).

Now in terms of how users can be paid for something that they have done in the dapp:

  1. Your first suggestion would probably imply that the dapp canister would control the minting account. I am not sure this is advisable. First, for the reason that you already stated, as the dapp might get hacked. This is even more concerning if the dapp is on a (currently) less secure subnet. Moreover, it would then be unclear how voting rewards can be paid. Also, I can imagine many use cases where a dapp consists of multiple canisters over time that can easily be added and removed from the SNS by just setting their controllers to the SNS or removing it. Having then one dapp canister with this power to mint might be undesirable.

  2. Here you seem to suggest that the ledger canister itself controls the minting account. I think this is not how the current ledger design intended things to work. In general, we should probably be very cautious of adding more logic to the ledger, as it is now more or less just a database of accounts and transactions. For security (and probably also for integration), it is probably a good idea to keep the ledger canister as simple as possible. But the team working on the ledger could probably provide even more input here.

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.
I think apart from your concern that I share, another tricky thing here is how we can make this generic so that all SNSs can use the same canister code. Also, there might be multiple dapp canisters, so in some cases this might be more complex than just regularly minting tokens to one canister.

I thus think all of these options require some more thought regarding how we can make things generic (so that all/most SNSs can share the canister code) but flexible (so that SNSs have the choice).
From the top of my head, it seems that having a manual proposal every now and then where some funds are just allocated to the right canister (e.g., one of the dapp canisters) and then have the logic how these rewards are algorithmically allocated to users based on their behaviors in the dapp canisters, might be a combination that can cover many use cases…

2 Likes
27

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
28

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.

2 Likes
29

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.

4 Likes
30

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.

2 Likes
31

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?

2 Likes
32

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
33

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.

3 Likes
34

Any progress regarding SNS?

35

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!

3 Likes
36

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

37

I think it will be the NNS ledger token standard.

38

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
39

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

1 Like
40

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.

2 Likes