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:
- 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.
- 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!