SNS initial token swap

[Jacobs.ic]

What will be the tokennomics from the SNS tokens?

[plsak]

@lara

the maximum guarantees that no principal can get too large of a share of the initial token distribution

Thank you for the proposal (I overlooked that this topic was already started)!

My questions is related to above quoted text - how will you guarantee that someone won’t create 1k principals and then use them to get too large of a share?

You can say that it’s not realistic from administration perspective, but I think that several project will be worth hiring people for that and setting up some automations.

IMO possible solution would be to allow only principals which passed People Party, but from my understanding (recently raised question about that in different thread) this is delayed.

Thanks again, I believe that SNS will be a game-changer and a gateway to true Web3!

[bjoernek]

Hi @Jacobs.ic

the suggested design for SNS rewards is described in this forum post. In a nutshell: we suggest leveraging the concepts and code base of the NNS reward scheme but make configurable.

There is also a dedicated community conversation on this topic.

[Jacobs.ic]

Thanks Bjoernek for your awnser. I appreciate your taking time for acurate answers

[lara]

Hi @ArjaanBuijk, thanks for the question!
I think you could deploy SNS canisters locally or on an application subnet to try out different things. For example, I think you could locally set up an NNS and SNS and simulate the proposal to start the swap (this has the advantage that you don’t use cycles, although you might also want to test cycles). Or you could manually deploy the SNS canisters on an application subnet if you want to play around with them and also see the cycle behaviour.

[lara]

Hi @plsak, this is indeed a problem that we do not fully solve.
As you say, once we have good means for proof of humanity / personhood, for example by people parties, we could attach such a restriction. But they are not ready yet so we think it is worth to nevertheless already release the SNS without this and potentially add such improvements in later iterations.

One idea to nevertheless mitigate this problem a bit is to give some tokens to principals that are already “known”. For example, when a dapp has been live for a while, there might be some principals that have very active profiles and a lot of community members might even know the person behind the principal / profile. When a dapp is decentralised, it could choose to give some initial neurons to such “known” dapp users and less tokens to the initial token swap. This does of course not prevent the problem as a) multiple dapp profiles might belong to the same person and b) the dapp users could purchase additional tokens in the initial swap, but it might make an attack harder and thus provide more confidence for decentralisation.
Does that make sense?

Thanks! I am also looking forward to seeing SNSs be used by a vide variety of dapps!

[plsak]

Hi @lara and thanks for the response!

I agree that it’s better to release SNS rather sooner but as thinking about possible workaround (until People Parties are live) got this idea (although I’m not sure if is technically feasible):

• limit participation in the SNS swap/auction only to principals, which have at least one voting neuron older than (let’s say) three months
  • or apply the limit only for 80%(?) of tokens - to allow minor/20%(?) participation also for new investors…
  • there might be also some limitation on minimal voting power or neuron being in CF, but that might be already too restrictive
  • indeed the limitation could be completely different, my main point is to link the participating principals with their voting neurons and use this as prevention
    • and any such settings could be part of initial swap parameters - handing over responsibility for it to the dapp devs

      @lara

      parameters can be set for each initial swap

I believe that this would:

1. prevent speculators and favor long term IC investors
2. effectively disable possibility to cheat with large number of principals
   • although several investors might have large number of voting neurons, they most likely keep them under limited number of Internet Identify accounts/principals (although I’m not 100% sure that single II account means single principal - looks like that for me) - and with age (or rather creation date - as age averages down when increasing stake) limitation there would be no option how to generate large number of valid new ones

Hopefully this idea will be useful at least a bit, looking forward SNS a lot (I’m quite small investor, but still, some of the projects look great)!

[Bevis]

初始代币兑换或卖的分配和最高限额是否可以考虑NNS投票权重这个因素？这样可以一定程度防止机器人恶意拍卖也可以激励ICP长期投资。[quote=“lara, post:1, topic:13591, full:true”]
TL;DR：我们为新的“初始令牌交换”罐提供高级设计。我们解释了为什么这是将互联网计算机上的现有dapp转换为由SNS DAO控制的分散式dapp过程的重要组成部分。

背景 SNS

