- We present an overview of proposed improvements for critical SNS proposals, such as treasury proposals.
- We provide more details on how to implement the removal of following for critical proposals.
The community shared a lot of feedback and ideas on how to improve SNS treasury proposals. We thank everyone who contributed to this discussion! In this post, we want to summarize some considered improvements regarding SNS treasury proposals and other critical SNS proposals. Some of the improvements related to this topic were discussed some time ago and are already being worked on, while others were recently proposed, including for example by community members in this post.
While it is important to have in-depth discussions for all individual topics, it is also important to consider the larger context. Therefore, we want to share an overview of all improvements that are considered first. In addition, we then present one proposed improvement in more detail.
Many of the proposed improvements may not only be valuable for treasury proposals but more generally for critical SNS proposals. We therefore first explain what we mean by critical proposals.
Many of the current discussions focus on SNS treasury proposals. We propose that some improvements are applied more broadly to the following three types of SNS proposals that can be considered to be critical SNS proposals:
Transfer_sns_treasury_fundsproposals: These proposals allow an SNS to move ICP or SNS tokens from the SNS’s treasury to a given account.
Why are they critical? Treasury proposals are considered critical because they can move SNS-owned funds to any account.
Mint_sns_tokensproposals (name tbd): This type of proposal will allow the SNS to mint new SNS tokens. Note that this proposal type does not exist yet, but is being developed as shared here.
Why are they critical? Minting proposals are considered critical because minting new tokens can drastically change the full SNS DAO tokenomics.
Deregister_dapp_canistersproposals: These proposals allow an SNS to give up control over a dapp canister and hand it back to a (centralized) controller.
Why are they critical? These proposals are considered critical since dapp canisters can hold valuable assets, for instance ckBTC tokens. In these cases, handing over control of the dapp to a centralized party means giving this party full control over the dapp-controlled funds.
We next provide an overview of all improvements regarding critical proposals that are currently being worked on. This list may change with time, as we think about the design more and gather more feedback from the community.
- Increase the required threshold for all critical proposals: Critical proposals are only adopted if 50% of the available voting power votes in favor of the proposal. This also implies that such proposals can only be adopted if at least 50% of the voting power participated in the voting, as opposed to other proposals where 3% yes-votes and simple majority are sufficient to adopt a proposal.
Status & more details: This improvement was presented to the community in this and this forum post and, since it received positive feedback, we started working on it.
- Remove following for critical proposals: Completely remove the following mechanisms for critical proposals. This means that all voters have to directly vote on such proposals.
Status & more details: This is a new design and the details are shared in the next section. Depending on the community feedback, we will take up working on this.
- Limit SNS treasury proposals: Limit the amount of tokens that can be moved by SNS treasury proposals. This might, for example, be a limit of how many ICP and SNS tokens can be moved out of the SNS treasury per week or month.
Status & more details: This is a new idea. We will share a more concrete design proposal in the coming weeks, which will then be discussed with the community.
We now provide more details for the proposed Improvement 2) Remove following for critical proposals. High level idea is that there is no following for critical proposals and all SNS neurons have to directly vote on such proposals.
We propose to remove following from all critical proposals, that is from SNS proposals with type
Deregister_dapp_canisters proposals. As explained in the previous section, all these proposal types affect SNS funds or tokenomics in some way that can be viewed as critical, which motivates requiring more active votes to make such critical decisions.
For some proposals it may be important to have following for adopting time-sensitive proposals quickly, for example if bugs need to be fixed urgently. However, usually proposals to move funds or hand over control do not fall in this category. Therefore it seems OK that the critical proposals might take a bit longer to be adopted after this change.
Since there should be no following on critical proposals, the following on these proposal types will be removed from all neurons. This can be done, for example, by looping through all neurons and doing this cleanup in an SNS governance canister upgrade.
More technical details: Looping through all neurons can be done in the post_upgrade method that is executed when the SNS governance canister is upgraded to a new version. For each neuron, the current following settings for the critical proposals can then be removed. In addition, the SNS governance canister has a reverse index from followees to followers, which can also be cleaned up in the same way.
A change to the neuron’s method for following another neuron on a proposal type would ensure that going forward neurons cannot follow other neurons on critical proposal types.
If this proposed change is adopted, SNS neuron holders have to directly vote on treasury, minting and on de-reginster dapp proposals. If they do not directly vote, no vote will be cast for them and they might miss out on voting rewards.
In addition, if one user has multiple neurons in the same SNS, they have to directly vote with each of the neurons on critical proposals (as it is not possible anymore that some of the user’s neurons follow one of their other neurons). Luckily, this last part can be simplified by appropriate frontend design. For example, on the NNS frontend dapp it is already now possible for a user to select all neurons with which they want to directly vote on a proposal - so voting with all neurons would not be an additional effort.
Without following, some proposals might take longer to be adopted. Moreover, it might be harder to get enough votes to adopt a critical proposal, especially after the Improvement 1) Increase the required threshold for all critical proposals.
This means that SNS participants who submit a critical proposal might have to spend more time and effort in promoting their proposals, making other SNS users aware of them, and convincing SNS users that the proposal is necessary and well thought-out.
We are looking forward to your feedback regarding the removal of following and also the bigger context of other planned improvements.
We will keep you posted with progress on the increased threshold and also get back to you once we have a more concrete proposal on how to limit treasury proposals effectively.