Update:
Community Conversation on SNS this week.
4 Likes
@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!
6 Likes
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
5 Likes
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.
8 Likes
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.
6 Likes
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?
4 Likes
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?
10 Likes
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.
18 Likes
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.
2 Likes
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?
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.
3 Likes
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.
7 Likes
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.
3 Likes
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 :-))
4 Likes
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.
11 Likes
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).
4 Likes
Although Iâm looking forward to seeing the exploration of many novel governance schemes on the IC, I see a lot of value in starting with a specific âtokenization and decentralization in a boxâ solution.
It would also be very helpful if the Dfinity Foundation provided a âWyoming DAO LLC in a boxâ starter pack, and even offered the services of a registered agent in Wyoming. This would make it much easier to protect SNS-governed dApps from being deemed unlimited-liability general partnerships, so founders donât have to figure out all the legal stuff themselves.
5 Likes