与[网络神经系统（NNS）]（https://medium.com/dfinity/the-network-nervous-system-governing-the-internet-computer-1d176605d66a）是控制互联网计算机区块链（IC）的开放代币化治理系统（IC）类似，服务神经系统（SNS）是算法DAO，允许开发人员为其dapp创建分散的、基于令牌的治理系统。请参阅[本文]（https://medium.com/dfinity/how-dapp-developers-placing-their-faith-in-total-decentralization-will-inherit-the-world-79419a3e36c9），以了解有关SNS如何授权dapps充分利用IC潜力的更多背景。

SNS由一组罐子组成，包括治理罐和分类账罐。分类账罐包含SNS令牌，这是每个SNS的唯一令牌。它存储哪些帐户拥有多少个SNS令牌以及委托人之间的交易历史记录。治理罐存储了关于如何发展SNS管理的dapp的建议，以及定义谁是治理参与者的神经元的建议。神经元包含赌注的SNS令牌，每个人都可以通过在神经元中押注SNS令牌成为开放治理过程的参与者。

目标

要分散dapp，开发人员可以将dapp的控制权移交给社区。当然有很多方法可以做到这一点。互联网计算机SNS的目的是以非常简单的方式允许这一点：开发人员可以将他们的dapp的控制权移交给互联网计算机，然后互联网计算机将根据开发人员的规范，为他们启动带有治理系统和令牌分类账的SNS。启动SNS的一个关键部分是新创建的代币是如何分配的，以及如何将它们押注到神经元中，以便SNS的治理确保适当的分散化。

在这篇文章中，我们提供了一种实现这一点的简单方法：我们介绍了初始令牌交换的概念，参与者可以将ICP令牌交换为SNS令牌，为dapp提供资金。然后，我们解释了如何在SNS的推出中利用这种初始代币交换。

与其他 SNS 项目的上下文

虽然最初的SNS设计包括代币拍卖，但最新的SNS时间表（见[本论坛帖子]（https://forum.dfinity.org/t/sns-service-nervous-system-timeline-pilot-projects/11963））不包括碳里程碑的初始代币分配。这个想法是，我们稍后会添加这个作为附加功能。

然而，对于项目来说，他们的SNS的启动必须将其投票权分配给许多不同的神经元持有者。由于碳里程碑的目标是SNS已准备好使用，我们建议优先考虑实现开放初始令牌分配的工作，并将其纳入碳里程碑。

初始代币交换的拟议设计

为了确保代币可以在SNS发布期间分发给独立方，我们建议使用初始代币交换，该交换由新引入的交换罐实现。

我们首先解释了交换罐的拟议设计，然后解释了如何将该交换罐集成到SNS发射的流程中以实现分散。

####交换罐设计

每个SNS将有一个单独的交换罐，该罐仅在SNS启动期间存在。

*交换罐一开始就设置了一定数量的SNS代币，以公开分发。

*在互换期间，参与者可以将ICP发送到交换罐，为dapp的资金做出贡献。
*在掉期结束时，收集的ICP被“交换”为SNS令牌：掉期参与者获得SNS令牌，SNS获得收集的ICP。每个用户将收到他们那部分SNS代币池，按其占ICP贡献总数的百分比进行比例。例如，如果掉期罐最初持有1000个SNS代币，并在掉期期间收集了500个ICP代币，那么汇率将是2:1，每个掉期参与者将为他们贡献的每个ICP代币获得2个SNS代币。
因此，汇率与基于自动做市商（AMM）的分散式交易所（DEX）类似，其中假设是两个代币池具有同等价值。
*掉期实现a）设定SNS令牌的市场价格，b）每个掉期参与者以该价格获得SNS代币。

为了确保这个过程的重点是分发dapp治理，而不是投机，所有代币都将在神经元中分发，溶解延迟为三个月。这应该会给SNS社区留出足够的时间，在第一批代币成为液体之前启动代币市场。

接下来，让我们详细了解一下初始交换罐的细节，特别是可以为每个初始交换设置哪些参数，以及它们如何影响交换。

• ICP代币的最大数量：掉期收取的最大ICP作为资金。如果达到这个金额，掉期就结束了。与下一个参数一起，这决定了最低和最高SNS代币价格。

• 最低ICP代币数量：掉期需要收集的ICP最低数量才能被视为成功。与第一个参数一起，这决定了最低和最高SNS代币价格。

