SNS initial token swap

I didn’t say I don’t believe in the NNS.

It’s just that nobody can distinguish a good project from a bad project, unless you can predict the future.

Going through a vote (and I suppose a queue and etc) is definitely less decentralised than no vote.

Cheers

There are two opposing views on this issue. so in my opinion for decentralization someone should create a NNS voting proposal on this issue. Regardless of the outcome, it will be up to the voter to decide.

1 Like

It wont be 100%, but it could be 80% accuracy that a project is good, when many people in the community think it is good. For example, a lot of the community may vote that Distrikt for example is good. It reduces (even if not eliminate) the chances of bad elements taking advantage of investors with not much knowledge.

2 Likes

It also depends what do we mean by good.

Given this bull market, most of the projects are going to pump and then have a drawdown of 95% next time. Many of them can have fatal bugs. Even distrikt have bugs now and it’s being promoted on official Dfinity channels while other social networks are not.

Cypto markets are so brutal that I think it could help a small percentage, like at most 5%, but not 80%.

As an example you can look at Polkadot/Kusama crow-loans. Karura was the favourite project of the community. Right now it seats at -95% from ATH, and many inversores have locked tokens because it was endorsed by Polkadot. It’s a legit project, but not the best by far. Investors couldn’t get protected from the general market and defi in Polkadot got slowed down.

In summary, I think this is just going to hurt innovation by helping projects already established (not the best ones) to gain more power. It’s not going to protect investors.

2 Likes

In my opinion SNSes should be permissionless, all Dfinity should do is provide a UI where we can search search them all in one place and give visibility to the best DAOs.

Instead of having approved/not approved projects I think we should explore alternatives to let users decide which projects they think are the most valuable for the ecosystem, we could use some form of quadratic funding or once people parties are integrated give verified account a fixed amount of points every month that can used to vote their favourite DAO and then have “All time favourites” and monthly/yearly leaderboards.

This would make it a much more meritocratic system where quality and innovation is rewarded. The system Dfinity proposed has many issues:

  • NNS stakers could decide to approve all projects so they can get cheap tokens no matter how trusted the project is, in a bull market almost everything makes money, so many would think it’d be better to have as many tries as possible.
  • Evaluating a project’s reliability is a hard thing to do especially in Crypto, a year ago everybody thought BlockFi, Celsius and 3AC were trusted and too big to fail, we all know what happened.
  • The system proposed is too binary, a project is either approved or not and once it is it goes in a list of approved projects which will eventually consist of hundreds of DAOs, making it hard to distinguish between nice projects and great ones.
4 Likes

Thank you all for your many inputs and especially for the concrete suggestions on what to improve @blockpunk!
Let me first clarify some points that might address some of the feedback and then go through the improvement suggestions in more detail.

Clarifying points

The proposed SNS design is a first version that will be evolved by the community.
It is important to note that we propose an iterative process, thus the current design is a proposed first version of the SNS. Moreover, the SNS will be evolved by the IC community as the SNS version will be kept and voted on in the NNS. Therefore, we expect that the SNS will be evolved according to the needs of the community.

The SNS is provided with a concrete implementation.
The main reason why we think it is useful to provide a concrete implementation is that not all developers and projects might have the resources to implement their own DAO. We think that by providing the SNS as a service we make DAOs accessible to a wider range of projects. However, anyone can also take the open sourced code and diverge from it or implement their own DAO. That is, we suggest in the deployment and upgrade design (see this forum post for more details) that there are two ways a SNS can be deployed and continuously upgraded a SNS:

  1. A SNS that is a system functionality, which is automatically maintained by the IC and where the SNS canisters are hosted on the SNS subnet.
  2. A SNS that is self-deployed, manually upgraded, and hosted on an application subnet.

These two possibilities allow SNS communities to choose between using SNSs that are provided as a service by the IC, where maintenance is as automated as possible, and SNSs that have full flexibility of how they can be evolved.

The SNS subnet hosts only “blessed SNSs”
We are currently working on a feature that will allow application subnets to have a larger replication factor. As a consequence, all DAOs, including self-deployed SNSs and other DAO implementations can be deployed to high-replication subnets.

We propose to still have a separate SNS subnet only running SNSs on the “blessed upgrade path” (see this post) as this simplifies verification for end-users. Specifically, for verifying SNS canisters, users only have to verify one implementation path, as all SNSs follow the same upgrades, or they can simply trust the wisdom of the crowd, as updates to the upgrade path are voted on in the NNS.

