Service Nervous System | Governance for Dapps

Hello everyone. We want to express the hope that for-profit and non-profit will work with different specifications and that both will work.

  1. Public dapps will be run by token governance.
  2. Corporate or individual dapps can be run centrally. Or only limited number of people can purchase governance tokens. We want to be flexible.
  3. AI censors the data. Operated by a foundation or a community.

The Twitter thread is below. It is in Japanese.


So I’ve been building a simple SNS that doesn’t require changes to the IC protocols, just as an experiment and hopefully it will be useful to projects wanting something like the SNS before it comes out. Nothing crazy, WIP, but here’s the code: GitHub - lastmjs/simple-sns

As I’ve been building this, an interesting nuance has surfaced. It would be nice for the SNS to allow any token (including NFTs) to be specified as the governance token. Why should every dapp have to issue a new token entirely?

What if I want ICP holders to be able to govern my dapp? Or HZLD holders? Or Cronics hodlers? What If I want to start out with Cronics holders, and then allow the community to vote and switch to another NFT to govern from there on?

It would be nice to allow the SNS to choose an already-existing token as the governance token, in addition to minting a new token (as an option).


Hey thanks @dralves appreciate the feedback :pray:


Reading through the design proposals I’m glad that @lastmjs addresses the elephant in the room. A complicated and opinionated feature is implemented what instead should be something allowed for the free market of dapp developers to figure out. Imagine such a proposal as an Ethereum EIP. Unthinkable! In fact it is somewhat alarming that permissionless innovation seems not a core value of the dfinity team.

Make it a library not a core feature at least.

  1. I believe the supply will be inflationary because of the staking of such token. However, change is possible but don’t know the pros and cons of extending that from the original design of the NNS.

Should the NNS have complete power over every SNS?

I think the NNS should have more power over time. I don’t think the distribution of power is where it needs to be right now.

It assumes the community of the SNS is a small percentage of the NNS. The NNS will have verified neurons so it will be more distributed and tied to real people. Whereby, the SNS might be a restricted community for example alt right Trump supporters. Should the NNS have power to take them down. What if the SNS votes to keep the content. Should the global community of NNS take them down?

Going rogue. Depends on how the minting of tokens is done. But I am guessing it is possible. The NNS might keep track of the tokens though to stop clone tokens.

Going with the standard template for token distribution presented in the video, can we have a set amount of tokens from action reserved for verified neurons. Also setting a max amount limit for purchase, during each phase. There can be many different types of phases that can be chosen.

The other question people have mentioned is if the initial projects owners can choose to do it their own way? And if so, that project would be open to more scrutiny. However, should that be a right?

1 Like

Hi everyone,

As Diego mentioned above, we have been quiet in the forum the last few days working on internalizing the feedback and listening.

So I want to give you all a quick end of week update.

The main update is that we heard folks feedback on configurable parameters. We have therefore been actively discussing which parameters should be configurable in the SNS at what stages of the project (during initialization vs. later) and to what extent. We will have an update soon which we think most folks would like.

Regarding other pieces of feedback, we also plan to provide an update this coming week.


Private Foundations could solve this, especially anonymity and privacy.

Thanks for the update.

I’m wondering if you could also shed some light into the token standard(s) SNS will eventually support. That would make it much easier for developers to plan.


Hi, Lara and the team
Please do help us confirm whether SNS will help the community unify a fungible token standard.
After the canisters can store ICP, whether can they also store tokens SNS issued?
Thank you very much.

Hi Lara ~ thanks for the update and all yours (and the Dfinity team’s) hard work in building the NNS and formulating a plan for the SNS. In this regard, I recently watched the Wanxiang Roundtable with Dom, Vitalik and Juan where they discussed various topics. From what I gather from Dom’s comments, it appears that the tokenisation of dApps via auctions will play a big role in the SNS and as such, I am wondering if this will be a permanent feature of the SNS for all dApps and/or if this is one of the configurable parameters that the Dfinity team is currently discussing. Thanks.


Could you share this roundtable that you speak of? I seem to have missed it

Hi all,

New week, new update!