• 交换截止日期：掉期结束的截止日期。如上所述，如果收集了最大数量的ICP代币，掉期可能会在截止日期前结束。

• 掉期参与者的最低人数：交换参与者的最低人数，以被视为成功的掉期参与者。

• 每个参与者的最低和最高ICP金额：每个交换参与者可以贡献的最低和最高ICP金额。最低限额实现每个参与者都有最低投资，而最大限度保证任何本金都不能获得过多的初始代币分配份额。

总之，有两个参数，即ICP代币的最大数量和掉期截止日期，决定了掉期何时结束，以及两个参数，即ICP代币的最低数量和掉期参与者的最低数量，决定了交换是否成功。最后，每个参与者的最低和最高ICP数量决定了什么是有效的参与。

如果掉期成功，则为每个掉期参与者创建神经元，其中包含由上述汇率确定的赌注SNS代币数量。如果掉期结束但不成功，例如，由于收集的ICP不足，所有收集的ICP代币都将转移回掉期参与者。

SNS 发布

现在，让我们研究一下如何启动SNS，这就是如何使用这个初始令牌交换将dapp的控件从集中状态过渡到分散状态。拟议的设计旨在实现以下目标：

*向SNS社区移交dapp的开发人员应该在启动的SNS中获得一些投票权

*启动的SNS的初始投票权份额，即初始神经元，应由独立政党拥有，互换应分散
*推出的SNS应该有一些初始资金，SNS社区可以使用这些资金来支付贡献者、支付周期费用和使用奖励
*在掉期结束之前，没有人可以转移SNS代币
*随时可以升级dapp以对其进行改进并解决错误

为了实现这些目标，我们建议SNS的发布经过以下阶段。

1。初始化SNS：当开发人员初始化他们想要将dapp控制权移交给SNS时，他们会选择分配给开发人员、初始令牌交换和财务的部分令牌，该帐户将由SNS治理罐拥有，SNS社区可以根据自己的需求使用。也许他们还可以指定分配给其他预定义方的部分令牌，例如将一些令牌“空投送”给已知的dapp用户。开发人员还可以定义交换的条件，例如至少应该收集多少个ICP代币（详见上文）。
由于SNS尚未分散，交换罐由NNS控制。
在SNS发布期间，只有两个带有流动代币的分类账账户，即治理罐拥有的国库和掉期罐拥有的预分配代币。为了确保没有人可以转移代币，并分发代币或过早启动代币市场，开发人员或“空投参与者”的所有初始代币都被锁定在神经元中。此外，为了确保这些初始神经元不能在交换之前或期间修改SNS，也不能转移财务令牌，SNS部署在功能有限的预发生模式下。

2。**Dapp控制权移交：**在SNS初始化和交换开始之间，开发人员将dapp的控制权移交给SNS。由于已经有初始神经元（来自第1步），dapp现在可以通过SNS提案升级。最初的神经元不能做其他事情，例如更改SNS参数，因为SNS治理罐仍处于预发生模式。由于开发人员在SNS初始化之前就已经在控制dapp，与SNS初始化之前的状态相比，他们实际上没有任何额外的特权。
3。开始掉期：掉期由NNS提案发起。这意味着在发布期间，最初控制dapp的开发人员将他们的dapp的控制权移交给NNS，然后为它们初始化交换。在对NNS开始交换提案进行投票时，NNS神经元应考虑交换参数是否有意义，最重要的是，dapp的控制是否已经移交给SNS（即步骤2已成功完成）。因此，NNS提案也是一种保障措施，人群的智慧可以在诱骗用户投资之前检测到潜在的恶意SNS。
如果NNS提案获得通过，则交换由NNS启动。如果NNS提案被拒绝，SNS启动将被中止，dapp的控制权将移交给开发人员。
4。初始交换：当交换开始时，交换罐保存初始化时指定的SNS令牌数量（见步骤1）。最终用户可以通过将ICP令牌转移到交换罐来参与初始令牌交换。

5。SNS起源：当掉期结束时，首先确定掉期是否成功，例如，收集了足够的ICP。
如果掉期成功，汇率如上所述确定，所有代币将提供给押注三个月的神经元的掉期参与者。一旦所有神经元都创建，SNS将处于分散控制之下，治理罐将被设置为功能齐全。
如果掉期不成功，权力下放尝试就会失败。因此，在SNS发布之前，所有内容都将恢复到状态，包括将dapp的控制权交还给开发人员，并将所有收集的ICP退还给交换参与者。

