Based on the feedback collected during the SNS launch of SNS-1 and OpenChat, it was requested to simplify the launch process for an SNS.
In particular, it is suggested to combine the various steps for launching into one process which would be triggered by the SNS proposal submission.
The combination of all preparation steps into one process would have two main advantages: It becomes easier to launch & verify an SNS and the responsibility of the complete launch, including the issuance of a token, is linked to the proposal.
Suggested requirements of 1-proposal
The creation of an SNS should be “all or nothing”, thus it should be one proposal.
The NNS, not the dev team, creates the SNS and its tokens.
The dev team can decide on the future of their dapp by expressing that their dapp is open to being decentralized and by recommending certain settings in the DAO (e.g. initial parameters, how many tokens they get, etc.)
Both the NNS (via NNS Proposal) and the dev team need to agree on all parameters and only then is the SNS DAO created and the dapp is decentralized via the swap.
The dev team can safely integrate and test out all DAO functions.
The dapp can be upgraded during the launch process (when the NNS proposal is ongoing and during the swap), so that for example urgent bugs can be fixed immediately.
Given that this is a one-shoot solution (instead of doing launch steps iteratively) it is required to have tooling for validation checks of various parameters, such as ledger, governance, swap etc (ideally as pre-launch check but also as a check included in the launch)
Required changes by component
Launching an SNS would newly consist of the following steps:
Dev team adds NNS root as controller to the dapp canister
One NNS proposal is sent (specifying all configuration parameters)
As a result of an adopted proposal,
the SNS is automatically created
the SNS swap is automatically started
The swap lasts for the specified time period and afterwards the swap is automatically ended.
This leads to the following changes by component
NNS governance
Parameters: The new NNS proposal (CreateServiceNervousSystem) needs to include the SNS configuration parameters which were set previously in separate steps. This includes all parameters affecting tokenomics and governance. For example the initial token allocation, configuration of voting rewards, community fund investment, swap duration etc.
Proposal action: The proposal is of topic SnsAndCommunityFund, but a new action will be required with the name CreateServiceNervousSystem.
Proposal validation: When the proposal is submitted it should be validated before being put to vote. The validation should include a check that the NNS root has been added as a co-controller of the dapp and new consistency checks of various parameters. Only one NNS proposal of this type should happen at a time (this might be enhanced later). If the proposal is adopted, this results in a call to SNS-W with the SNS configuration and SNS-W will create and install the canisters.
SNS-W
Orchestration of SNS creation: SNS-W has a new method that creates an SNS with all parameters available at initialization.
Requests that NNS root (the co-controller of the dapp during this proposal) takes control of the dapp and removes the dev team as co-controllers. Abort if the dapp is no longer co-controlled by the NNS (i.e. dev backed out due to non-agreement with NNS proposal).
Create the canisters on the dedicated SNS subnet (same as now)
Loan initial cycles to the newly created SNS that will be repaid by the SNS during finalization.
Install wasms with initial payloads configured in the NNS Proposal.
Transfer controllership of the dapp to the newly deployed SNS.
The swap is initialized with parameters set in the NNS proposal, including the swap start date. This allows the swap to start autonomously.
Ensure controllership of the dapps is returned to the developers if any part of SNS deployment fails.
NNS Root
Controllership: The NNS root will be the co-controller of the dapp until the SNS can assume control. SNS-W and NNS governance will get the canister status of the dapp through NNS root during the creation process. SNS-W will request NNS root to assume control of the dapp when the proposal is adopted and executed, and then hand control to the SNS.
SNS swap
Start of swap: The start of the swap is specified as a time of day in UTC. After the NNS proposal succeeds, a 24 hours delay is calculated. After those 24 hours, the next occurrence of the specified time of day will trigger the swap, and this timestamp is passed to the swap canister.
End of swap: Require a duration of the swap in the NNS proposal. If the end is reached, end the swap. If the swap is ended, finalize the swap automatically. If the swap finalization fails, allow for manual retries.
Since the SNS-W has loaned the newly created SNS the cycles for its initial operation, the swap canister will use ICP raised as part of the decentralization swap to repay the loan from the SNS treasury.
SNS root
Allow transfer of controllership from sns-wasm to SNS root autonomously.
SNS governance
The SNS governance should parse the initial parameters and keep them forever to act as the initial starting point for the audit trail of an SNS.
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:
It reduces the number of manual steps needed to be performed in the launch process.
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.
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.
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.
Hi @ZackDS, enablement of the feature flag will not be done in the upcoming NNS release. We will be explicit in the release notes when this proposal will be available for voting.
The bug-fix associated with multiple OpenSnsTokenSwap is currently being tested and staged for proposal submission by the NNS team. You can follow this thread for direct updates on it.
The NNS team took extra caution to not enable the 1-proposal feature while working on the bug-fix, but we are planning to enable 1-proposal in the next proposal cycle. Keep an eye out for the NNS Updates forum post next week
Sorry, I finally found the post at Suggested enhancements to the Community fund (item 1). Apparently, the ratio is already set to 1/3. Perhaps smoothly decreasing the parameters would be the best approach. Currently, projects are taking about 60% of the contributions from the NF. @bjoernek