We had some time to process your messages and even had the pleasure to talk to some of you to go deeper into the feedback.

Thank you all very much for taking the time to formulate your concerns and provide us with feedback!

Main takeaway

The main feedback seems to be that the current design is overly-complex and restrictive, as some developers might not, for example, want an auction to initialize their SNS. Moreover, for many, the highest priority seems to be a governance system.

While we still think that the originally proposed design is one possible way to provide an SNS “out of the box” from the NNS, we acknowledge that developers want more flexibility and might only want to use some of the SNS components (i.e., not the “full box”).

Therefore, the current thinking is to revise the SNS design & implementation and to aim at starting with a more minimal SNS consisting of a governance and ledger canister.

Other features, such as the auction, will be rolled out at a later stage and in a very modular way. This would allow those developers that only want a governance and/or ledger canister to already use them.

Larger context

We also briefly want to mention that there is another NNS-related project that will allow neurons to become so-called “community fund neurons” and contribute their staked ICP tokens to a community fund that can then be invested. While the efforts related to this project are tracked separately, we will of course ensure that the designs are compatible such that investing in SNSs is possible.

What are the next steps?

First, we will go back to the drawing board. For example, we have to think about what a minimal governance system should include and we will reconsider whether it makes sense to refactor the NNS canisters and repurpose them for the SNS or whether implementing the SNS canisters from scratch would be more effective (classic software engineering practical decision: refactor or recreate)

What happens to the 1-pager serving as draft motion proposal above?

The idea is that, once we have sufficient clarity on what a new design could look like, we will share a new draft for a motion proposal that replaces the one above.

We look forward to hearing your thoughts and wish you all a happy weekend!


PS a small personal note: @lara will be out the next week or so @dralves , @jwiegley , and I be covering for her on the community forums. Please be patient as three dudes try to cover one half of Lara.


Thanks for the update. Very exciting stuff.

I’m a little hesitant about the SNS ledger canister copying the NNS ledger canister, because I don’t fully understand the decisions made about the NNS ledger canister interface.

For example, why is notify separated out from send?

In ERC-677, for example, a single transferAndCall function updates the balances and notifies the recipient in a single atomic transaction. The ICP ledger canister split this into two functions, which means that the responsibility of combining both into a single atomic transaction lies with the caller. I’m not sure it’s safe to trust DeFi canister developers to correctly implement transactional semantics; if it’s possible to encapsulate this into a single sendAndCall or transferAndCall update, that would be safer as well as easier to use IMO.

And in terms of governance, it took me a couple of days to really grasp neurons, dissolve delay, age, etc. If we really intend for SNS-owned dapps to go mainstream one day, I think the IC’s governance model is way too complicated for the average user to understand (or to bother understanding).

I would rather we take our time with SNS to get it right. There are a couple DEX projects building their own token standard. Working together with them on a really good token standard would pay big dividends. Personally, I doubt any IC project really needs SNS at this very moment; what they probably do need (or at least I do) is a working token standard with working rudimentary DeFi plumbing. SNS would be a natural next step after that.


“Personally, I doubt any IC project really needs SNS at this very moment”

That is what I was thinking till I read this article by Dominic ( Why Totally Decentralizing Dapps Wins, and How to Do It | by Dominic Williams | The Internet Computer Review | Oct, 2021 | Medium). I spent a few hours digesting all the things in the article.

One excerpt “Very possibly, by January 2022, when the SNS functionality goes live, the funds the NNS has available to contribute will exceed 1 billion dollars in value. Watch for news: the NNS is due to start collecting funds imminently.”

If the features of the SNS as his vision in the article are coming through by January, 2022 including community funded neurons, then i would think that most projects would completely wait for the SNS.

Not sure how this vision , which is SO exciting, will match up against the reality of the time pressures. But regardless let’s move on with SNS.


I really like the idea of making ICP tokens locked in NNS neurons liquid for the purpose of buying project tokens that are (mostly) locked in SNS neurons instead. Brilliant!

But what I don’t understand is: Why pool these into a fund and allocate them to specific projects using majority-rules liquid democracy? Why not just let each owner decide which projects they want to invest in themselves?