未来方向

一开始，我们提出了在SNS发射中需要解决的挑战。我们认为最初的互换罐是应对这些挑战的第一个工具。稍后，可以提供其他或替代工具，从而生成一个工具包来启动SNS，SNS发射台。

这种可能延期的一个例子是社区基金，我们将在未来几天分享第一个设计提案。

安全

我们认为这是一个安全关键功能。例如，涉及不同的代币（SNS代币和ICP代币），必须确保交换参与者获得SNS神经元，当且仅当他们正确地将ICP存入交换中。

我们已经与DFINITY的安全团队一起审查了设计，并计划在实施完成后在他们的帮助下进行彻底的安全审查。

考虑的替代方案

*我们可以在没有初始令牌分发的情况下启动第一个版本的SNS。如上所述，想要启动SNS的项目需要此功能。因此，我们认为将这一功能作为碳里程碑的一部分很重要。
*我们本可以选择使用拍卖而不是交换来分发初始代币。这种拍卖必须a）确定SNS代币的市场价格，b）每个人都必须支付相同的价格（否则一些参与者将获得不公平的优势）。许多现有的拍卖机制不能满足这两种要求，因此不清楚这种拍卖的细节会是什么样子。建议的初始互换提供了所有必需的属性，而不会引入额外的复杂性。除了更简单的设计外，最终用户可能更容易理解交换的另一个原因是，它与许多用户熟悉的分散式交易所中使用的令牌交换非常相似。

Procedure Motion 提案和更新的 SNS 时间表

如上所述，我们建议将此功能添加到碳里程碑中。

关于引入此功能，我们建议进行以下操作：

1。本周和下周：讨论这个论坛帖子关于拟议设计
2。6月9日星期四：社区对话
3。下周：就上述设计进行投票的动议提案（可能更新，并听取1和2的反馈）
[/报价]

@lara

TL;DR: We provide a high level design for a new “Initial Token Swap” canister. We explain why this is an essential part of the process of converting an existing dapp on the Internet Computer into a decentralized dapp controlled by a SNS DAO.

Background SNS

Similarly to how the Network Nervous System (NNS) is the open tokenized governance system that controls the Internet Computer blockchain (IC), service nervous systems (SNSs) are algorithmic DAOs that allow developers to create decentralized, token-based governance systems for their dapps. We refer to this article for more background on how SNSs will empower dapps to leverage the full potential of the IC.

A SNS consists of a set of canisters, including the governance canister and the ledger canister. The ledger canister contains SNS tokens, which are unique tokens for each SNS. It stores which accounts own how many SNS tokens and the history of transactions between the principals. The governance canister stores proposals that are suggestions on how to evolve the dapp that the SNS governs and of neurons that define who are the governance participants. Neurons contain staked SNS tokens and everyone can become a participant of the open governance process by staking SNS tokens in a neuron.

Objective

To decentralize a dapp, developers can hand over the control over their dapp to a community. There are of course many ways to do so. The aim of the Internet Computer’s SNS is to allow this in a very simple way: developers can hand over the control of their dapp to the Internet Computer that will then launch an SNS for them with a governance system and a token ledger according to the specification of the developers. A crucial part of launching an SNS is how the newly created tokens are distributed and how they are staked into neurons for the SNS’s governance ensuring proper decentralization.

In this post, we provide a simple way to achieve this: we introduce the concept of an initial token swap where participants can exchange ICP tokens for SNS tokens to provide funding for a dapp. We then explain how this initial token swap can be leveraged in the launch of SNSs.

Context with other SNS projects

While the original SNS design included a token auction, the latest SNS timelines (see this forum post) did not include an initial token distribution for the Carbon milestone. The idea was that we would add this later as an additional feature.

However, it is essential for projects that the launch of their SNS distributes its voting power over many different neuron holders. As the goal of the Carbon milestone is that the SNS is ready to be used, we propose to prioritize the work to realize an open initial token distribution and to include it in the Carbon milestone.

Proposed design of the initial token swap

