TL;DR For transparency and feedback we are sharing a detailed version of the updated SNS roadmap presented in the January 2023 Global R&D. In order to enable SNS projects as soon as possible, we first focus on eliminating any blockers, then on further improving the user experience, and finally on new features. Our roadmap and the next steps forward address the lessons learned from SNS-1. We aim to resolve the blockers and enable the first SNS launch in Q1 of 2023.
SNS Roadmap
Hello everyone,
After we launched the first SNS DAO at the end of last year, we shared the lessons that we learned from the SNS-1 test run in this forum post. Since then we’ve been working heads down on solutions to many of the detected problems. As we are getting a clearer picture of what is needed we want to share the new SNS roadmap with you.
SNS phases
Before diving into the roadmap, let us recap the different phases that a project goes through for decentralizing and handing over control to an SNS.
- Pre-launch SNS preparation phase: Before the SNS launch, the dapp canisters are typically controlled by a developer team. In this phase, the development team should get ready for the launch. For example, they should ensure that the daily operations and their tooling are sufficiently on-chain so that the dapp is ready to be managed by a DAO.
- SNS launch: This phase is when the SNS is launched for a dapp. This means that the NNS community votes on whether the SNS should be launched, the SNS canisters are created and initialized, and the SNS decentralization sale takes place. In this sale, users can participate by providing ICP in exchange for SNS tokens.
- Post-launch operations of the SNS DAO: After a successful launch, the dapp canisters are controlled by a fully functional DAO that is governed by the community. This community can consist of the sale participants, the original developers, seed funders, and users that received tokens via an airdrop.
SNS roadmap
To facilitate SNS launches as soon as possible, we first want to focus on eliminating blockers, i.e., features that we consider absolutely necessary for an SNS to launch. Next, we want to focus on improvements that strengthen existing functionalities and user experiences. In a later phase, we plan to deliver new add-on features.
We are now presenting the roadmap in terms of features that will enable projects to go through each of the SNS phases successfully. We will also state which features we consider blockers, improvements, and add-ons. Finally, we will also mention how the features address the lessons learned from SNS-1.
Pre-launch SNS preparation
BLOCKERS
-
Tokenomics configuration: When an SNS is launched many configuration parameters can be chosen, notably the initial token distribution, voting rewards and how much of the decentralization sale is allocated to the community fund. We will be providing training material and analysis tools for evaluating different choices of these initial parameters and assessing whether they lead to a decentralized DAO. Please refer to this SNS tokenomics wiki page for further information. Assessing the tokenomics configuration is relevant for the SNS developers, but also for sale participants and NNS voters.
-
Developer tooling - scripts & documentation for on-chain SNS testflight: A DAO can only control programs and assets that are on-chain. However, prior to the SNS launch, developers might use various off-chain scripts for daily operations, such as upgrading canisters. The purpose of this feature is to encourage developers to move all their operations on-chain and test that they are compatible with a dapp that is controlled by an SNS DAO. For this purpose we plan to have a test SNS that allows developers to test how they can trigger operations, such as canister upgrades, by SNS proposal before starting the actual launch process. This is essential for developers to reduce the risk that their dapp becomes non-functional due to the SNS launch process.
This addresses General challenges developing on the IC that we learned in SNS-1 as it aims to simplify the developer experience.
IMPROVEMENTS
- Reduction of off-chain dependencies (infrastructure): The main purpose of handing a dapp’s control over to a DAO is to put it under decentralized control so that there is no single point of failure. If a dapp relies on off-chain infrastructure this is still a point of failure that may be controlled by a centralized party. Therefore, this feature aims at reducing dependencies on off-chain infrastructure. One example is to enable users to use their own custom domains on the boundary nodes which reduces the reliance on external infrastructure.
ADD-ONS
-
Developer tooling - local SNS testing: This feature aims to further simplify the end-to-end developer experience when handing over a dapp to an SNS. One of the key aspects is that there is a simple process for developers to locally test the SNS launch, potentially under different configuration choices, and to locally test the SNS integration with their dapp.
This addresses General challenges developing on the IC that we learned in SNS-1 as it aims to simplify the developer experience.
SNS Launch
BLOCKERS
-
Handle more load in the SNS decentralization sale: In SNS-1, a lot of users experienced difficulty when trying to participate in the sale due to a high demand. Therefore, it is important to ensure that the next sale can handle high participation volumes better. This will be achieved by multiple improvements and better scalability testing to ensure the improvements’ effectiveness. One of the main bottlenecks in SNS-1 was the number of ingress messages that had to be processed. We intend to decrease the number of required ingress messages to participate in the sale with optimizations in the sale APIs and a new caching canister. Also, we enable the subnet to handle more ingress messages: The cost of verifying ingress messages sent via the NNS frontend dapp was high in SNS-1 as these messages include a delegation obtained from II that needs to be verified in addition to the usual signature. The replica code was updated to cache the verification of these delegations which increased the ingress throughput of the subnet. Finally, the UI is improved to provide a better user experience even if there is a high load.
This addresses why the SNS subnet got stuck during SNS-1: While the cause for this bug in SNS-1 has been fixed already, this will further help to avoid such problems in the future. -
Sale payment flow - fixing retries: When users participate in the SNS decentralization sale they contribute ICP in exchange for a share of the initial SNS token allocation. A sale participation consists of a ledger transfer and a notification. As these two calls are opaque for the user, the frontend should ensure that they happen together and retry notification until it succeeds. However, in SNS-1 there was a bug which caused these retries to stop prematurely. Even though all these tokens were refunded and no tokens were lost, this should be avoided by fixing the bug.
This addresses Repeated ICP transfers that we learned in SNS-1 and will make it less likely that refunds are needed. -
Sale payment flow - ticketing system: In SNS-1, if users refreshed their browser pages, a second sale participation was issued for them. This could cause users to participate with a larger number of ICP than they intended. As it cannot be expected that users don’t refresh their pages, this issue needs to be addressed before the next SNS launch. It will be solved by introducing a new ticketing system to the SNS decentralization sale. The idea is that the SNS tracks for all principals the status of ongoing participations. If a user logs into or refreshes the frontend, the frontend would first query the SNS to see if there are ongoing participations and only start a new one if this is not the case.
This addresses Repeated ICP transfers that we learned in SNS-1 and will avoid repeated transfers for the same user. -
Community fund: The community fund introduces the concept of an NNS controlled treasury. One of its main goals is to aid the bootstrapping of the SNS DAO ecosystem by investing in SNS decentralization sales. Therefore this is an important feature to ensure that SNS decentralization sales receive enough funds to be successful.
-
Time gap between NNS proposal adoption and SNS decentralization sale start: The SNS decentralization sale is started as a result of an NNS proposal. In SNS-1, the sale started right at the moment when the NNS proposal was adopted. This meant in particular that the last neurons that brought the number of yes-votes over the 50% majority determined the starting time and users had to closely observe the voting process to be ready when the sale started. To improve this, there should be a delay between the time when the NNS proposal is adopted and the time when the sale is started so that users can prepare for the sale. To avoid that someone can influence the starting time too much (every time is inconvenient for one part of the globe), we further consider adding some randomness to this delay.
This addresses Sale started when the NNS proposal was executed that we learned in SNS-1.
IMPROVEMENTS
-
Mitigating bots: The current sale design is first-come-first-serve. Therefore bots have an advantage, especially in cases where the maximum ICP that can be invested in an SNS decentralization is not large. As it is undesirable for decentralization if many purchases go to the same bot-owning users, an improvement is to make it harder for bots to frontrun others. We consider solving this problem by adding a captcha to the sale participation.
This addresses Bots participating in the SNS decentralization sale that we learned in SNS-1. -
Participation documentation: To make it easier for users to participate, it is important to provide better user documentation so users know what to expect from an SNS. This is realized, for example, in terms of a new SNS FAQ website that is already online and will be continuously improved with new feedback and as more questions arise.
ADD-ONS
-
Sale payment flow - ICRC-2: As a future add-on we want to change the payment flow for participating in the SNS decentralization sale to use approve and transfer_from based on the new ICRC-2 standard. Compared to the payment flow after the first two milestones, this would make it impossible to issue transfers before the start of the sale. Moreover, refunds would only be needed if the sale is unsuccessful.
This addresses Bots participating in the SNS decentralization sale that we learned in SNS-1 where we discussed that some payment-related transfers happened even before the sale started. -
SNS initialization in one proposal: An SNS launch still requires manual steps to create the canisters and initialize them correctly. To make this flow easier in the future, all steps included in an SNS launch, including the SNS canister creation, their initialization, and initializing the decentralization sale, should be triggered by a single NNS proposal.
This addresses Sale started when the NNS proposal was executed that we learned in SNS-1 as this proposal would first create the SNS canisters and then start the sale at a predefined date in the future which is independent of the voting time. -
Better airdrop support: The use of airdrop neurons in SNS-1 was not user friendly and required manually copying principal IDs from one dapp to another. As airdrops are a great tool to promote a dapp and to ensure better decentralization, this feature’s goal is to provide better support for airdrops. Since there are also projects that do not need airdrops we don’t consider this a blocker.
This addresses Use of airdrops that we learned in SNS-1.
Post-launch SNS DAO Operations
BLOCKERS
-
SNS-1 bug fixes: As expected for a test run, SNS-1 uncovered some bugs and details that were confusing for users. For example, there was the issue that users’ airdrop and sale tokens ended up in the same rather than in two separate neurons. Fixing this and other bugs is a top priority before launching the next SNS.
This addresses Neurons with randomized dissolve delays and Incorrect dissolve delays for neurons of sale and airdrop participants that we learned in SNS-1.
IMPROVEMENTS
-
NNS frontend dapp - additional neuron commands and a new token view: To further improve the user experience, we continuously update the frontend with new SNS features as they are ready. This includes SNS neuron commands and a new view for users to see multiple tokens.
This addresses Frontend does not (yet) have all the functionality that we learned in SNS-1. -
SNS dashboard: To facilitate better visibility into what is happening on the SNS canisters for users and developers who interact with them, it is important to have an SNS dashboard. Among other things, the dashboard will help to monitor the cycles of the SNS and dapp canisters that currently still have to be manually topped up with new cycles. We intend to continuously publish features on the SNS dashboard that are ready.
This addresses Delay in neuron creation when sale was finished that we learned in SNS-1 as it is a first step towards easier cycles monitoring, which caused the delay in the neuron creation in SNS-1.
ADD-ONS
-
More automated support for cycles: As mentioned in the last features, ensuring that the SNS and dapp canisters have enough cycles is still a manual process as also described here. The purpose of this feature is to automate this process more, for example by adding alerts or by even topping up the canisters automatically with cycles by using ICP from the SNS treasury.
This addresses Delay in neuron creation when sale was finished that we learned in SNS-1 as it simplifies cycles management, which caused the delay in the neuron creation in SNS-1. -
NNS frontend dapp - voting on SNS proposals: As mentioned, we intend to continuously update the frontend as new features are ready. We prioritize voting less than other SNS functionality as voting is also possible by adding another principal to an SNS neuron as a hotkey and then vote with this hot key on another frontend that already supports this.
This addresses Frontend does not (yet) have all the functionality that we learned in SNS-1.
Progress and outlook
We have already made progress on a lot of the blockers and improvements. For example, you can already check out the current status of the improved NNS frontend dapp, the new SNS dashboard, the SNS tokenomics wiki page, and the new SNS FAQ website. The custom domains feature has been demoed in the January 2023 Global R&D. We are looking forward to sharing more updates and demos with you as they are ready and estimate that we will complete the blockers and enable the next SNS launch in Q1 of 2023.
We hope that gives you a good overview of our current plan and are looking forward to your feedback. We are excited to see these projects making progress and of course to the next SNS launch! Stay tuned!