I’m currently in the process of setting up and testing an SNS locally, i’ve specified my sns_init.yaml and changed it accordingly. After running a $(dfx cache show)/sns init-config-file validate it doesn’t come up with any issues.
When trying to test this locally with the sns-testing repo it’s far from plug-and-play and encountered the multiple issues;
when changing the fallback_controller_principal_ids and first developer neuron controller, it does not work because there is a script that replaces the default aaaaa-aa principal
When adding more then 1 airdrop neuron it fails, it keeps hanging in a Using identity: "default". loop
There were some other issues i encountered as wel and after some digging through the scripts i could find what went wrong because of the error on the propopsals.
all and all, i dont think this is the correct way to verify my sns_init.yaml and being able to check the outcome in an easy way. One of the things i would like to check is the total amount of tokens, so airdrop + developer + swap + treasury. And if my swap properties are set correctly.
What is the best way to do this, i’m kind of breaking my head over this.
Set the first developer neuron and the fallback_controller to the management canister id. The executing script will automatically replace it with the principal of the dfx identity that is executing the script
Can you clarify this further? Maybe a screenshot of what you’re seeing and the exact entry of what this looks like in your sns_init.yaml file
This is already taken care of by the init-config-file validate that you ran. The deploy_sns script also does this internally. So you wouldn’t be able to pass invalid parameters that don’t satisfy the constraints
i figured that the ./wait_for_last_sns_proposal.sh is the one creating the issue, this runs ./get_last_sns_proposal.sh in a while loop, but when i run this script manually it just gives a good (no error) response.
So i’m kind of stuck on that.
As we privately discussed it, this was more the math of the total tokens but for everybody reading this i should clearify it again.
If i remove the all airdrop neurons + add the default aaaaa-aa developer neuron, I am able to get the sale showing in the local NNS. But because i miss the crucial data (airdrop-, developer neurons), the total supply showing isn’t correct (swap + treasury + developer neurons + airdrop neurons).
I think the check you are mentioning is related to the sns-token-e8s argument on the propose-to-open-sns-token-swap call and the swap_distribution.total_e8s in the sns_init.yaml
Thank you for raising this and I am sorry for the inconvenience. We are constantly trying to improve the sns-testing repository and having feedback like yours is helpful to identify where the shortcomings are. Let me see if I can help.
If is specify more then 1 airdrop (or developer) neuron it fails and keeps looping Using identity: "default".
It seems like you are running into issues with how the config file is interacting with the repo. For me to better understand and help debug I’d like to try to repro the issue you are encountering locally. If you wouldn’t mind, could you share the sns_init.yaml file you are using as a separate file. This is safe to do as this will be all public info once you create the SNS. Additionally, it would be very helpful if you could copy/paste the exact scripts you are running, in order, and whether they run successfully or not. This will help me pinpoint the exact issue you are encountering and I can either submit a fix to sns-testing or give a pointer to what should change when running the tests.
When adding more then 1 airdrop neuron it fails
While there is support for airdrop neurons while configuring an SNS we recommend closely examining whether this is something you’d like to include. Airdrop neurons are distributed at genesis (at the same time as developer neurons) so it might be the case that developer neurons do not have majority voting power at genesis and before the swap is complete. We’ve previously seen that it takes time for community neurons to get used to voting and this may prevent the developer neurons from executing proposals like registering dapps and adding GenericNervousSystemFunctions. It could also prevent upgrades to the SNS controlled dapps before the SNS is fully decentralized. This is why OC and HotOrNot distributed airdrops separately from installation, and is recommended path. Additionally, support for airdrops at genesis will be disabled when the new 1-proposal SNS initialization feature is complete (you can see the design of 1-proposal in this forum post Enhancement of the SNS launch process: One-proposal).
One of the things i would like to check is the total amount of tokens, so airdrop + developer + swap + treasury . And if my swap properties are set correctly.
Thank you for raising this. In the current configuration (v1) this is done by hand at the moment. While not helpful for you at the moment, the v2 configuration that will be released along with 1-proposal will have a checksum at the end that validation will ensure matches the amount specified in the config. We also created a humanize library that will allow you to specify distribution amounts in e8s or whole tokens. This will hopefully make writing the configuration file somewhat easier.
Specified below is the yaml file, the things i tried;
moving all neurons to the developer neurons spot (and including the aaaaa-aa neuron as wel)
moving all neurons to the airdrop neurons spot (and keep the aaaaa-aa as a developer neuron)
For now the only thing that worked for me was;
to have a single developer neuron (the aaaaa-aa controlled)
and an optional 1 airdrop neuron which i also made aaaaa-aa controlled)
With the above configuration it will run the default steps with ./run_basic_scenario.sh and it will reach the part where the decentralized sale is started, 3 people participate and viewable from the local NNS dapp.
It then goes into a Using identity: "default". loop, I think its caused by the while loop inside the wait_for_last_sns_proposal.sh. But if i run get_last_sns_proposal.sh manually, i get a valid response, so not sure where the issue is, i’m maybe thinking its due to the changed tokenomics, but not able to verify this.
wait_for_last_sns_proposal.sh
#!/usr/bin/env bash
set -euo pipefail
cd -- "$(dirname -- "${BASH_SOURCE[0]}")"
while [ "$(./get_last_sns_proposal.sh | ./bin/idl2json | jq -r '.proposals[0].executed_timestamp_seconds')" == "0" ]
do
sleep 1
done
for clearity, i’ve ran into different issues as wel due to the invalid / not compatible config, where it also reached an infinity using identity loop but i was able to debug it by searching for the scripts, manually running the methods and see if any error occured, but this doesn’t seem to be the case in the last scenario.
@aterga Might be able to speak more on this, but I am unsure of how the run_basic_sceanrio.sh should be executed as I believe this is setup to validate your locally running sns-testing instance running correctly. In the meantime I took your configuration file and followed the README.md instructions under the SNS Lifecycle section. Below are my results:
Major Differences
I had to modify your pasted sns_init.yaml file in a few ways listed below:
Used a local logo instead of your pasted cat_logo.png. This should be irrelvant to the issues you have been facing
I had to adjust the max_dissolve_delay_seconds as it is lower than the largest dissolve delay of the allocated developer and airdrop neurons you’ve configured.
Output
# After going through the `Special instructions for Apple Silicon users` section I had a working local replica with an NNS correctly setup.
$ ./cleanup.sh. # cleans up my local directory of previous setups
$ ./bin/sns init-config-file --init-config-file-path sns_init.yml validate # sns_init.yml is the file I pasted your config into
> Error: The following PrincipalIds have a dissolve_delay_seconds configured greater than the allowed max_dissolve_delay_seconds (63115200): [4zlt2-vxp3s-g2tcw-grw4q-w24x3-4qnxn-tnscz-5sxww-dvwwt-6excq-oae, swlp6-6qujk-ozivy-wtwp2-rkvp5-figiu-j7mdt-rztl2-jgvfg-bn4jg-bqe, bvlzq-24tlm-zhrcz-kx5ob-cg43a-2ob76-loxjw-cjhgf-w7kbl-pzjip-oae, yx3ml-4i746-rhl4a-p5tzt-pnvp2-vco4x-oapb5-d6ylj-im5jt-pvb2n-qae]
# Fixed this issue by updating the `max_dissolve_delay_seconds` to 63120000 in your configuration
$ ./bin/sns init-config-file --init-config-file-path sns_init.yml validate
> No Errors Found
# I then followed the SNS Lifecycle Instructions in the README.md
$ ./deploy_test_canister.sh
$ ./deploy_sns.sh sns_init.yml
# This successfully ran with your configuration file
$ ./get_sns_canisters.sh
# I wanted to validate that there was a newly deployed SNS
(
record {
root = opt principal "asrmz-lmaaa-aaaaa-qaaeq-cai";
swap = opt principal "ajuq4-ruaaa-aaaaa-qaaga-cai";
ledger = opt principal "a4tbr-q4aaa-aaaaa-qaafq-cai";
index = opt principal "aovwi-4maaa-aaaaa-qaagq-cai";
governance = opt principal "a3shf-5eaaa-aaaaa-qaafa-cai";
dapps = vec {};
archives = vec {};
},
)
$ ./register_dapp.sh by6od-j4aaa-aaaaa-qaadq-cai # Output from deploy_test_canister.sg
# Note this failed due to not having access to the identity.pem of one of the develoepr neurons you had configured in your sns_init.yaml. However, when I reran this test with a modified sns_init.yaml with an identity i controlled it worked fine.
# With the next step I modified the ./open_sns_swap.sh script to match the values you provided for the ic-admin command. this was the contents of the ic-admin command so you can see it yourself
#
# ic-admin \
# --nns-url "${NETWORK_URL}" propose-to-open-sns-token-swap \
# --test-neuron-proposer \
# --min-participants 125 \
# --min-icp-e8s 65000000000000 \
# --max-icp-e8s 130000000000000 \
# --min-participant-icp-e8s 100000000 \
# --max-participant-icp-e8s 10000000000000 \
# --swap-due-timestamp-seconds "${DEADLINE}" \
# --sns-token-e8s 11250000000000000 \
# --target-swap-canister-id "${SNS_SWAP_ID}" \
# --community-fund-investment-e8s 40000000000000 \
# --neuron-basket-count 3 \
# --neuron-basket-dissolve-delay-interval-seconds 31536000 \
# --proposal-title "Decentralize this SNS" \
# --summary "Decentralize this SNS"
#
$ ./open_sns_swap.sh
# The sale proposal was successful and adopted. I was then able view the proposal and the sale in the nns-dapp. See the photo at the end of this forum post. Note it took 5 minutes for the aggregator canister to detect the new SNS state
$ ./participate_sns_swap.sh 260 5000
Thanks this does seem to work, only issue I’m having is registering the canister with the SNS which isn’t an issue for now.
Could you maybe also verify the following scenario;
The person with a 50%+ majority from the team isn’t to technical when it comes to the SNS / CLI, so to make it easy we drop the neurons he is getting to his NNS principal. Which (I assume) makes it impossible to create proposals and vote on them because the neurons don’t show up in the NNS yet and can’t be coupled to a DFX identity as a hotkey.
Because of this reason I came up with the following scenario which I try to verify if this is doable.
We want to get a majority vote on the “register canister with the sns” proposal. Because if we have majority the proposal is accepted right away and doesn’t need to last 4 days.
The thing I’m trying to figure out is it;
I know that the developer neurons are dropped before the sale (when I deploy the SNS). This means they hold all the voting power.
I don’t know how that works for the airdrop neurons, I assume they are dropped AFTER the sns sale is over.
So in a scenario where we have a 1 SNS token developer neuron, and do the rest of the team neurons as an airdrop, it would mean that we have a majority to push propopals before the sale.
Hi @RMCS, I’ve outlined how the airdrops work and their drawbacks in my original reply. The Airdrop neurons are created before the sale, along with all developer neurons.