To ensure that tokens can be distributed to independent parties during an SNS launch, we propose an initial token swap, which is implemented by a newly introduced swap canister.

We first explain the proposed design for the swap canister and then explain how this swap canister is integrated into the flow of an SNS launch to achieve decentralization.

Swap Canister design

Each SNS will have a separate swap canister that only exists for the duration of the SNS’s launch.

• The swap canister is set up at start with a defined amount of SNS tokens to be distributed publicly.

• During the swap, participants can send ICP to the swap canister to contribute to the dapp’s funding.

• At the swap’s end the collected ICP are “swapped” for the SNS tokens: the swap participants get SNS tokens and the SNS gets the collected ICP. Each user will receive their portion of the pool of SNS tokens, pro-rated by their % of the overall number of ICP contributed. For example, if the swap canister initially held 1000 SNS tokens and 500 ICP tokens were collected during the swap, then the exchange rate would be 2:1 and each swap participant would get 2 SNS tokens for each ICP token they contributed.
  The exchange rate is thus set similarly to decentralized exchanges (DEXs) based on automated market makers (AMM), where the assumption is that two pools of tokens are of equal value.

• The swap achieves that a) a market price for the SNS token is set and b) every swap participant receives SNS tokens at that price.

To ensure that the focus of this process is on distributing dapp governance and less on speculation, all tokens will be given out in neurons with a dissolve delay of three months. This should leave enough time for the SNS community to start a token market before the first tokens are liquid.

Let’s next look into a bit more details about the initial swap canister, specifically which parameters can be set for each initial swap and how they affect the swap.

• Maximum amount of ICP tokens: The maximum amount of ICP that the swap collects as funding. If this amount is achieved, the swap ends. Together with the next parameter, this determines a minimum and maximum SNS token price.

• Minimum amount of ICP tokens: The minimum amount of ICP that the swap needs to collect to be considered successful. Together with the first parameter, this determines a minimum and maximum SNS token price.

• Swap deadline: The deadline when the swap ends. As mentioned above, the swap may end before this deadline if the maximum amount of ICP tokens has been collected.

• Minimum number of swap participants: The minimum number of swap participants for the swap to be considered successful.

• Minimum and maximum amount of ICP per participant: The minimum and maximum amount of ICP that each swap participant can contribute. The minimum achieves that each participant has a minimum investment while the maximum guarantees that no principal can get too large of a share of the initial token distribution.

In summary, there are two parameters, the maximum amount of ICP tokens and the swap deadline, that determine when a swap ends and two parameters, the minimum amount of ICP tokens and the minimum number of swap participants, that determine whether the swap was successful. Finally, the minimum and maximum amount of ICP per participant determine what constitutes a valid participation.

If a swap is successful, neurons are created for each swap participant containing the amount of staked SNS tokens as determined by the exchange rate described above. If the swap ends but is not successful, for example because not enough ICP have been collected, all collected ICP tokens are transferred back to the swap participants.

SNS launch

Let’s now look into how an SNS can be launched, that is how a dapp’s control can be transitioned from the centralized into the decentralized state, using this initial token swap. The proposed design aims to achieve the following goals:

• The developers handing over a dapp to an SNS community should get some voting power in the launched SNS

• A share of the initial voting power of a launched SNS, that is initial neurons, should be owned by independent parties and the swap should be decentralized

• A launched SNS should have some initial funding that the SNS community can use to pay contributors, pay for cycles, and pay for usage rewards

• Prior to the swap’s end, no one can transfer SNS tokens

• At any time, the dapp can be upgraded to evolve it and address bugs

To achieve these goals, we propose that an SNS launch goes through the following stages.

1. Initializing the SNS: When developers initialize a SNS to which they want to hand over the control of their dapp, they choose a portion of tokens that are allocated to the developers, to the initial token swap, and to a treasury, which is an account that will be owned by the SNS governance canister and can be spent by the SNS community according to their needs. Possibly they can also specify a portion of tokens that are allocated to other predefined parties, for example to “airdrop” some tokens to known dapp users. The developers can also define the conditions for the swap, for example how many ICP tokens should at least and at most be collected (see details above).
   As the SNS is not yet decentralized, the swap canister is controlled by the NNS.
   There are only two ledger accounts with liquid tokens during the SNS launch, the treasury that is owned by the governance canister and preallocated tokens owned by the swap canister. To ensure that no one can transfer tokens, and distribute them or start token markets prematurely, all initial tokens from developers or ‘airdrop participants’ are locked in neurons. Moreover, to ensure that these initial neurons cannot modify the SNS before or during the swap and cannot transfer the treasury tokens, the SNS is deployed in a pre-genesis mode with limited functionality.

