How to improve the SNS framework?

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.


1 Like

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.

1 Like

Hi @aterga , thanks for setting this up!

  • Ability to use the SNS framework without going through an SNS sale and still be running on the SNS subnet. Some projects may develop their product, launch their own custom utility token and then decide to move to a more secure environment that the SNS offers. They won’t necessarily want to go through an SNS sale because they already have a token and just want to use the framework.
  • Ability to add deflationary reward system directly in the SNS parameters. Currently, projects are either inflationary or have no rewards. At Gold DAO, we had to build our custom reward system to be able to introduce a deflationary model. A solution would be to set aside a portion of the treasury and apply an ever-reducing reward curve to it that ensures sufficient rewards are available in the treasury forever.
  • Stop adding more and more policing limitations to the SNS. Adding the 300kUSD / week limit to treasury withdrawal proposals and minting proposals may limit an SNS’ ability to grow. I understand the desire to protect SNSs but what happens if a project grows e.g. to the size of DFINITY (let’s be optimistic here)? I don’t have any insights to the financials of DFINITY but I imagine that 1.2 million USD per month is probably not enough to keep DFINITY running, including all spendings.

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:

  1. Issues with the SNS framework and proposals: Even after repeatedly reading the SNS technical documentation, I still faced:

    • Some SNS initialization parameters were not as I understood.
    • I was unsure how to draft different types of proposals for the first time because I didn’t know their underlying mechanisms and feared making mistakes. I wanted to reference successful proposals from other SNS projects but couldn’t find any, so I put all our successful proposals on GitHub for others to refer to.
    • During SNS management, we encountered problems that other teams had faced but often had to consult Dfinity members on the forum to resolve. I suspect future SNS projects will face similar issues.
  2. Challenges in marketing and promotion: Despite our efforts, we still felt disconnected from the ICP community:

    • Our free airdrop, with its low threshold and social viral mechanism, distributed tokens worth 1800 ICP, bringing nearly 100k ICP users from Twitter and gaining us 180k Twitter followers and 2k OpenChat members. Yet, this didn’t seem to make any waves in the ICP community.
    • Our lucky red envelopes, which seemed to be the first on-chain red envelopes running on Twitter, achieved good numbers within a month but didn’t make an impact in the ICP community.
    • Our technical lessons aimed to introduce the core ICP technology in simple language, received many likes and shares, but didn’t seem to resonate in the ICP community.
    • Our DeAI demo, believed to be the first LLM running in a canister (at least I haven’t seen others), also received many likes and shares but didn’t seem to make an impact in the ICP community (though it did catch Jennifer’s attention).

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:

  • Queued upgrades for voting on multiple proposals at once.
  • All or none upgrades to ensure canisters don’t advance in version ahead of others in the case of proposal failure.
  • A pre-proposal data integrity check. We use a deployment pipeline now, but when sending canister proposals from local, you can mistakenly send the wrong wasm, this risks data loss without the warnings devs would typically see in dfx.
  • List of all common proposal examples, sometimes it can be a pain to write standard proposals without examples to go off of. Even consider, why does this need to be done in the command line, a GUI may prevent input errors and save time.
  • Reiterating comments above about neurons:
1 Like

@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 :wave:t3:
Saikat from Yral here

Feature Requests for SNS capabilities from our end are:

  • Semantic versioning for SNS upgrade releases
  • Sequential/batch/multi-step proposal execution with callback mechanism

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,

  • Make a call to some canister with an expected response of failed/successful/pending
  • Time out in a specified time limit with an upper bound if no response received
  • Do this serially for all the steps in the specific proposal
  • Fail if any of the intermediate steps fail

@gravity_vi from our team can add more if I missed something :slightly_smiling_face: