A short update on the SNS for Sonic

[bjoernek]

TL;DR

Creating an SNS currently entails two proposals. The first proposal for Sonic was accepted, allowing Sonic to create and initialize their SNS canisters. The proposal to start the SNS swap for Sonic was rejected, leaving the Sonic SNS in a restricted mode where it does not govern anything and where token transactions are not possible. The control of Sonic dapp canisters has been returned to the developers.

In this post we would like to emphasize that the SNS framework has worked as intended and explain the current state of the Sonic SNS.

Background & goal

The creation of a Service Nervous System (SNS) DAO is done in two phases. In the first phase, a proposal of type “Update Allowed Principals” is submitted, which approves the initiation of an SNS launch for a dapp and allows a specified principal to install and initialize the required SNS canisters . In the second phase, an SNS swap proposal is submitted. If this proposal is adopted, it triggers the start of the SNS swap. If this proposal is rejected, the SNS launch fails and the control of the dapp is given back to the developers. The developer principal to which the control will be handed back is defined in the SNS initialization.

In the case of the Sonic dapp, the first proposal was adopted. However, the second proposal, which was aimed at initiating the SNS swap, was rejected. This has led to several Sonic users and members of the community questioning what this means for the SNS. The objective of this forum post is to clarify the current situation and outline the implications.

The following diagram depicts the second part of the SNS launch flow after the first proposal has been adopted:

Current state of the Sonic SNS

Control of Sonic dapp canisters was handed back to the Sonic team

After the SNS swap proposal was rejected, the control of Sonic dapp canisters was automatically returned to the fallback controller, as specified in the SNS initialization. This can be verified on the dashboard: the control of, e.g., the Sonic swap FE asset canister (eukbz-7iaaa-aaaah-ac5tq-cai) was handed back to the designated fallback controller (vfk4j). As a result, the Sonic dapp is not under the control of the Sonic SNS.

The Sonic SNS governance is in a restricted mode

The usability of SNS governance is limited until the SNS is successfully launched. This restriction ensures that no fundamental changes to the SNS DAO can be made until it is fully decentralized. For instance, it is not possible to transfer tokens or to alter the tokenomics configuration of the SNS in this restricted mode.

In Sonic’s case, because the SNS swap proposal was rejected, its SNS governance continues to be in restricted mode. You can confirm this by calling the “get_mode” method of the SNS governance canister on the dashboard.

SNS tokens & neurons have been created but are not usable

During the SNS initialization process, SOC tokens and neurons have been created. You can see the linked minting transactions on the SNS ledger on the dashboard.

SOC tokens only exist in neurons and in the SNS treasury. However, since Sonic’s SNS is in restricted mode, neurons cannot be disbursed and the tokens in the treasury cannot be transferred. Therefore, no SOC token transfers are possible.

Because the SNS is in restricted mode, Sonic’s SNS neurons are not visible in the NNS frontend dapp, as this application only displays tokens and neurons once an SNS is successfully launched.

The Foundation abstained in all votes regarding the Sonic SNS

The foundation wants all projects and the ecosystem to succeed. In the case of Sonic, the foundation abstained from voting, because the information provided by the team was not sufficient and because of concerns raised by other community members. Indeed, the SNS creation has failed solely based on votes by the rest of the community. The foundation hopes that Sonic addresses these concerns, provides additional information, and makes a second attempt at creating an SNS.

Conclusion

In conclusion, the SNS framework functioned as designed. The NNS community did not approve the initiation of the SNS swap for Sonic. Consequently, control of the dapp was returned to the developer team. As the SNS has not been successfully launched, it remains in restricted mode cannot be used further. In particular, the created tokens and neurons cannot be used or repurposed. If the Sonic team would like to attempt a second launch, they would need to initiate the SNS creation process from scratch, i.e., submitting a first proposal, installing and initializing new SNS canisters, and then submitting the second proposal.

[ZackDS]

@bjoernek

the SNS creation process from scratch, i.e., submitting a first proposal, installing and initializing new SNS canisters, and then submitting the second proposal.

This is good to know that in case of failure one needs both proposals to pass again.

[jwarner]

Hi @bjoernek, thanks for clarifying. I know for me personally, I understood what it meant for the SNS (it failed to be adopted), but the dashboard UI made things confusing. Currently, it shows what appears to be sonic controlled canisters running.

It shows that SOC tokens were minted and distributed.

It shows all of the proposals except one were exectuted.

It shows neurons with staked SOC as well.

From looking at this page only, it actually looks like everything went through, even though it didn’t. So, in my opinion (from a small retail investor perspective), this information shouldn’t be displayed because none of it matters or is valid any more? All of the canister creation and token distribution is moot because the adoption failed.

Since both proposals will have to be voted on again, and all of this will have to be re-done, what is the purpose of displaying it at all? It seems to me, it just confused a lot of people. It didn’t help that some people were also tweeting it was successful with similar screenshots to what I attached.