2. Dapp control handover: Between the SNS initialization and the start of the swap, the developers hand over the control of their dapp to the SNS. As there are already initial neurons (from Step 1), the dapp can now be upgraded via SNS proposals. The initial neurons can not do other things, such as changing the SNS parameters, as the SNS governance canister is still in pre-genesis mode. As the developers were already controlling the dapp before the SNS initialization, they effectively do not have any additional privileges compared to the state before the SNS initialization.

3. Starting the swap: The swap is started by an NNS proposal. This means that during the launch, the developers that originally controlled the dapp hand over the control of their dapp to the NNS that then initializes the swap for them. When voting on a NNS proposal to start a swap, the NNS neurons should consider whether the swap parameters make sense and, most importantly, whether the dapp’s control has been handed over to the SNS already (that is Step 2 was completed successfully). The NNS proposal thus also serves as a safeguard where the wisdom of the crowd can detect potentially malicious SNSs before they trick users into investing in them.
   If the NNS proposal is adopted, the swap is started by the NNS. If the NNS proposal is rejected, the SNS launch is aborted and the dapp’s control is handed back to the developers.

4. Initial swap: When the swap starts, the swap canister holds the number of SNS tokens that were specified at initialization (see Step 1). End users can participate in the initial token swap by transferring ICP tokens to the swap canister.

5. SNS genesis: When the swap ends, it is first established whether the swap was successful, e.g., enough ICP have been collected.
   If the swap was successful, the exchange rate is determined as explained above and all tokens will be given to the swap participants in neurons staked for three months. Once all neurons are created, the SNS is under decentralized control and the governance canister is set to be fully functional.
   If the swap was not successful, the decentralization attempt failed. Thus, everything will be reverted to the state before the SNS launch, including that the dapp’s control is handed back to the developers and all collected ICP are refunded to the swap participants.

Future directions

In the beginning we presented the challenges to be solved in a SNS launch. We see the initial swap canister as a first tool to address those challenges. Later, additional or alternative tools can be provided resulting in a toolkit to launch SNSs, a SNS launch pad.

One example of such a possible extension is the community fund, for which we will share a first design proposal in the coming days.

Security

We consider this to be a security critical feature. For example, different tokens (SNS tokens and ICP tokens) are involved and it must be ensured that swap participants get SNS neurons if and only if they correctly deposited ICP into the swap.

We already reviewed the design with DFINITY’s security team and plan to have thorough security reviews with their help once the implementation is done.

Alternatives considered

• We could launch the first version of the SNS without an initial token distribution. As argued above, such a feature is required for projects that want to start an SNS. We therefore think it is important to include this feature as part of the Carbon milestone.
• We could have chosen to use an auction, rather than a swap, for the initial token distribution. Such an auction would have to a) establish the market price of SNS tokens and b) should be such that everyone has to pay the same price (otherwise some participants would get an unfair advantage). Many existing auction mechanisms do not satisfy both of these requirements so it is unclear what such an auction would look like in detail. The suggested initial swap provides all the required properties without introducing additional complexity. In addition to a simpler design, another reason why the swap might be easier to understand for end users is that it closely resembles token swaps used in decentralized exchanges, which many users are familiar with.

Procedure Motion proposal & Updated SNS timeline

As already argued above, we propose that this feature is added to the Carbon milestone.

Regarding the introduction of this feature, we propose to proceed as follows:

1. This & next week: Discussion on this forum post regarding the proposed design
2. Thursday June 9th: Community conversation
3. Next weeks: Motion proposal to vote on the above design (potentially updated with feedback from 1 & 2)

[Pete]

For the record, the motion proposal was adopted on 2022-06-19.

Internet Computer Network Status

[Pete]

Thanks plsak, assigning some kind of reputation to a principal on the basis of past history of interactions (with the NNS or other activity) and using those reputation attributes to gate access to new functionality is certainly an idea we’d like to explore in general on the IC.

