Verification and trust in a (launched) SNS

If you participate in an Service Nervous System (SNS) DAO by getting some SNS tokens in liquid form or by staking them in the SNS governance canister or if you use a dapp that is under SNS DAO control, you rely on the fact that the SNS DAO is trustworthy. This article elaborates on what verification you can do to convince yourself of the trustworthiness of the governed dapp and the SNS canisters. If you cannot or do not want to verify everything yourself, you should be aware that you are implicitly trusting some other parties.

This page describes on a high level how to minimize trust requirements through verification when participating in an SNS DAO. It also describes what needs to be trusted when various parts are not verified. You also trust certain parties when you participate in an SNS decentralization swap, which is described here. Note that some trust assumptions are the same, so you will find some sections and paragraphs in this linked article as well as on this page.

Finally, at all times you trust the NNS community in that they fully control the Internet Computer platform.

Verify the SNS DAO participants

Why?

When you use a dapp or participate in the SNS DAO that governs the dapp, you should be aware of who is controlling them. For example, if a SNS DAO is not properly decentralized it might be that few centralized parties can decide on how the SNS DAO and the governed dapp are changed.

Verification

• Verify or trust that the SNS DAO community is decentralized or trust a few centralized parties. The main idea of a DAO is that many independent parties contribute to decisions and that therefore no trust in central parties is needed. However, for a given DAO you should verify that this decentralization indeed holds.
  • Unfortunately, it is not straightforward how to do this in practice as the SNS DAOs identify users by principals, however the same real-life entity might own multiple principals (also known as “sybil attack”). You might be able to verify decentralization to some extent if different users identify themselves outside of the DAO and can prove that they own certain principals.
  • Even though this does not provide any guarantees, it also makes sense to at least exclude obvious cases of centralization, by checking that there are not few principals that own a majority of the neurons.
  • If these measures are not enough to fully prove that the DAO is decentralized you implicitly trust that this is the case. Alternatively, you can accept that there might even be few centralized parties that govern the DAO / dapp, in which case you need to trust these parties.

Verify the SNS canisters

Why?

You should make sure that you are in fact interacting with a real SNS and that the SNS canisters run trustworthy code, as otherwise they could for example steal the tokens that you own on the SNS ledger or that you staked on SNS governance. You should also ensure that the configurations in the SNS are trustworthy as otherwise the voting rules or tokenomics could be unfavorable and allow for attacks, such as adopting unwanted proposals decided by few parties.

Background

All SNS canisters run on a dedicated SNS subnet. The only canister that can install an SNS is an NNS canister called SNS-W. It will only install SNS canisters with code (Wasms) that have been pre-approved by the NNS. Also, it will always set the controllers of the canisters in a predefined way so that the SNS canisters control each other except for the SNS swap which is controlled by the NNS. SNS canisters can be upgraded to Wasms versions that are pre-approved by the NNS and also stored on SNS-W.

Verification

• Verify that the canisters that you interact with are indeed SNS canisters. This is one of the most important things to verify, as otherwise you could send your tokens to canisters that are not trusted and might steal your tokens. The NNS frontend dapp launchpad only displays real SNSs that are installed on the SNS subnet. If you trust the dashboard, you may also use this page to identify the SNSs on the SNS subnet.

