DFINITY's voting on upcoming SNS launch proposals

Background & goal

During the last weeks several project teams have raised the question how DFINITY intends to vote on upcoming SNS launch proposals for future SNS projects. In order to be transparent, we would like to share our current thinking.

Before we go into details, we would like to make the following disclaimer: Given that the SNS framework is very new, the community & we have only very limited experience on reviewing and voting on actual proposals. With experience collected over time, our views and focus points might evolve. This post only provides initial thoughts from the perspective of DFINITY. Other (known) neurons might have different views.

Out of scope

An assessment of the viability of a given project is out of scope of our assessment. This is up for the participants of the SNS swap to decide.

Overall approach

Our intent is to explain our thinking so community standards can emerge on minimum standards with respect to the amount of information & analysis which is deemed to be necessary for the community overall to make informed decisions.

Adherence to the minimum standards does not mean DFINITY will always vote yes, if these are full-filled. It is rather meant to establish a basis for a clear & concise discussion. However, it is of course in the interest of the IC (and hence also DFINITY) to foster the growth of the IC ecosystem, including the launch of many SNSes.

DFINITY would typically vote towards the end of the voting period, in order to pick up signals from the community and typically not overrule the community direction.

Suggested minimum standards

Project description

  • Concise description of the underlying application & use case.
  • Role of the SNS within the project.

Syndication approach

  • Careful syndication of the SNS proposal, including a motivation of the chosen tokenomics parameters in the proposal and SNS init file (e.g. in the form of a whitepaper).
  • Post at least in https://forum.dfinity.org/ and ideally further channels.
  • The syndication (once all parameters are fixed) should last at least two weeks.

Funding target

  • Clear articulation of the minimum and maximum funding target.
  • Planned usage of funds, e.g., plan for team ramp-up plan.

Neuron fund (NF) contribution

[Ammendment May 16th 2024]

As highlighted in Dom’s post, proposals requesting contributions from the NF should meet a higher standard. The Foundation reserves the right to decline proposals for projects where no significant on-chain Open Internet Service would be governed by the SNS, such as memecoins or other primarily off-chain entities or services.

Decentralization & voting power

  • This is particularly relevant if the SNS plans to raise funds via the swap.
  • Provide a technical decomposition of the architecture, so that the community can validate that the dapp will actually be a decentralized application after the swap.
  • Articulate on token distribution and voting power (including vesting periods for the dev & seed team)
  • Analyze the distribution of voting power at genesis, potential attack vectors and how the voting power might evolve over time.
  • Articulate why the DAO is decentralized.
    • It is considered to be best practice that sale participants have the majority of voting power at genesis.
    • If the dev team has the majority, then DFINITY would reject because the SNS is not decentralized (and could be mis-used for, e.g., a rug-pull).
    • If the dev & seed have the majority, then it should be clearly articulated why dev / seed are independent.

Security aspects

  • In general, it is considered to be best practice to conduct a security review including the fixing of risky findings. Guidance on security best practices is here.
  • Hence, a project should explain to which extent security reviews are relevant for the dapp and what kind of security reviews have been conducted for the dapp if applicable.
  • Core functionality of the DAO should be open source.

The statement you provided suggests that dscvr and dmail projects left the ICP ecosystem, which I believe they are not.

From what I see, as a “for profit” project, they wanted to be perceived as neutral dApps, rather than as maximalist projects.

To attract a wide range of users from various blockchain ecosystem, it’s important for dApps to maintain this neutrality and avoid appearing to favor a specific blockchain technology.

This approach may help them gain popularity and acceptance among diverse blockchain communities.


“sol.” on the link “sol.dscvr.one” represents a subdomain in a URL. It’s a way to organize different sections or services on a webapp, it does not mean it is migrating.
There also could be “bnb.dscvr.one”, “eth.dscvr.one”, “avax.dscvr.one”