More information on Proposal 108634 “Enable principal omnzo-7qaaa-aaaal-qbtpq-cai in SNS-W to initiate the generation of an SNS for OpenChat”

[lara]

TL;DR

We provide additional information about the NNS proposal 108634.

• SNS canister installation is currently limited to pre-approved principals
• The proposal approves a DFINITY principal and allows it to install the SNS canisters that are required to launch an SNS for OpenChat
• In the long term these manual steps will be removed and we will move to a single NNS proposal for SNS creation

Intro

Yesterday, the OpenChat team submitted an NNS proposal with title “Enable principal omnzo-7qaaa-aaaal-qbtpq-cai in SNS-W to initiate the generation of an SNS for OpenChat” and with proposal ID 108634. As the proposal explains, “this proposal offers the OpenChat dapp to the NNS to be turned into a decentralized service by creation of an SNS to govern the OpenChat canisters”. Thus, should this proposal be adopted, this is the first step towards enabling an SNS launch for the OpenChat dapp.

In this forum post, we will

• Confirm that the principal omnzo-7qaaa-aaaal-qbtpq-cai is owned by DFINITY as claimed in the proposal,
• Explain in more detail what this principal will be able to do if the proposal is adopted, and
• Explain in more detail how the SNS launch process works now and in the future.

We start with the last point as this will help with understanding the other points.

How an SNS will be deployed in the future.

The vision is that a dapp can be handed over to the NNS and be offered for decentralization in one single proposal. That is, we propose a design where there is one single NNS proposal that can be voted on by the NNS community and that, as a result, creates the SNS canisters, sets the initial parameters for all SNS canisters, sets the parameters for the decentralization sale, and automatically starts the decentralization sale at a later date.

Instead of waiting for all features, we release features as they are ready so that the community can already use them and aim to continuously improve the SNS. This includes the SNS launch, where the implementation does not yet implement the above described design.

How an SNS is deployed today.

Currently, the process of launching an SNS is split up in two parts and still requires some manual steps.

1. First, the SNS canisters are created and their initial parameters are set by a manual call to the NNS canister called SNS-W (SNS wasm modules canister). The dapp’s control is then handed over to the SNS canisters, which are in a pre-decentralization-sale state with limited capabilities. In this state, the developer neurons exist and they can upgrade the dapp canisters through the SNS already.
2. Second, an NNS proposal is submitted. The NNS voters can now verify the parameters in the already existing SNS canisters as well as the sale parameters that are set in the proposal. If the proposal is adopted, the SNS sale is started and if the sale is then also successful, the SNS is launched. If the proposal is rejected, for example because the NNS community rejects the chosen parameters from Step 1 or the sale conditions proposed in Step 2, then the SNS launch fails and the dapp is handed back to the developers.

To ensure that malicious parties cannot simply perform the first step and fill the SNS subnet with non-approved SNS canisters, SNS-W contains a list of allowed principals that are allowed to install an SNS. This is what proposal 108634 is about: it adds the principal omnzo-7qaaa-aaaal-qbtpq-cai to the allowed principal list in SNS-W so that it can install exactly one SNS. After this one call, SNS-W automatically removes the principal from the list again, so this can only be done once.

The effect of an adopted proposal 108634 and what this means for the principal omnzo-7qaaa-aaaal-qbtpq-cai.

If the proposal is adopted, the principal omnzo-7qaaa-aaaal-qbtpq-cai is added to a list in SNS-W that allows it to install one SNS.

Let’s look at the details and where you can look in the code to convince yourself that this is the case.

• If the proposal 108634 is adopted, it will call the method update_allowed_principals on SNS-W. This will add principal omnzo-7qaaa-aaaal-qbtpq-cai to the list allowed_principals that SNS-W stores. There are the principals allowed to install an SNS. If you look at the method update_allowed_principals here you can see that only NNS governance can call it, which means that this list can only be changed by an NNS proposal.
• After principal 108634 is in allowed_principals, it is allowed to call the method deploy_new_sns on SNS-W, which installs and SNS.
  • deploy_new_sns uses the method consume_caller_from_whitelist which has two effects:
    1: it checks that the caller principal is in allowed_principals. If someone else calls this method, SNS-W will return an error.
    2: The caller principal is “consumed”, which means that it will be removed from allowed_principals. This implies that the principal can only make this call once. Only another NNS proposal to add the principal again to the list would allow the principal to repeat this process and install another SNS.

What the principal omnzo-7qaaa-aaaal-qbtpq-cai is and who controls it.

The principal omnzo-7qaaa-aaaal-qbtpq-cai is a cycles wallet. This is because a call to install SNS canisters needs to send along cycles with which the SNS canisters are initialized.

The cycles wallet omnzo-7qaaa-aaaal-qbtpq-cai has multiple controllers, each of which is controlled by a different DFINITY engineer.

Q&A

Q: If we envision a different design in the future, why do we not wait for this design to be done?

A: We think we should release whatever is ready so that the community can build on it. It should be up to the individual projects to decide whether the current product is sufficiently meeting their needs or whether they would like to wait for future versions of it.
In particular, some projects might need the funding that an SNS decentralization sale can help collect or they might need the SNS as a marketing tool to attract more users. We want to unblock them.

Q: How do I need to trust the controllers of the cycles wallet omnzo-7qaaa-aaaal-qbtpq-cai?

A: The worst thing that any controller of this wallet can do is to install an SNS, possibly with useless configurations. However, this SNS will not be fully functional, especially no tokens can be moved, without the second NNS proposal to start the decentralization sale.
In particular this can only be done once, as such a call would remove the cycles wallet from the list again (see explanation above).

