This is true. People understand that when they invest in a project, they are taking a risk and must do their own research. Having SNS will in fact help them access projects whose trust is highly enhanced.
2 Likes
As far as I know this is currently not planned. However the discussion on the community fund and the UX is currently still ongoing and I will run this thought by the UX team.
It will be the existing maturity.
Yes correct, this is a current limitation which we suggest to accept for the first iteration of the SNS. See also this thread touching on this topic.
1 Like
That is hardly necessary. 
The SNS is shipping with two modes. -application and NNS integrated. I think the first mode is much safer initially and also faster to get shipped.
1 Like
Thank You, Kind Ser
ā¦
Have the Dfinity team(s) working on this considered the who in the IC community will be able to participate in token swaps if existing maturity is all that can be contributed? It will be interesting to see how much maturity is going to be available. For me, I have a significant neuron dedicated to the Community Fund, but until recently I have compounded maturity on a regular basis so it will grow. Hence, I donāt have nearly as much maturity available as I would be willing to commit to token swaps. The people who have not been compounding might have accumulated an appreciable amount of maturity, but the majority of ICP available for token swaps will be large wallets that donāt take long to reach the maturity level that enables them to max the allowed contribution. The barrier to participation might be pretty tough for a lot of people that this SNS token swap concept wants to attract. It might be good to start communicating that we should not be merging maturity if we want to have maturity available for SNS token swaps when they become available.
3 Likes
It is my understanding (& @bjoernek or anyone else can correct me if i am wrong) , that the folks who have NOT compounded maturity, have NOT compounded maturity for a long time. These typically appear as whalish hoddlers to me.
It seems that token swap is targeted exactly for those folks. Which, if i think about it, may not be a bad thing. Instead of upward pressure to mint new ICP, it goes to the SNS token swap.
Is there a downside to minting ICP through merge maturity into an 8 year neuron? Why is token swap preferable? In the former the ICP is subject to a time locked dissolve delay and in the latter the ICP is liquid. Hence, if you are worried about inflation of circulating supply of ICP, then the token swap seems less preferable.
I wouldnāt want to dissuade the token swap feature based on that augment though. I think itās more favorable to move forward with SNS funding mechanisms such as the token swap.
It is planned that there will be two ways to participate in a token swap: Either by (1) directly contributing ICP to the token swap or (2) indirectly via the community fund, in which case the maturity of the CF neurons will be used.
For the community members pursuing option (2) it would indeed make sense to give them a heads-up so that they do not merge further maturity. I will include this in the next update on the community fund.
2 Likes
Putting this here because I donāt want another top level thread and thought it would be a good place to keep the discussion going:
It came up on the neurotic podcast(@icpjesse @Kyle_Langham) that ICDevs was against having a token for any app that hadnāt been in existence for two years and I thought it was worth clarifying that position in a couple of ways.
-
At this point, the dev board hasnāt decided anything and the dev board is ultimately who will decide and each vote will likely be decided independently.
-
The position that I have (@afat) and the recommendation Iām currently likely to make is more nuanced than presented on the podcast.
2A. I am very much in favor of projects tokenizing and raising funds as soon as they need them and feel they can make a case to investors.
2B. I am very much in favor of DFINITY releasing the amazing work theyāve done on SNS token, governance, swap, and lifeline/upgrade canisters and I hope they will release Motoko reference implementations as well.(And I think they are best positioned to build solid secure canisters so I hope they keep up doing soā¦the commune should step up and build better/diverse uis to these canisters)
2C. Iām in favor of as many projects as want to implement these on application subnets and begin a grand experiment with on-chain governance as soon as possible.
2D. Iād recommend approving applications to move to the SNS subnet with āofficialā integration at the NNS level after that application has been actively governing >$100M worth of tokens for >2 years. We just have too much to learn about how this is all going to work for the NNS to get married to these ecosystems without dating for a while. A good case can be made for different numbers for different kinds of projects, but the guiding principle is to make sure the post-issuance governance is functional and properly decentralized.*
2E. If the SNS/NNS integration does go forward Iād recommend running any UI in an alternate url than NNS.ic0.app to avoid blocking NNS users from accessing their current investments in the case that the SNS domain is blocked by regulators. (Discussed at Proposal: Host the SNS at an alternative domain to avoid existential risk to existing NNS stakes)
This course of action would be more conservative, but would also give us a reason to lean on veering subnet migrations in place which is a key future security feature anyway. Instead of approving the issuance of tokens, the NNS would be voting to migrate known projects with already issued tokens to the SNS subnet. The is a light regulatory risk that SNS token approves could be held accountable for activating a non-compliant securities issuance. If the token exists already we are just voting to change some routing tables.
My biggest concerns are:
I would hate to end up in a position where ICDevs has to abstain or must reject due to regulatory reasons.
I donāt want blowback for inevitable Luna style blow up being easily tied to $ICP and depressing the price more than necessary.
āMore than necessaryā is probably a key phrase here. What I like some clear(er) communication on is why NNS gateting and integration is ānecessaryā at this time. It may be a great idea and I think weāll have NNS integration in the future for mature projects, but Iād like a better understanding of why it is necessary at this time.
*I have skin in the game on this with my position at ORIGYN. The concern of a screw-up at Origyn being tied by the press to my/the boardās other significant investments in ICP is too great to launch on the NNS/SNS integration until we have a good understanding of how our governance of OGY will burn in. Separating āinfant and toddlerā tokens from the NNS makes an anti-ICP narrative harder to craft.(admitted they will try anyway).
3 Likes
I completely disagree with @skilesare and his concerns, if we want Internet Computer to truly thrive and become a leading technology in the blockchain space we need to give complete freedom to projects wanting to build on IC and not create more roadblocks. Just look at Ethereum and how even with all the scams on its chain it continues to grow stronger exactly because of the fact that it allows such freedom on the development side. As such, Iām against making every project wanting to use SNS to go through NNS approval as this will undoubtedly make the process even more political than it already is.
Having said that, I think a good alternative is for IC community to work towards creating a Trust Rating that will guide investors and limit risks as much as possible without such roadblocks for developers whoās only faults might be not having any fame or the sort of reputation groups like ICDevs are demanding. Such a feature should be reasonably easy to implement directly in the NNS to complement the SNS frontend.
4 Likes
Ideas that are too ideal will lead to a dead end, I think the opinion from @vavram maybe better.
Heyā¦I may have miscommunicated a bit, if so Iām sorry. I 100% agree with you and I think that if you reread my comment youāll be able to see that and/or point out where I miscommunicated. This is complex stuff.
Iām 100% in favor of something like this as well, although I think the market gives us one with price. If the token launches in application mode and thrives over a couple of year period, its trust score is its price. Alsoā¦againā¦Iām against any roadblocks for tokens launching their SNS-based tokens on the application subnets(And to be fair I donāt think DFINITY is against this either). Iām against approving anything at the NNS level at this pointā¦it seems unnecessary. Anyone can launch on the application subnet without restriction and no one needs to approve it.
Hey Austin,
Really happy to hear you listened to the podcast 
Weāll correct the record on the next podcast. I may just read from your post so that I donāt put words in your mouth. Sorry for the miscommunication and any issues it may cause.
No worries! Iād rather have conversation than have it be perfect.
Connecting the SNS frontend to the NNS dapp is necessary though, as project discovery is unfortunately sorely lacking on the Internet Computer as a whole and most new users onboarded will likely start their IC journey with the NNS. So while I fully disagree on needing the NNSā input on what projects to be allowed or not, listing projects leveraging the SNS directly on the NNS is a great idea actually as long as the community-driven Trust Rating is implemented along with it to complement it.
We could make it optional to go through NNS and leave it to the developers, but give projects that have gone through NNS a visible stamp that of approval from NNS, and only this should take part in the community fund. Those with this stamp will also be more appealing to investors.
Thank you all for contributing to this discussion!
As it has been mentioned that it seems unnecessary that the NNS is involved in the SNS launch, let me try to motivate this a bit better.
One challenge in adopting an SNS (or any DAO) for a dapp is to transition from a centralised state, where single parties are responsible for the dapp content, to a decentralised world, where the dapp is governed by a DAO that is controlled by many and where there are tokens that are owned by many. One way to achieve this transition is to make use of an already decentralised system. Since the NNS is an already decentralised system, the proposed design suggests to use it: a developer can hand over the control of the dapp to a newly deployed SNS and ask the Internet Computer (i.e., the NNS community) to generate tokens and start a decentralisation sale for these new tokens to bootstrap a decentralised governance for the dapp. At the end of a successful decentralisation sale, SNS tokens are owned by a large community and therefore the SNS governance is decentralised.
Having a decentralised system ārun the saleā ensures that at no time during tokenization and DAO bootstrapping, only a few individual parties are in control and could for example cheat the sale participants or manipulate token distribution in any way.
Note that the sale is the only process that currently is triggered by an NNS proposal, precisely for the reason explained above. We do not claim that this is the only way to decentralise a dapp. As we have to start with something, this is what will be supported in the MVP, but other possibly better options can be added in later iterations.
The question which SNSs are shown on the NNS frontend dapp is a different discussion. Again, what we suggest is just the initial version. If later new ways to launch an SNSs are added, a decision under which conditions SNSs shall be listed on the NNS frontend dapp needs to be taken.
5 Likes
is it possible to get an integrated Reward Calculator. And just give it a nice & simple UI. That easily show you what you can expect by locking for XX years etc.
i know about the Reward Calculator which is already out there, but it isnāt really user-friendly etc
Agreed. We currently have the reward calculator on the internet computer dashboard but it would be nice to implement it into the NNS / SNS frontends.
2 Likes