Enhancement of the SNS launch process: One-proposal

Governance
2

Overview

To recap, the One-Proposal SNS initialization project is meant to streamline and simplify the launch of a Service Nervous System (SNS) on the Internet Computer platform. It was proposed based on feedback gathered from the first SNS launches.

The goal is to condense the numerous steps previously needed to launch an SNS into one single NNS (Network Nervous System) proposal, resulting in two primary benefits:

  1. It reduces the number of manual steps needed to be performed in the launch process.
  2. It makes it easier for NNS voters and swap participants to verify a potential SNS.

In the new process, the creation of an SNS is an “all or nothing” event - one NNS proposal triggers the entire process. The development team only decides on the future of their dapp by indicating that their dapp is open to being decentralized and by handing it over to the NNS. The new NNS proposal contains all initial parameters of the SNS on which the NNS Neuron holders will vote. If the proposal is adopted, the NNS will autonomously create the SNS canisters with the given parameters and start the decentralization swap. If the decentralization swap is successful, the swap canister will also autonomously distribute SNS Neurons to participants. At any point in this process, if there is a rejection of the NNS proposal or a failed decentralization swap, the dapp canisters will be returned to the dapp developers.

Changes by Component

This is a quick summary of the changes that enabled the new feature, listed by component:

  • sns-cli: This is the command line tool that can be used during an SNS launch. Two new subcommands have been added:
    • sns prepare-canisters to assist dapp owners in handing over their dapp to the NNS by adding the NNS Root canister as a co-controller of their dapp canister(s).
    • sns propose to submit the NNS proposal to launch an SNS for a dapp using a yaml configuration file.
  • SNS Init Config File: This is the configuration file where the initial parameters for all SNS canisters is defined. This newly includes initial parameters for the SNS Swap canister. In addition, there is a new “humanize” library that allows parameter values to be specified in more user-friendly units, not just e8s.
  • dfx: dfx now includes the sns-cli as an extension, allowing for a more frequent release cadence of the sns-cli tool making new features and improvements available to users who consume sns-cli through dfx.
  • NNS Governance: A new proposal type named CreateServiceNervousSystem has been added, presenting all data of a to be created SNS within a single proposal. This means that rather than investigating an already deployed SNS, NNS neuron voters and potential swap participants can view all relevant information about an SNS directly from the proposal. This proposal type has the topic SNS & Neurons’ Fund, so NNS neurons that followed other neurons for SNS decisions will still do so after this change.
    Another change in the NNS governance is that, when the proposal is adopted, NNS governance will autonomously trigger the full SNS launch process by requesting SNS-W to create the SNS canisters and subsequently start the swap.
  • SNS-W: The SNS-W canister (the NNS canister responsible for deploying SNSes and storing the WASMs SNSes upgrade to) now automatically transfers the dapp canisters’ control to the newly created SNS, providing voters with visibility into the exact dapps being decentralized.
    The deployment process of an SNS remains similar to the previous method of initialization, except it is automatically triggered by the NNS Governance canister and therefore does not need a manual call. There is no more need for an initial NNS proposal to add a principal to an allow-list in the SNS-W.
  • SNS Swap Canister: The decentralization swap is automatically started without the need for a second NNS proposal and also automatically finalized when conditions are met, eliminating the requirement for any user-initiated call.
  • NNS frontend dapp: The NNS frontend dapp has been updated to support rendering the new proposal.

What Is Proposed For Release

Many components of the SNS one-proposal enhancement have already been released into mainnet both in the NNS and the SNS codebase, however, they remain inactive until a feature flag is enabled. The enablement of the feature flag, which exists in NNS governance and currently disables the submission of the new proposal type, will be voted on by the NNS Neurons as part of the regular NNS release process that will take place in the coming weeks.

Both the current (soon to be legacy) and the new initialization paths for SNSes will be supported and can be utilized. However, we plan to propose to the NNS to deprecate the legacy initialization path in Q3 2023.

If the proposal to enable the CreateServiceNervousSystem proposal is adopted, two more supporting enhancements will be released.

  1. Improvements to the Internet Computer developer docs covering the new SNS launch process will be released, outlining the overall initialization flow as well as a step by step guide for developer teams going through this process. A new section explaining the difference between the methods will be created, and documentation covering the current method (soon to be legacy method) will remain on the website until the legacy method is deprecated.
  2. Updates to the sns-testing repository (a repository that helps prospective teams test launching an SNS locally) will also be available on the day of release. The current (eventual legacy) method for SNS initialization will not be supported on the tip of the main branch, but will be available at a previous commit for those who may still need to access it.
4 Likes