• Verify the SNS canisters’ controllers. As mentioned, the SNS canisters are set up with predefined controllers. If you don’t verify this, then you trust the NNS that a) the SNS-W code initialized the SNS correctly and b) the SNS canisters’ code (that has been approved by the NNS) does not allow changing controllership after initialization.
• Verify the SNS canisters’ Wasms. As mentioned, the SNS canisters are installed with and can only be upgraded to Wasms that have been pre-approved by the NNS. You can either verify all the SNS canisters’ Wasms or trust the NNS community that they only approved trustworthy WASMs. Note that in general, you must trust the NNS community because the NNS community can update the platform. Specific to the SNS, the NNS community can also approve new SNS Wasms.
• Verify the SNS canisters’ state and configurations. Each SNS can have custom configurations. It is important to verify these configurations as they influence, for example, how proposals are decided and how voting rewards are distributed. To verify the configurations and the general state of the SNS canisters, you should verify the initial settings and how they have changed since then.
  • The SNS canisters initialization is approved in an NNS proposal. Thus, you can either verify the initial configuration and state or you need to trust the NNS community that they have done so.
  • After the SNS canisters are installed, their configurations can be changed by SNS proposals. Thus, to ensure that the SNS canisters remain with a desirable configuration and state you can either verify the SNS proposals or trust the SNS community to do so.

Verify the dapp canisters and other assets

Why?

You should make sure that you are in fact interacting with dapp that is fully governed by an SNS as otherwise there might still be centralized parties that can change the dapp in any way and steal valuable assets, such as tokens, that are stored in the dapp.

Background

The dapp that is governed by the SNS DAO might consist of multiple canisters, some of which might be directly governed by the SNS DAO and other which might be indirectly governed by the SNS in that a given dapp canister is controlled by another dapp canister that is in turn controlled by the SNS. This might also include an asset canister that serves the asset that you see when you interact with the dapp’s frontend.

Verification

• Verify that the dapp is fully SNS controlled.
  • To do so, verifying all canister’s controllers. The dapp canisters should be controlled by the SNS root canister only or by another dapp canister that is in turn controlled by SNS root (this can also be over a longer chain of control that leads to only the SNS root at the top). This ensures that the dapp canisters cannot be changed without SNS approval.
  • In addition, you should verify that the SNS accepted the control of the dapp canisters. This is important as anyone could assign SNS root as a controller of their, potentially malicious, canister without the SNS community knowing and accepting this canister. You can do so by calling list_sns_canisters on SNS root and looking at the canister IDs listed in dapps. For example, for the OpenChat SNS, you can find this command on the dashboard page for their SNS root canister here.
  • You should also check that the dapp canisters do not rely on external code, outside of the dapp and thus of the SNS’ control, for their core functionality as this code might not be trusted. If this is not possible, see the next point.
• Trust the external components of the dapp. A dapp might rely on external components, e.g., calls to other dapps or even off-chain components. As a user you need to trust these components as they are not controlled by the SNS. If they are off-chain this might also require trusting certain platform providers or other centralized entities.
• Verify the app canisters’ Wasms. To make sure that the dapp canisters are trustworthy you should verify the code that they run. Otherwise you trust the SNS community with this fact if there was already at least one upgrade since the dapp has been handed over to the SNS or the dapp developers if this is not the case. One the dapp is under SNS control it can only be upgraded via SNS proposals, so you can make sure that you don’t miss any new modification by monitoring all SNS proposals.
  • Some things to watch out for are to verify that the canisters do not have any “backdoors”, for example methods that can be called from the outside, maybe just by some defined principals that would then have centralized control over this method call.
  • For some privileged methods that should only be invoked by an SNS proposal, you should verify that the code enforces that these methods can only be called by the SNS governance canister.
• Verify that the dapp canisters have a clean state. Most dapp canisters will be deployed by a centralized party and then just handed over to an SNS. Even if these canisters’ control was handed over to an SNS DAO, they might still contain malicious state that is preserved over upgrades. Therefore, to fully trust a canister you would also have to convince yourself that after it is handed over to the SNS DAO its state has been cleaned up. You can do so by verifying the corresponding SNS proposal or by trusting the SNS community. Alternatively, you trust all the previous controllers of the dapp canisters (e.g., the original developers).
• Verify the asset canister. The asset canister has a list of principals who can update assets. It should be configured such that this list of privileged principals can only be changed by SNS proposal. You should verify that this is the case. You should also understand which people own the privileged principals and you have to trust them not to upload malicious assets.