The NNS starts SNS swaps
As different people have pointed out here, one advantage of having the SNS swaps being approved by the NNS community is to profit from the wisdom of the crowd.

I think I slightly disagree with the statement that if things go wrong then the SNS participants can be refunded with the SNS treasury. While this is true in some cases, if few principals manage to get the majority of the voting power after the initial token swap, then they can decide how the SNS treasury is spent and thus refunding of all smaller neurons might not be possible.

It is also worth mentioning that this mechanism does not prevent approval of all swaps, should the majority of the NNS neurons support this. For example, we could have known neurons that are followed for decisions on how to evaluate SNS initial token swaps and it is possible that the voting strategy of these neurons is to simply approve every SNS swap proposal. If enough people in the NNS community agree that this is the best approach and follow those neurons, then there will effectively be no gatekeeping.

Suggestions of improvements

Enable access to the SNS dedicated subnet
As mentioned above, we suggest as an alternative to provide application subnets with a large replication factor as we think this provides the advantage of more security to all DAOs while still simplifying verification of blessed SNSs for the end-users.

More modular SNS
We agree that SNSs should be as modular as possible, so that self-deployed SNSs can interchange different parts easily.
For example, the governance canister is already implemented in a separate canister so that a community could take the SNS code and replace just the governance canister with an alternative implementation that realizes a different voting scheme.
Similarly, it was also an intentional decision to implement the initial token swap in a separate canister. This allows to add alternative initial funding options later, both in the blessed SNS path and for self-deployed SNSs.

Continue to encourage the development of dapps
We agree that we have to think about future funding rounds. In the spirit of iterative progress, we are working on a design to ensure that the initial SNS is forward compatible with future sale rounds. This would allow us to add future sales / swaps by upgrading the SNS later and for example implement the future sales in yet another canister.

For regular payments, one solution would be to have a SNS ledger account controlled by a canister that makes the payments based on some logic. The community could then review the canister and approve a proposal that moves some portion of the treasury to the ledger account controlled by this canister. This is, of course, just one of many possibilities. It will be interesting to see what the different SNSs require and continuously improve the canisters to account for these needs.

The release of SNS Token
To avoid “rug pulls” we were starting down the route of hard coding safeguards around what is considered a “fair” decentralization and “secure” initial parameters for a swap. The original idea was that having neurons with a non-zero dissolve delay might have some advantages in that tokens cannot immediately be liquidated if something went wrong. We now noticed that it might indeed be a better approach to start with few constraints and let the community (via the NNS proposal) decide what constitutes good sale parameters. We can of course also continuously change the constraints for the initial parameters as we evolve the code.

I hope that this could clarify some of our intentions and ideas.
Again, I thank everyone for taking the time to express your feedback and concerns and wish you a great weekend!

5 Likes

I love the different opinions and feedback views which improves my understanding but I have my own opinions as well.

There seems to be 2 different views here:
The concerns seem to me more about lousy project ideas and the cost to the SNS reputation if not successful, not the technology or design.

But I have to provide a view of mine about community governance.

When I first set up my NNS and joined the forum for direction and knowledge I was confronted by the community in the governance forum calling me names for following and their attempts to take away my rewards and told that as they vote and I was just a follower I didn’t deserve the rewards I was given. The outcome was a change to the NNS that every 6 months I will be unfollowed and have to re-follow or lose rewards therefore giving my invested rewards to name callers.

So I started to login regularly from feeling bad about being just a follower and found something about voting and governance.

I have become a name caller as I call myself a Bystander.

I feel that the only proposals I have voted on are a scam ##-test that I could receive extra rewards on but now I believe we all receive them anyway so the only voting left is team updates that I can just follow anyway.

So just to reiterate I am a BYSTANDER and don’t feel valued as NNS community member but don’t get me wrong I am happy that I have IC locked away for 8 years and while the price is down I still have all my coins and more, this price drop is not a concern for me.

I am just saying that ideas and project types, good ones are few and far between and I hope the reputation doesn’t tarnish the SNS

I myself put up a proposal in the forum for an add on to the NNS that I felt was important but no feedback or interest. I would like to see Bystanders create proposals and ideas for the NNS.

So I feel from the information and concerns here I will attempt a proposal idea for the SNS and don’t expect much, just maybe name calling or ignored so I will not be disappointed.

We should have a weighing system on every project so if you join a high risk project then you must understand that it is high risk. Risk in my opinion is determined by type.