One of the key features of an SNS initial token swap is we’d like broad participation and not lock access to only insiders, this would include users of the dapp (who may not be NNS neuron holders) and also brand new users to the IC ecosystem to be able to participate. Hopefully in turn these users also become participants of the NNS.

By locking the SNS tokens issued in neurons and distributing all tokens at the same price, we think this will dampen down some of the motivations for short term speculative behaviour.

[Tony89]

Hi, I have a proposal that projects that want to participate in fundraising on SNS need to be approved by the community through votes from the proposal on NNS.
because the market always has projects that only give promises but their purpose only wants to scam investors. Therefore, participating projects that need votes from the IC community through the NNS proposal will partly reduce the risk for investors. people can check and approve projects that are trusted enough by the community by voting. while protecting IC .'s reputation

[Lagatha]

Hello all,
I have a few questions;

Will ICP token be replaced by SNS token in future ? If so how can I swap ICP tokens for SNS on binance? I don’t wanna sell my ICP tokens right now because I am in big loss. Please help me to understand this process.
Thank you

[singularity]

No, SNS token is an umbrella term to mean tokens issued on the IC using the IC SNS platform.

[blockpunk]

As a long-term researchers of IC ecology, we have found some problems from the evolution of SNS design:

• DFINITY Foundation doesn’t just provide the underlying capabilities, it always tries to guide developers at the application level and show them how to do it;
• To make things even more awkward, the DFINITY foundation wants more NNS control over SNS, but doesn’t want to provide a less accessible interface.

For example, in the SNS rewards system, the foundation even went so far as to design a curve paradigm for voting rewards for SNS, but the truth is that developers probably don’t need such complicated low-level features.

Another example is the SNS initial token swap. In the current design of DFINITY, as a low-level capability, the swap container can only be started after DApp has passed the NNS governance vote. This raises a number of questions:

• This greatly increases the startup cost of Dapp developers, who may need to solicit votes or even buy ICP votes themselves;
• SNS may be controlled by ICP whales or external capital. Big capital has the ability to vote down specific initial swap financing requests to suppress competitive projects that do not meet its own interests, and pull IC ecology into the quagmire of the factional struggle for governance;
• Reduces the financing efficiency of ICP (and thus the potential value of ICP) and stifles genuine innovation.

Another example is the NNS community fund, which is a community-managed investment DAO, but is directly integrated into the management page of the NNS neuron, which seems to become a system low-level function. Communities could have implemented their own Venture DAOs to achieve decentralized investment, but community funds killed many of the possibilities.

Sure, these “overdesigns” of SNS may push the ecosystem in a specific direction faster and make developers worry less about such trivia, but they may also stifle some interesting innovations.

We Need Underlying Purity

As an infrastructure, it should be kept pure, allowing developers to explore any kind of application on it, and not discriminating against any kind of application. Diversity is the foundation of a thriving ecosystem and the secret of ETH’s ecological success.

It’s great to see new capabilities of IC underlayer that allow developers to integrate previously unseen types of applications into blockchain systems. But some of the design of SNS tries to take the place of community thinking and lead developers to conform to certain paradigms, which is not what the underlying infrastructure should do. Will the initial token swap function limit the innovation of various IDO, fair distribution, and Launchpad platforms? Will the Community Foundation limit Venture DAOs’ innovation? Will SNS reward system limit the innovation of incentive means? We have to be skeptical.

At the same time, we believe that the underlying functions of the system should be permissionless, which should not increase the cost of developers in the admittance. SNS and its initial token swap functionality should be provided to any developer as a system low-level feature, with no access, no barriers, and out of the box. In addition to the additional cost of entry, it is also difficult to build dapps and tools based on it.

What Can We Improve?

Enable access to the SNS dedicated subnet

Developers should be free to deploy their own SNS systems in a SNS dedicated subnet just as they would deploy containers in an application subnet, just paying enough cycles. The use of swap containers in SNS should not be controlled by NNS governance.

If there are concerns about potentially fraudulent projects after open access, then the governance capability of SNS itself can be relied on, and the use of ICP financing (such as refunds) can be determined by the users participating in the initial token swap. NNS governance can serve as a trusted discovery mechanism for recommending good projects to users. SNS should not be confused with NNS governance.