Hopefully the process will continue to be refined so everyone can better understand how the process works. Thanks again for clarifying!

[FOX]

I’m proud to have prevented CF from RUG Pulling with great community decision making!

[Junkfarm]

Interesting that community members swayed Dfinity. Those community members are paid to FUD projects and Dfinity listened to them. There are only a few honest teams left in this ecosystem and you just shoved one of them out the door. I have little faith Dfinity will ever do anything meaningful with this approach

[Junkfarm]

Of course. Meme Cake bought it and has done tons of work to upgrade the Dex. All of this has been documented in the Sonic discord.

[FOX]

I think it is appropriate to develop Sonic in Luna (Terra) instead of ICP

[runner836]

I respectfully disagree with your assumption that the MemeCake and Sonic team are frauds. They are a very respected team that I would follow anywhere. I’m very happy to get to know them and I appreciate their hard work day in and day out. Even when most have bailed on the ecosystem they continued to build innovative products.

[diegop]

@Newtolearn as a moderator, i wanted to let you know I removed your post because it crossed into clear ad hominem.

I ask you please refrain in the future, please.

[diegop]

@FOX

I’m proud to have prevented CF from RUG Pulling with great community decision making!

Few folks flagged your comment. Tbh, I’m not entirely certain what it means so I am going to ask you please take a bit more stock for the future in what you write.

[josephgranata]

That is a very disrespectful comparison, Luna was a gigantic fraud and a rug pull.

DFINITY is a serious blockchain, why do you compare it with Luna?

Do an honest constructive criticism instead.

For those unaware of this “joke” this was Terra:

Terra (blockchain)

[bjoernek]

Many thanks for your feedback @jwarner. You raise valid points.

Let me review with the dashboard team, how the presentation can be improved.
cc: @Dylan

[diegop]

Thank you, I appreciate a lot you willing to iterate for the sake of this community. Thanks a bunch.

[Antony]

From my experience they have one of the best UI and experience. I noted that some people mentioned this before.

[Antony]

Thanks @bjoernek for the clarification. But I have some doubts regarding $SOC

1. What’s the future of $SOC token in the SNS Neuron
2. It seems that some token already distributed, what is the future of that tokens?

I want to add one more thing: From my little experience with this community Dfinity ecosystem is small to FUDD by a few people /fake accounts. We can easily kill a project by some people, here is the proof (my personal opinion)

[bjoernek]

@Antony

• What’s the future of $SOC token in the SNS Neuron

The currently issued tokens cannot be used. They are not transferable and the governance set-up is in restricted mode.
Please note: In case thats the Sonic team initiates a second launch using new canisters, they could still use the same token name.

• It seems that some token already distributed, what is the future of that tokens?

For the time being the according canisters are not deleted and thus the ledger with the tokens & governance (which is in a restricted and thus non-functional mode) still exists. We should review whether/when we would like to have some kind of clean-up mechanism which deletes non-functional canisters after some point in time.

[caolw]

I think the model has to change and it’s really affecting the schedule of the project side

1. Any project can release tokens on SNS
2. If you need to use SNS, you can publish your proposal.
3. When the project needs the amount of community fund, you can publish the proposal
4. When the project party needs to use the neuronal governance of SNS, it can publish the proposal.
   We should break up the current SNS to give early project parties a chance.

[skilesare]

@bjoernek

The currently issued tokens cannot be used. They are not transferable and the governance set-up is in restricted mode.

I’ll suggest again that a much better path to the NNS would be requiring teams to deploy these on application subnets and control them before being approved by the SNS. That way the token is operational and teams can set them up as desired. Once they want to do a decentralization sale, the NNS can check that they are using vetted wasms and have submitted control to the SNS system.

This would also give the teams some chance to demonstrate how they run a dao and what the community can expect of them.

If the sale fails then control can return to the team.

How can we build vetted tokenomics worthy of community fund investment if your token isn’t generated until the sale where people are supposed to invest in demonstrated value?

Perhaps I’m missing something in how it works…perhaps you can already bring your own token…but it seems that generating a token for swap is part of the current process.

[bjoernek]

@skilesare

Perhaps I’m missing something in how it works…perhaps you can already bring your own token…but it seems that generating a token for swap is part of the current process.

Many thanks for your feedback, @skilesare! I completely agree that the Internet Computer should provide various methods for launching a DAO. That is why I was thrilled when CigDao was introduced as an alternative community driven DAO framework at the last Global R&D event.

Your suggested path, that is, to first launch and then raise funds, is definitely a viable option.

The design intent behind combining the launch and token swap within the SNS framework was to ensure decentralization of the DAO from the start where the launch decision is triggered by another DAO, the NNS. From my perspective, this is an equally valid approach.

I hope we can see different DAO frameworks coexisting on the IC, each one tailored to a specific use case.

[skilesare]

For sure…and I know SNS is meant to evolve. Having the conversation for a cig or axon to SNS jump may be worth having so the tech is ready when that situation occurs.