Testing SPS locally

Advanced

Governance

Tutorial

Overview

To help developers, BigFile has created the sns-testing repo which has scripts that help developers test the SPS process. Developers can run a local version of the BIG execution environment on their local machine, deploy their dapp locally and run through the stages of decentralizing their dapp.

sns-testing repo might not work for any dapp. It is intended to showcase one example dapp and so one can tweak for their own dapp.

After having chosen the initial SPS parameters in a .yaml file and before requesting an SPS launch in production, the SPS launch should be tested locally.

The main intent of sns-testing repo is for a developer to test the actual process of decentralizing their dapp.

Among other things, developers can use sns-testing repo to:

Initiate proposals.
Pass proposals.
Start decentralization swaps.
Upgrade dapp via DAO voting.

sns-testing is just one form of testing SPS process locally. Developers should feel free to use others, fork/modify sns-testing or create their own.

Using the `sns-testing` repo

These scripts have been most tested with a stack that looks like this:

A single canister that is being decentralized.
A canister that can be deployed to local replica via dfx deploy.

Getting started

To use the sns-testing commands and their arguments properly, you need to first set up the sns-testing repo properly. Please see README.

All of the commands in this article require sns-testing to be set up properly.
If you have started using sns-testing before August 2023 and are using the old legacy flow of launching an SPS (please see here for more context), please continue your work with the legacy documentation on this old README. In particular,
If you were following the Apple silicon-only instructions, please switch to the v1-legacy Git tag.
If you were using the Docker-based deployment approach, please use the docker image: docker pull ghcr.io/dfinity/sns-testing:v1-legacy.

Testing stages of the SPS launch process

For simplicity, next the stages introduced in the SPS launch stages documentation in the documentation commands and actions to go through SPS launch are mapped to the relevant scripts in the sns-testing repo so you can learn what part of the launch is tested in which script. Note that some developers have dapps that do not match the narrow cases of sns-testing so the table also includes a column for what other developers have experienced.

Stages

0. Deploy a dapp to the local replica.

Option 1: Testing a pre-packaged dapp created in `sns-testing` just for purposes of testing

./deploy_test_canister.sh

Option 2: Deploying your own single-canister dapp

dfx deploy

Option 3: Deploying your own multi-canister dapp

In this case, you should use whatever scripts or set up you have to deploy your dapp.

1. Dapp developers add NNS root as co-controller of dapp.

They can do so by running the following command:

Option 1: You have one canister

dfx sns prepare-canisters add-nns-root $CANISTER_ID

Option 3: You have many canisters, run it for each canister ID

dfx sns prepare-canisters add-nns-root $CANISTER_ID_1
dfx sns prepare-canisters add-nns-root $CANISTER_ID_2
...
dfx sns prepare-canisters add-nns-root $CANISTER_ID_N

2. Dapp developers choose the initial parameters of the SPS for a dapp.

Typically, dapp developers choose initial parameters that will be used in subsequent proposals.

Fill out this file:

example_sns_init.yaml

3. Submit NNS proposal to create SPS.

Submit an NNS proposal that ingests the example_sns_init.yaml file from stage #2

dfx sns propose --network local --neuron $NEURON_ID example_sns_init.yaml

$NEURON_ID comes from the sns-testing setup