Bread and butter types like Distrikt as mention here is a bread and butter investment which can take on the top tech companies built on web2 and having poor reputations that Distrikt can market on as a better alternative but I don’t like their idea on marketing to young professionals and itself name calling and restrictive.

Then there was the other mention of collapsed ideas that were higher risk or maybe unknown or tested that would have a heavy weighting.

The final point is that the SNS is an idea in my opinion to increase traffic and projects built on the ICP which is what we all want.

The tech is already built.
The bread and butter projects are known.
If unknown or untested then high risk.

Let’s not be bystanders and just support and protect, let create ideas for all our success.

I would like to think I was a shareholder of the future top tech on ICP

2 Likes

Jesus Chris this dope baby sh*t is eventually gonna come to us. Now I feel easier to defend against ETH people why ICP updated canister makes sense for being assets. :smiling_face_with_tear:

Can’t the majority of holders of an SNS just put a proposal to drain the treasury. We have seen this done with SNS-1. Also can’t they just change the delay at that point, or is the delay set to the point that even SNS majority cannot change?

I think the problem with this is that a liquid treasury can be drained when the founding team controls the SNS. I have seen several projects now have essentially the keys to the bank, the only thing that stops them isn’t anything technical but social, maybe also the NNS.

Hi @cyberowl,
first I just want to note that this is a rather old thread and a lot has happened in the meantime on the SNS design. You can find the latest SNS design and description in the SNS developer documentation.

I will still try to answer your questions in the current context.

Can’t the majority of holders of an SNS just put a proposal to drain the treasury. We have seen this done with SNS-1.

During the SNS launch, SNS governance does not allow any treasury transfers.
As soon as the SNS is fully launched, and the swap participants received their tokens, if the majority of the SNS community adopts such a proposal, they can indeed make any treasury transfers. If the SNS is sufficiently decentralised, then this decisions should not be up to a few parties. But whether or not the decentralisation is given has to be evaluated for each SNS.

Also can’t they just change the delay at that point, or is the delay set to the point that even SNS majority cannot change?

I am not fully sure what you mean by “delay”, maybe you want to elaborate?
In general, the SNS community can change the governance rules by changing the so called Nervous System Parameters. You can find a list of all these parameters here.
They can however not upgrade the governance to arbitrary wasms - all wasms are pre-approved by the NNS (see here).

1 Like

Srry I meant dissolve time.

So the treasury is liquid ICP correct. However, the founding team + CF + Community is issued Neurons with some dissolve time. One question is can’ t the majority DAO / proposal modify that to be 0. It seems like you can here: Managing nervous system parameters | Internet Computer.

Another question is even if they can’t, if they have a small dissolve period say a month they can sell out and then acquire tokens from some exchange. Set the neurons to be max dissolve and completely change the voting power of the DAO. This is if of course a handful of people own similar amount of tokens as CF and Community shares. Specially if the handful of people own more than CF and Community.

I meant dissolve time.

Thanks for confirming!

One question is can’ t the majority DAO / proposal modify that to be 0.

An SNS’s voters can change how the dissolve delay affects the voting power (by changing the two fields
max_dissolve_delay_seconds and max_dissolve_delay_bonus_percentage, but they cannot change the individual neurons’ dissolve delay.

Another question is even if they can’t, if they have a small dissolve period say a month they can sell out and then acquire tokens from some exchange. Set the neurons to be max dissolve and completely change the voting power of the DAO. This is if of course a handful of people own similar amount of tokens as CF and Community shares. Specially if the handful of people own more than CF and Community.

Correct. This is why it is recommended to consider the initial token distribution between NF (former CF), developer neurons, and direct sale participants when participating in an SNS.
Note that initial developer neurons can also have a “vesting period”: this means that they have a certain vesting period in which it is neither possible to dissolve them nor to increase their dissolve delay. For example a developer neuron can have a dissolve delay of 1 month (to make sure that the voting power is not too high) but a vesting period period of 1 year: this will mean that in this year the neuron’s dissolve delay cannot be increased to gain more voting power and it can also not decrease to liquidate the token. This can be used as a measure against some of the concerns that you raised.

2 Likes

Looking at the sns-testing repo but can’t find the schema for this vesting period. What field would that be based on the example given:

      developer_neurons:
        - controller: aaaaa-aa
          stake_e8s: 1500000000
          memo: 0
          dissolve_delay_seconds: 15780000 # 6 months

NVM I think I found it vesting_period_seconds

1 Like