Q: What if I do not like the parameters that the SNS canisters are initialized with?

A: As explained above in “How an SNS is deployed today“ and as also mentioned in the proposal, the NNS community can and should review the parameters that the SNS canisters were initialized with in the second NNS proposal to start the decentralization sale. The still have the possibility to reject the parameters, and thereby the SNS launch, at this point and the dapp would then be handed back to the developers.

[justmythoughts]

@lara

To ensure that malicious parties cannot simply perform the first step and fill the SNS subnet with non-approved SNS canisters, SNS-W contains a list of allowed principals that are allowed to install an SNS. This is what proposal 108634 is about: it adds the principal omnzo-7qaaa-aaaal-qbtpq-cai to the allowed principal list in SNS-W so that it can install exactly one SNS. After this one call, SNS-W automatically removes the principal from the list again, so this can only be done once.

Quick question:

Let’s say after step 1 (first proposal passes), I install the SNS warms and receive my developer neurons. For the sake of this example, let’s say my principal now holds > 50% of VP and can pass proposals immediately.

In this state, the developer neurons exist and they can upgrade the dapp canisters through the SNS already.

In this intermediate state before step 2 (before the Dapp is handed over to the SNS), does this allow the developer principal that created the SNS canisters to also upgrade those recently deployed SNS canisters/parameters of those SNS canisters, or does it only allow one to upgrade the Dapp canisters through the SNS canisters?

It seems like it’s the latter, based on this code, but I just wanted to verify.

dfinity/ic/blob/0383abff70551d731d1d7a4810cd95f53c520365/rs/nns/sns-wasm/src/sns_wasm.rs#L665

I just want to make sure that there’s no loopholes that would allow anyone to actually change any part of the code of any of their SNS deployed canisters at this point (i.e., that would then allow someone to upgrade and transform an SNS canister into a canister factory that could fill up the SNS subnet).

[wpb]

Thank you @lara. Your explanation was very helpful and makes sense. It filled in many of the gaps in information that I couldn’t find publicly after first reviewing the proposal. I’m glad to know that you can verify the identity of the proposer as well as the principle that is included in the payload. I received confirmation from the OC team earlier today as well. It is very helpful to see forum posts about proposals (preferably in advance) because it’s a two way conversation that enables verification of proposal details. Thanks!

[msumme]

@justmythoughts

In this intermediate state before step 2 (before the Dapp is handed over to the SNS), does this allow the developer principal that created the SNS canisters to also upgrade those recently deployed SNS canisters/parameters of those SNS canisters, or does it only allow one to upgrade the Dapp canisters through the SNS canisters?

@justmythoughts Developers cannot upgrade SNS canisters except along the blessed upgrade path, before or after the sale. The SNS canisters are never under developer control. The SNS-W canister does the deployment, and at the end of that deployment it sets all SNS canisters to be controlled by the SNS Root (which itself is only controlled by SNS Governance). The Swap canister remains in the control of the NNS.

[justmythoughts]

@lara

They can then choose to follow the blessed upgrade path or deviate from this path, e.g., leaving out some versions, or even modify the canisters’ code in a completely different way. In this option, canister upgrades require active actions of the SNS community (i.e., the submission of a proposal) and the SNS community has to ensure that the upgrades are secure.

@msumme maybe I need to understand more about the blessed upgrade path then. I haven’t dug too deep into that, so forgive me if my questions are redundant and have been answered elsewhere.

In the time between step 1 & 2, when the developer could have full control to pass any proposal change (before the decentralization of the dapp), can they upgrade their SNS canisters through this blessed upgrade path?

For example, Since the SNS governance canister controls the SNS root canister, can it upgrade the root into anything it wants to (a malicious factory canister?)

[msumme]

So the quote you have from the design document talks about a self-deployed SNS. This is not fully implemented or supported at the present, so it doesn’t apply either way.

If an SNS is deployed through SNS-W, it is only on a blessed upgrade path. That upgrade path is set via NNS proposals. The SNS deployed in that way will always be on a blessed upgrade path unless there is some extraordinary action taken via NNS proposal to move it onto some SNS version that could be completely managed by the SNS community. That would require development work in addition to community action.

@justmythoughts

In the time between step 1 & 2, when the developer could have full control to pass any proposal change (before the decentralization of the dapp), can they upgrade their SNS canisters through this blessed upgrade path?

Yes, they can upgrade their SNS canisters through the blessed upgrade path.

@justmythoughts

For example, Since the SNS governance canister controls the SNS root canister, can it upgrade the root into anything it wants to (a malicious factory canister?)

No, the SNS Governance can only upgrade Root along the blessed upgrade path maintained by SNS-W. If an NNS proposal added that malicious version of Root to the SNS-W, then yes, but that is more or less the risk for everything on the entire IC. If a malicious proposal was passed, NNS Governance could be changed to do bad things.

Hopefully that answers your questions.

[justmythoughts]

This answers my questions, thank you.

[Berg]

Not the best time for a cash grab tbh. Hope voting sentiment stays the same until the end.

[Samer]

I wouldn’t call it a cash grab but I myself was expecting a SNS-2 test first

I voted no

[hpeebles]

The dev team will receive their CHAT tokens in neurons which vest over 4 years.
We are here for the long term, this is definitely not a cash grab.
All of the ICP raised will be held in the SNS treasury and is under community control from day 1.

[Berg]

I actually meant the 8%, given to Dfinity due to being early investors. At what price did they invest?

[hpeebles]

Dfinity have funded the development of OpenChat for the past 2 years.

So they didn’t really have an exact buy in price, but they took on the risk of funding us with no guarantee of any return.

Also, their neurons vest over 2 years, with the earliest one only vesting after 6 months.