Service Nervous System | Governance for Dapps


Community Conversation on SNS this week.


@lara i think folks had some questions on the thread that may be worth addressing in the community conversation.

Other folks:

If you haven’t yet, please add some questions which @lara can prepare for. That would make her life a little easier. Thanks!!

1 Like

Thanks @diegop.
Although I haven’t had time to respond, I have looked at all the above comments when preparing the slides and hope that my talk will cover and clarify some of the concerns!

Also looking forward to all the questions that people will ask tomorrow and hope to see many of you there for an interesting discussion!


It looks like you’re going to be able to create fungible tokens that can be distributed to manage the DAO – my question is will these tokens follow a certain standard? If so, what will the standard be?

1 Like

Here is the video of today’s community conversation.

Well done @lara !


Great talk.

I’m hoping we can engage on some of the ideas @lara presented today, and hopefully soon reach a stage where we can all vote on a NNS proposal with a fleshed out SNS design (like with other proposals over the last few weeks). The initial design doesn’t have to be perfect, and I expect there to be many modifications to it over time as we learn more about different dapps’ use cases.

Points that stood out from today:

  • One SNS per dapp
  • All SNSs will be managed by the NNS, with new SNSs created via NNS proposal
  • SNS includes governance and ledger canisters
  • Initial token supply will be 10% liquid and 90% locked in neurons (and will be configurable)
  • Initial token distribution is as follows: 25% to developer, 35% to a SNS treasury, and the remaining auctioned off on-chain (the auction will be implemented with the SNS as a turnkey solution; distribution is configurable)
  • Auction bidders pay in cycles for SNS tokens (could be ICP as well)
  • Token supply can be inflationary
  • Multi-canister dapps will be supported
  • Initial implementation will reuse NNS code; one benefit is that SNS ledger canisters will get Rosetta API compliance for free
  • Alternatives to liquid democracy may be possible? (governance should be configurable)

Personally, I’m really excited about this, and hope it can be prioritized in the coming months. It’s something that separates the IC from the rest of the blockchain pack—by a long shot.


Awesome progress!

My main concern is governance configurability. I’m designing new governance structures for IC projects because the current system has a tendency to create centralized voting power over time.

Even the NNS itself should eventually adopt a different governance structure if it truly wants to become decentralized. ATM the rich get richer and gain more voting power over time.

I propose to implement a combination of quadratic voting and reputation-based voting. This will ensure good economic incentives and permissionless participation (relative to registered voting), but it will become very difficult to gain centralized power.


The design sounds pretty good for default option, of course over time other solutions will pop up.

I understand that the design is in planning phase, but wondering why NNS proposals need to be involved to create SNS? That would result a lot of proposals and honestly I don’t really want to vote for every dapp… do it my friend, you and your community will pay the SNS cost, why would I reject your request?


Yes, why is creating an SNS for a canister or set of canisters permissioned by the NNS? Creating a canister and setting the controller is already permissionless, why would effectively setting the controller to a group of token holders be permissioned?


TLDR the current design is too complicated and specific

After watching most of the video, I would like to echo my previous concerns.

The proposed design seems far too specific, enforcing a particular governance scheme on all dapps. What if I don’t want staking of my governance tokens? What if I don’t want to distribute the initial supply with an on-chain auction? What if I don’t want to govern my dapp just like the NNS?

I think a more generalized (and simpler) design should be discussed. We should agree on the absolute minimum set of features that all community-governed dapps would want. Over time extra optional features can be added.

For example, I would think the most basic design would at least have the following characteristics:

  • A token distributable to many different principals
  • A controller that can be set somehow to all token holders instead of a single principal
  • A voting mechanism that allows the code and state of the canister(s) to be updated based on some threshold of positive votes

Does it need to be much more complex than this to start? We just need a basic multi-signature scheme for the controller of canisters. All other features it may be possible to build on top of this very simple base.


This is a good place to start. It will also allow the more complex elements to find use cases in the community, as we are seeing in the responses here. Some folks are all in and some want a light weight start.

I like the overall plan and really think this can do well.


It is an innovative and forward-looking idea. I’m all for it.
I have a question, do we need NNS voting to issue tokens?

Good feedback.

@lara @johan @dralves


The SNS is meant to be a “tokenization and decentralization in a box” solution and thus needs to have very specific terms and inner workings. However it is ultimately up to the developer(s) to choose to have their app managed by the SNS.


I hope that this box has well-defined interfaces, so that maybe we can have a world where different SNS implementations can still be used uniformly by common clients, where applicable. For example many may have different voting and distribution rules, but still want to be ledger-compatible, so that wallets and exchanges will just work. Similarly, I expect that a lot of SNS can share the code and logic that acts on accepted proposals (upgrading canisters, managing cycles…) completely independent of how these proposals are managed. Good factorization of concerns will help the ecosystem here, and probably even makes the “offical” SNS simpler.


Hi Joachim. W.r.t. to the spec design intent here is for the SNS to share code and interfaces with the NNS, to this goal we want to:

  • Simplify the NNS’s interface, extract a spec of the main methods and how they work. (e.g. what are the types and the expectations/pre-conditions when calling methods on NNS’s ledger or the governance canister).
  • Refactor NNS specific stuff to it’s own APIs/types so that we can have a de-facto interface that we know works, from which we can extract the spec.

With regard to swappable implementations of the different components, the SNSs code, like the NNS is going to be open source so anyone is free to extract some or all of it to come up with their own solution.


Sound good! (Although “it’s open source so anyone can change it” is not quite “it’s modular by design and anyone replacing the voting logic module with a different module can continue to use the other parts unchanged”. But I’ll sit quite and see what has been built before I am too annoying :-))


On the topic of different governance systems, I just learned about Polkadot’s governance model and it’s pretty interesting (and something individual dapps may want to implement).

They divide power among three different groups:

  • Council
  • Technical committee
  • Community

They emulate a representative democracy with referenda, as opposed to IC’s model of a direct democracy. One thing I like is their explicit inclusion of a technical committee (whose members are voted on by the council, whose members are in turn voted on by the community). It’s made up of developers most knowledgeable about the source code, which means they have the power to fast-track proposals like bug fixes and uncontroversial features.

Anyways, it’s somewhat tangential to this topic, but I wanted to bring it up due to its surprising sophistication.


Well defined interfaces and structures would be good. One thing I am reminded of here is Polkadot’s substrate framework: Build | Polkadot. Developers are given well-defined tools to build blockchains that interface with the Polkadot chain (parachains in their jargon). Similarly - we would want the SNS to instead of being a single out-of-the-box governance-token-contract, to be a framework or set of tooling to produce the necessary infrastructure to support a wide variety of governance and tokenization models. (Although - the first step to generality is specificity, so if we want the first draft to merely replicate the mechanics of the NNS that’s fine too).


I think it is tangential this topic but perhaps relevant to the discussions on blessing binaries and how to create human processes for the review snd contribution of the code. The foundation has project to make the technical side of contributions and visibility easier (99% of the reason that code is visible after NnS proposals pass is purely for technical reasons which are being addressed)… but that does not mean the human side (The notion of committees is a good reasonable one).

So I’m definitely watching and learning (specially last few months as I work on public roadmap).