More modular SNS

We should make a clear distinction between what is the essential basis of SNS and what is the further application of SNS. If a feature is an application, it should be more modular, allowing developers to replace it with their own code implementation. Obviously, the root container and ledger container of SNS are indisputable, while governance and initial token distribution, incentives, and frontend are all applications.

Developers can replace the governance module to implement a variety of mechanisms such as pledge voting, non-pledge voting, and proxy voting. For the swap container corresponding to the initial token distribution, the developer should also add continuous financing, multi-round financing, auction, liquidity mining, and other launch methods.

Continue to encourage the development of DApps

The initial token swap only provides a cold start-up cost for dApps and is the beginning of development, not the end. Therefore, after the successful launch of SNS, how to motivate the founding team, developers, and contributors to continue to support the development of Dapp has become a very important issue. In the development of Dapp, there is a lot of tedious, periodic, and flexible payment and management work, which is difficult for SNS referendum to take care of.

In the setting of initial token distribution in SNS, the funds raised in the future cannot be preset (for example, allocate part of ICP to the founding team for continuous development), and the funds of developers cannot be guaranteed.

Will a future feature allow developers to customize the allocation of raised funds? For example, create a smaller Treasury for the development team, make one-time or periodic contributions from ICP financing to the development team Treasury, and allow the development team to use the funds freely without having to vote on SNS.

The release of SNS Token

After fundraising, SNS tokens are not released immediately, but are locked in neurons for three months. But some dapps may need to circulate utility tokens to run their business, which requires the tokens to be released immediately, while SNS does not yet have this flexibility.

SNS should give developers the ability to customize the unlock/release rules for SNS tokens, such as setting the neuron lock delay to 0 to allow tokens to enter business flow quickly.

[Tony89]

Hi bro, I see your views are only evaluated from the developer side, so what about from a small investor position? what if there are projects that only raise capital and then do nothing (rugbull)?? if the projects feel it doesn’t fit the terms of SNS then I think they can fundraise or sell their tokens another way, like ORIGYN they sold OGY on soonic without using SNS.

[singularity]

Rugpulls are a bigger problem so I support how SNS is currently set up

[blockpunk]

No need to worry, after the initial exchange ICP funds go to the SNS treasury, which is controlled by governance and any grants need to go through governance. In case of a project rug, the small investor can refund the ICP funds from the treasury through the SNS governance. If the project stops development after a period of time, the community can also encourage new contributors through governance.

However, the key point is that NNS should not be used to control the threshold for SNS deployment.

[Tony89]

I don’t understand why you are afraid of the problem that the community does not approve the project, if you are confident that you are building a really good project that brings benefits to the community, then of course the community will vote for you. Are you here worried that your project is not good and can’t vote to be able to raise capital on SNS?? Here I am advocating for projects that work really and really bring benefits, not a promise and a nice whitepaper to suck ICP of small investors with little knowledge. Therefore, I support the need to go through the NNS to vote for projects that want to join SNS. with enough knowledgeable people evaluating projects and voting will help eliminate projects that just talk but don’t do, just make promises without core. The NNS belongs to the community of IC believers, and is the central nervous system that protects the IC. so the power of the community to vote together to protect each other is natural. nothing bad here. 1 review alone may be wrong, but many reviewers will have better results. so votes from multiple voters will have more accurate results. Projects that want to participate in SNS they will need to do really well because behind them there is a large community that evaluates and votes for it. will reduce projects with bad intentions. because if they have bad intentions the community will detect and not vote for them, avoiding damage to the community and IC’s reputation in the long run.

[marcio]

Look at what happened with Luna, many smart people lost tons of money. I don’t think NNS can protect you.

Moreover, if somehow the NNS ends up voting in favor of Luna3 (or whatever), which is quite probable, we could have a big problem when investors come back for us.

IMO, there is no point in losing decentralisation for something that doesn’t have a clear value.

Just my 2 cents.

[Tony89]

if you don’t believe in DAO, don’t believe in NNS decentralization, then SNS turn your project into a DAO in your project token on SNS will work like ICP on NNS. if you don’t believe in decentralization then why do you want to put your project to swap tokens on SNS?? who will believe you?? Who will believe that your tokens exchanged on SNS will become a decentralized governance token like a DAO??