Dear SNS teams and community members:
DFINITY is currently prioritizing some work in the context of the SNS framework.
To that end, it would be very useful for our planning if you could briefly summarize the biggest friction points that you currently have with your SNSs. Alternatively, if you had to choose one improvement, what would that be? Please be as specific as possible.
Your feedback is very much appreciated.
Hi, I’m a member of ICLighthouse team. The following represents my personal views only.
SNS is an important part of the IC ecosystem and a tool for eco-projects to achieve decentralisation. Based on the ICLighthouse DAO issuance process, I would like to express some opinions.
It is recommended to accept the shortcomings of early projects in decentralisation, such as token distribution, voting weight, etc… However, the team needs to provide the goal and path to achieve complete decentralisation.
The operation of SNS projects needs to conform to the norms of SNS. What current projects do is very insufficient, for example, some projects are still operated directly by the team in dapp upgrades or operations involving assets (this can be seen in SNS proposals). It is recommended that the Dfinity Foundation conduct regular general evaluations of SNS projects and provide reports and recommendations, which involves a lot of work, but I think it is worthwhile. Perhaps an automated checking tool could be provided.
The original intention of the community fund’s participation in early stage projects is to support eco-projects, but this faces a huge moral risk, as some projects are not aiming to development, but to cheat SNS community funds, which greatly harms the SNS system and the IC eco-system. I think, community fund should not invest in every project, or a two-stage model can be designed, e.g., an SNS project conducts two public swaps, the community fund does not participate in the first swap event, after 3 months the project starts the second swap event (the project’s valuation must be higher than the first swap), and the direct participants reach a certain percentage before the community fund participates.
The treasury funds should have more specific release rules, and some uses must be carried out in smart contracts (such as liquidity, buybacks, airdrop canisters, etc.), and in many scenarios the funds can’t be withdrawn directly to personal accounts. Encourage SNS projects to disclose their finances on a quarterly basis to achieve financial transparency.
Allow SNS projects to fail, and the Treasury should implement a mechanism to reserve xx % of the ICPs for buying back SNS tokens in the event of project closure, which is not allowed to be withdrawn.
Hey Arshavir, on our side the most important feature we would love to see would be the possibility of making multiple SNS-Swaps. I think this is probably not too far as we already have the initial swap, and I think there is an open method on the swap canisters that might allow us to open new swaps. We want to make sure the SNS we’re going to do in two weeks can be extended in the future.
2 stage neuron fund participation. Separate vote after successful launch.
Ability to launch on the platform before a decentralization swap so that projects don’t have to feel an all or nothing launch.
An SNS SNS so that launching them can be removed form the NNS itself as there are still regulatory “issues” for US(and other jurisdiction) participants. You could even fork the current NNS neurons for this with a one time option people to liquidate to SNSGov and liquidate if they don’t want/can’t vote to launch SNSs.
Launch pad for launching a non NNS governed SNS.
Ability to upgrade a non NNS SNS to an NNS SNS.
Hi @aterga, Marcio from ICX here. Thanks for creating this thread.
As per Burn, Dissolve, Transfer SNS Neurons - #6 by Mar, I would choose the ability to transfer SNS neurons from the NNS frontend and, if possible, to burn neurons by sending them to an address. That would allow us to implement some sort of rage quit feature, which would solve some issues with the treasury mentioned by @bitbruce.
I also agree that SNSs should be allowed to fail. One way to do this could be by distributing the treasury among the circulating supply. This could increase the number of SNSs created, and the previous point should increase the quality.
Additionally, I think the ability to do multiple swaps is needed, but perhaps that could be implemented by each DAO.
Hi @aterga , thanks for setting this up!
Ability to define neuron baskets for ICP treasury collected during SNS sale.
For example SNS sale can be configured to stake 70% of the collected ICPs into multiple neurons, which are dissolved at 3-month intervals for 4 years.
This can assure SNS investors that ICP treasury will not be drained out in one day with one proposal.
Thanks @aterga for proposing this improvement to SNS. I’m Yan, the founder of ICPanda DAO, and I’d like to offer a suggestion beyond technical aspects.
I believe that SNS project teams, users who bought SNS tokens, the Dfinity team, and many ICP holders all hope for SNS projects to succeed. After the successful launch of an SNS project, people might assume that the project will thrive through the efforts of the team and community governance. However, looking at the development of over 20 SNS projects, success is not easily achieved.
I think the reason for this may be that SNS project teams, often tech-focused startups, lack experience in other entrepreneurial areas. Their overall entrepreneurial ability may be weaker than Web2 startups, and relying on community governance to fill the gaps is even more challenging.
Take ICPanda DAO as an example. We were honored to be recognized by the community and passed the SNS. We were confident, thinking that focusing on product and technology would solve everything. Yet, we encountered two main difficulties:
Issues with the SNS framework and proposals: Even after repeatedly reading the SNS technical documentation, I still faced:
Challenges in marketing and promotion: Despite our efforts, we still felt disconnected from the ICP community:
The reason we feel disconnected from the ICP community is that during our promotional efforts, we would At the official ICP account or influential OGs in the ICP ecosystem, hoping for attention, feedback, or retweets, but received none. We remain relatively unnoticed. There are certainly areas where we fell short, but we don’t know where the issues lie or who to consult.
Relying solely on project and community autonomy is difficult for success. My suggestion:
I hope Dfinity can initiate an SNS support alliance to provide guidance, consulting, and resource support for SNS projects. This includes, but is not limited to, knowledge sharing, technical guidance, resource connection, promotional exposure, and market activities, helping SNS project teams solve problems, avoid pitfalls, and grow quickly.
We would like the SNS voting rewards algorithm to be changed to match the NNS algorithm which was updated > 1 year ago. For SNSes, the total daily voting reward is constant regardless of the amount of voting power excercised that day. So if few neurons vote on proposals on a given day, those neurons share the entire daily reward. Instead, the total reward available per day should be ((max daily reward * daily voting power) / total voting power). This means the reward each neuron receives is independent of how many neurons voted and so is predictable. And very importantly, it reduces SNS token inflation.
We would like a built in proposal for the governance canister to call an ICRC1 transfer endpoint on any canister by specifying canisterid and amount. This would easily allow the SNS treasury to hold any token which is then accessible by proposal. Some SNS projects have sent tokens to the OpenChat treasury but they are currently inaccessible. We could solve this by creating a custom proposal (+validation endpoint) for each ledger but it would be much better oif this came out of the box to allow any SNS to hold any ICRC1 token.
In OpenChat we have around 50 different proposal types which makes following on anything other than “all types”, extremely onerous and therefore means it is unlikely anybody does it. This negatively impacts decentralization. We would like to be able to organise proposals into groups and support following by proposal group.
In a similar vein, it is necessary to configure following on each neuron separately. You can configure your oldest neuron and then configure each of you other neurons to follow it on “all proposal types” and also individually on each critical proposal type. But this is far too complicated and onerous and so again, negatively impacts decentralization. If following was configured at the principal level then this would massively simplify the process. Alternatively, if there was a single setting/button to have all your neurons automatically follow your oldest neuron on all types including critical proposals, then this would also massively simplify the process.
We would like named neurons to help people setup following for neurons other than the team neuron which would improve decentralization
The SNS decentralization swap can be configured to geoblock given countries by IP address. However, people from these countries can still become DAO members by staking tokens at a later date. The SNS should also support Geoblocking of staking.
Hey I’m a developer from Aikin, working on Nuance SNS, I’ve gathered some feedback from the team on improvements we would like for the SNS:
@megrogan this is a brilliant idea. I’m behind this 100% I particularly like the idea about following voting on principle, or being able to filter by that type is a good idea.
Oh and the auto following function of new neurons is also a great idea.
• SNS projects should contribute more to the community
• Kindly make the YML file more descriptive - some of the parameters are not clear.
• The YML file changes corresponding to the versions: SNS-test Repo is not updated with DFX.
• More efficient SNS Cycles Recharge and Maintenance, through notifications.
• SNS projects should take efforts to bring liquidity
Thanks, everyone, for the useful suggestions!
@branbuilder, when you say “SNS projects,” you’re referring to the community + developers, right?
I agree with the first and the last bullets from your list, but those are for the community and developers rather than the SNS framework, right?
Hey everyone 
Saikat from Yral here
Feature Requests for SNS capabilities from our end are:
Will explain the 2nd use case.
For app upgrades, right now, we do 4 separate proposals and manually wait around 10 mins to ensure each one of them passes. IF there were a multi step upgrade let’s say with some sort of standards based callback mechanism, then we could have say proposals that,
@gravity_vi from our team can add more if I missed something 