How to deadlock an SNS and a possible solution to discuss

Developers
, ,
1

So after i’ve read through all documentation on how to configure an SNS and deploy it locally, with testflight and eventually mainnet i thought i figured it all out. But when going for the real deal i still ran into some issues.

The main challenges i faced

  • The team members with a majority vote that have neurons specified in the developer section on the yaml file want their neurons dropped to their NNS principal
  • Between the SNS mainnet deployment and the swap (decentralized sale) you need to register your canisters, ideally with a majority so you don’t have to wait before its accepted

When you are done with setting up the yaml file, you can deploy your SNS to mainnet with a CLI tool, which also distributes the initial neurons specified in the yaml and puts the SNS in a “centralized state” where only the specified neurons have voting power.

After this step, you need to add the deployed SNS root canister as a controller to the canisters you want SNS controlled and create a proposal to register them with the SNS which can be done with a CLI tool called quill

After an initial discussion with the Dfinity team on how to proceed with these proposals with an ideally majority vote so we didn’t have to wait there were 2 options;

  • Add a local identity as a controller to the the majority neuron
  • Put out a proposal with a non-majority neuron and wait for the time specified in initial_voting_period_seconds to pass (minimum 1 day)

Regarding the first point, i wanted to know if it was possible to handover / add a controller to a neuron that has a dissolve delay and vesting period, so that after the initial voting i could assign it to a NNS identity. According to Dfinity this was possible.

After an internal team discussion we decided to go with the second option and put out the proposal and let it run for a day to be accepted. (so we thought)

So after making some minor changes to the yaml file and making my personal neuron(s) controlled by a local identity (to use with quill) and the rest of the developer neurons controlled by their specified NNS principals, i put out the proposal to register the canisters with the SNS.

only to find out that…
For a proposal to pass you need at least 3% of the votes of all available voting power, and i owned ~1.4%. And because the other developer neurons are not accessible by the team members our SNS is deadlocked.

To fix our deadlocked SNS we are proposing to make a change to the NNS dapp where we could access the NNS principal controlled neurons and proposals so we are able to cast a vote to at least get over the 3% of needed votes to continue the SNS process.
For example through an url change like this;

  • https://nns.ic0.app/neurons/?u=<sns-root-canister-id>
  • https://nns.ic0.app/proposal/?u=<sns-root-canister-id>
4 Likes
2

Thanks for sharing your experience here @rem.codes, I think this will be beneficial for upcoming SNS projects as well as for the whole community to learn!

Regarding possible solutions, I would like to point out that the 1proposal SNS initialization will soon be ready to be launched. After this, there is no need for an SNS proposal during the launch as the full launch process will be automatically triggered by one single NNS proposal. We actually plan to share an update on this feature and its release tomorrow!
I think this is worth taking into account when deciding how much effort should be spent on a solution and whether we should rather just make sure that the few SNSs that still go take the old path do not run into the same issue.

That being said, I agree of course that we should find a solution for the SNS in question!
It seems that the second solution that you propose would not solve the problem in you case as the SNS canisters are already initialized. Would you agree?

I think looking into what could be done with the NNS frontend dapp is the most promising solution. I plan to meet tomorrow with the team that is working on the frontend and discuss possible solution with them.
I will get back to you here once I know more!

1 Like
3

Yes you are right, I was thinking about other solution the prevent this from happening in the first place but i didn’t look at the “1 proposal SNS initialization” in-depth so im probably missing some context.

I will edit the initial post to make it more specific to the problem we are facing

4

@rem.codes Much appreciated for sharing this issue. We hope to avoid it when we launch.

@lara Do you mean the 1 proposal solution will be available tomorrow or just an update on the proposal?

5

@lara Do you mean the 1 proposal solution will be available tomorrow or just an update on the proposal?

We will share an update on the forum and a demo in the public Global R&D.
We plan to submit the proposals for fully releasing the feature in the coming weeks.

1 Like
6

Can you expand upon why the rest of the team couldn’t access their neurons? is it because they were created with the nns dapp principal?

7

Yes, their neurons are all NNS controlled, so currently not accessible to use for voting / adding hotkeys.

2 Likes
8

Hi @rem.codes,

We made a branch of the NNS dapp frontend which we believe will allow you to access your neurons.

Instructions are in the PR description.
I hope this helps.
David

4 Likes