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.
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
- Concise description of the underlying application & use case.
- Role of the SNS within the project.
- 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.
- Clear articulation of the minimum and maximum funding target.
- Planned usage of funds, e.g., plan for team ramp-up plan.
Community fund (CF) contribution
- To facilitate CF participation in various projects, the CF contribution to a single project should not exceed 10% of the total maturity of the CF at the time of submission.
- To facilitate a contribution from direct participants and the CF, the CF contribution should not exceed 33% of the max funding target of the SNS. Also, the CF contribution should be well below the minimum funding target (two thirds of the minimum funding target).
Decentralization & voting power
- This is particularly relevant if the SNS plans to raise funds via the swap.
- Provide a technical decomposition of the dapp architecture in terms of canisters, 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.
- 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.