Improvements for SNS treasury and other critical proposals & removal of following

Governance SNS Project Governance
,
1

TL;DR

  • 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.

Introduction

Hi all,

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.

What are critical SNS 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_funds proposals: 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_tokens proposals (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_canisters proposals: 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.

Overview of proposed improvements

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.

  1. 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.
  2. 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.
  3. 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.

Disable following for critical proposals

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.

Which proposals will this affect and why?

We propose to remove following from all critical proposals, that is from SNS proposals with type Transfer_sns_treasury_funds, Mint_sns_tokens, and 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.

What will happen to the existing following on critical proposals?

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.

What does this mean for following on critical proposals going forward?

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.

What does this mean for SNS voters?

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.

How will this affect SNS communities?

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.

Outlook

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.

Happy weekend!

17 Likes
2

It may be quite hard to reach 50% without following even if everyone who sees the proposal votes to adopt it.

How about if the critical proposals require a 2/3 majority and a minimum of ~20% approval?

So if a proposal reaches 2/3 then it is executed immediately, else it runs until the deadline and at that point it will be executed only if the adopt votes are at least double the reject votes.

In the proposed scenario, a proposal could have 49.9% approval and no reject votes but it still wouldn’t pass.

7 Likes
3

Hey @hpeebles, thanks for the feedback!

  • In your proposal, would you remove following and then, because this might make reaching 50% harder, just lower the required thresholds of the proposed measure 1) to what you propose?

  • I think your proposal can be understood in two parts: a) what it takes for a proposal to be immediately executed and b) what it takes to be executed by the end of the voting period.

For a), I don’t fully understand:

So if a proposal reaches 2/3 then it is executed immediately, else it runs until the deadline and at that point it will be executed only if the adopt votes are at least double the reject votes.

Why would it not be good enough to still execute immediately at 50%? Because with 50% even if you wait until the end, there is no way for the result to be turned anymore, right? Would you just say that for treasury proposals it should deliberatly be an even higher agreement that is required?
With a higher than 50% threshold my concern is a little that this changes quite some details in the code (where currently it is assume that at 50% the result is fixed).

For b), as I understand you you propose that if a proposal reaches the deadline, it would be executed with 20% yes-vote-participation and a 2/3 no-to-yes ration. Right?
I wonder if this idea could be combined with keeping the 50% for immediate execution. Or do you think this would be too confusing?

3 Likes
4

@icpmaximalist wondered if you had any feedback

5 Likes
5

I think these proposals are a step in the right direction but don’t fully address the problem. As I understand it, even after these proposals a bad actor could simply acquire 50.01% of a DAO’s tokens and distribute all of their assets to herself. The lack of minority protections for token holders effectively means that a particular DAO’s token becomes totally worthless as soon as somebody acquires a majority stake in the DAO.

I don’t know what the solution is. But based on the framework you proposed, one potential solution would be to base the threshold vote for “critical” proposals on what percentage of voters vote against it. In other words, the voting power needed to pass a “critical” proposal could change based on the voting power that has voted against it.

What I just proposed is only a kernel of an idea. But hopefully it sparks some thought into how we can protect minority token holders.

5 Likes
6

Hey @lara,

I’m having a difficult time seeing how proposed improvements #1 and/or #2 won’t end up bricking the treasury for a lot of SNSs, especially if the token swap results in a significant decentralized distribution of tokens. It just doesn’t seem like an SNS would be able to generate enough engagement for voting on the critical proposals under these conditions. Is there any reason to believe that any of the current SNSs have achieved greater than 50% manual voting participation on any of their proposals? Is it possible to collect that kind of data to verify? If you do move forward with proposed changes #1 and #2, then can you also extend the voting period?

It seems like the best way to prevent a SNS team from moving a large fraction of the treasury at one time is to limit the amount of the treasury that can be transferred over a given timeframe and to remove the critical proposal topics from the All Topics catch all category. Removing these critical proposal topics from the All Topics catch all would not require any NNS executed changes to SNS neuron configuration. All it would be doing is removing default following for those proposal topics. This approach would also enable people to actively set a Followee for these topics if they wish to have a Followee instead of always forcing them to vote manually with each of their individual neurons.

8 Likes
7

Currently all proposals are adopted if by the time they hit their deadline they have more adopt votes than reject votes and at least 3% adopt votes.
The fact that they execute immediately once they reach 50% adopt votes is solely because that is the point at which they are guaranteed to be adopted by the time they hit their deadline.

My suggestion is to instead require 2/3 adopt votes rather than 50%, and 20% minimum rather than 3%.
So if 51% vote to adopt and 49% vote to reject then the proposal would be rejected, which I think seems reasonable for these critical proposals.

Also, I think having no following is probably a bad idea, everyone who took part in SNS sales will have multiple neurons which all follow the one with the longest dissolve delay, so up until now many people will have only been voting via hotkeys with that single neuron. If we remove following they’ll have to do lots of manual work to vote with all of their neurons.

I think we should still allow explicit following on these topics but that they shouldn’t be included when following on ‘all topics’.

5 Likes
8

Developing an algorithm for point 3 appears to be complicated. Perhaps we should consider enforcing a voting period, such as 7 days, for transfer proposals? This approach seems simpler than adjusting the thresholds and disabling following. @lara

Also, it would be nice to have different voting periods for different types of proposals in the future.

3 Likes
9

Thanks Lara,

This is a very important topic and I am grateful that Dfinity is addressing this issue.

My personal opinion is that I would focus only on two changes:

  • limiting the absolute amount of treasury transfer. (20% of initial SNS sale, so it would require 5 approved proposals to fully empty treasury)
  • remove follow on critical topics.

I would not pursue the first one, as it might be too little or too much on different SNSs. And the other 2 seem to be enough to stop bad behaviour.

Although this is good, I think the root problem lies on the fact that there aren’t alternative Known Neurons.

We desperately need the NNS code of Known Neurons, to exist on SNS. Hopefully after that more known neurons will appear and voters will have more options to choose from. I would put this “known neuron parity” as top priority, along the other two.

In future SNS swaps, would recommend for Dfinity (and community) to demand 2 to 3 known neurons from start. So that any voter will at least have them on the NNS dApp to choose from.

This for sure will significantly improve the decentralization and robustness of our SNSs.

Hope this is helpful :pray:

4 Likes
10

Hello @lara,

Thank you for creating the thread:

  • Governance Consistency: If we begin to disable auto-following for special topics on the SNS will the same rules be applied to the NNS? There should be consistency between the NNS and SNS otherwise this appears like Dfinity strong arming projects.

  • Voting Threshold Concerns: I’m worried the 50% voting threshold could be too high without auto-follow. Larger stakeholders might not vote often. This could stop SNS projects from working well.

  • Autonomy in Following: I think we should respect that people chose to follow certain neurons. Maybe we could do a one-time reset of follows instead? That way people can opt-in again for important votes. It balances engagement and choice.

  • Treasury limits - we need flexibility for different projects. Can the proposals accommodate changing budgets? If this is to become similar to Dfinity grant process where teams require approval what was the point of the SNS in the first place? More clarity on what Dfinity is thinking here would be helpful.

3 Likes
11

Thanks for the feedback @wpb,

fully agree that it might be a risk that #1 and #2 make it harder for critical proposals to get passed.
I think here it depends on what the community thinks whether this has more advantages than disadvantages.

Is there any reason to believe that any of the current SNSs have achieved greater than 50% manual voting participation on any of their proposals? Is it possible to collect that kind of data to verify?

While I understand the concern here, let me also propose a possible counter-argument. I wonder if this is the right question to ask / analyse as it might be that up until now the SNS communities just never had to try to reach a large base of their voters. I think one can argue that this is also a downside of following that proposers sometimes might have to try less hard to really reach the community and promote their ideas. Of course it might change the dynamics of a DAO if this is needed - now decisions are made within days and with such a change it might take weeks to mobilise voters. But I think one could argue that this can also be beneficial for a DAO.
So I think maybe as a community we also have reflect on whether we think this would be a good direction to go (of course we could still do the analysis you asked in addition).

If you do move forward with proposed changes #1 and #2, then can you also extend the voting period?

I think this is a good idea! Even if one can promote and mobilise voters before the proposal is sent, it might be easier to achieve more active participation if voters have more time to cast their vote.

Thanks, as a summary I understand you propose to lower the bar of measure 2 a bit and just remove the critical proposals from the catch-all “all topics” rather than fully removing following for them.

3 Likes
12

Thanks for these clarifications @hpeebles , I think I understand now!

I think having no following is probably a bad idea, everyone who took part in SNS sales will have multiple neurons which all follow the one with the longest dissolve delay, so up until now many people will have only been voting via hotkeys with that single neuron.

Note that this can be solved to some extent on the different frontends, as argued above. For example, on the NNS FE dapp, once can select all neurons with which one wants to vote. Of course, this might require changes to other frontends or setting new hotkeys, but this work might possibly be a one-off rather than making the voter’s life harder for all proposals going forward.

Thanks for your suggestions!

2 Likes
13

Hi @Seers , thanks for the feedback.

Developing an algorithm for point 3 appears to be complicated

Could you elaborate on why you think this is hard?
I haven’t fully thought about the design, but I think the governance canister could just remember how many treasury transfers already happened in a given time period and when a new treasury proposal is submitted it can check whether this is still allowed with the given limits. Do you have concerns with this approach?

Also, it would be nice to have different voting periods for different types of proposals in the future.

I think it would be possible to consider different voting periods for different proposals. This is also the case in the NNS. I see two potential drawbacks with this:

  1. This makes the SNS code a bit harder (as now the governance canister has to keep track for each proposal in which category it falls and consider them in the right places)
  2. I wonder if an increase in the voting period is enough for treasury proposals if the goal is to have a larger voter base agree to those: for example if many voters don’t regularly check the proposals, it might still be easy to get treasury proposals through with little participation. Some of the other proposals encourage that more voters have to explicitly agree.
3 Likes
14

Thanks for the feedback!

Agree that the known neurons are also a good idea - this is on our list too!
I think here the challenge might be that first there have to be experts on different SNSs that are as independent as possible from the original developer team (otherwise it does not help much for decentralisation to have multiple known neurons).

So while I agree that it can help to include this in the governance system, I also think more than that is needed for 1) building known neurons and 2) ensuring that SNS participants don’t just blindly select known neurons they see integrated in the system, but still make informed decisions on who would best represent their opinion in a DAO.

2 Likes
15

Thanks for the feedback and questions!

will the same rules be applied to the NNS? There should be consistency between the NNS and SNS otherwise this appears like Dfinity strong arming projects.

This is not currently planned, but it is conceivable that the community also decides to require different thresholds for some NNS proposals going forward.
Note that while the governance system, with neurons and proposals, are similar in SNS and NNS, the code is not the same and there are already multiple differences betweeen the two governance systems.

Thanks for the additional inputs on Voting Threshold Concerns & Autonomy in Following.

Can the proposals accommodate changing budgets?

Note that changing treasury size could be taken into account, for example, by limiting how much can be moved from the treasury as a % of what is still in the treasury.

If this is to become similar to Dfinity grant process where teams require approval what was the point of the SNS in the first place?

Note that the main idea of these measures is to ensure that treasury proposals are carried by a majority of the decentralised SNS community. So anyone who would like to propose that funds should be sent from the treasury to some account would have to make sure that they convince sufficent SNS DAO members. In my view this is in line with the main idea of DAOs.

2 Likes
16

A couple of basic questions(pardon the simplicity of the questions as I’m sure the answers are in the docs, but I think elevating the answers will help others).

  1. Where are treasury funds actually held? Are they held in a subaccount in one of the SNS System canisters? Or are they held in a canister that the SNS is a controller of(like a cycle wallet for the SNS Instance).

1b. If the answer to 1 is not “SNS System Canister” what is to keep the SNS from passing an upgrade to the treasury canister that changes the code to have an endpoint that gives full control over the funds(I’m guessing/hoping the answer is actually “SNS System Canister”).

  1. Will SNSs ever be able to set the ‘minting account?’ Some tokenomics setups require the minting of new tokens in a more systematic way than having a vote. If you can change the minting account, is the new type even necessary? Can you just put an open-sourced, DAO-controlled canister as the minting account and then the DAO can update that to whatever they want?

Surrounding both of these is the fact that if the DAO still only needs 3% and followers are turned on then an upgrade canister proposal could always get around these measures. There is value in normalizing the desired flow, but if the other means still persists in some form it would be good to state so.

4 Likes
17

Happy to answer these questions!

Where are treasury funds actually held? Are they held in a subaccount in one of the SNS System canisters?

They are held in the respective ledger canister. Concretely:

  • The ICP tokens in the treasury are stored on the ICP ledger in an account whose controller is the SNS governance canister
  • The SNS tokens in the treasury are stored on the SNS ledger in an account whose controller is the SNS governance canister.
  • The minting account is also an account on the SNS ledger that is controlled by the SNS governance canister.

The ICP ledger cannot be upgraded by the SNS. The SNS ledger can only be upgraded according to the upgrade path that was pre-approved by the NNS. Therefore, I think the SNS DAO cannot circumvent rules by canister upgrades.
I agree that in general it is very important to consider if some “measures” can just be avoided by doing the same over other proposals, but I think this is not the case here.

Will SNSs ever be able to set the ‘minting account?’

In the current setting, the minting account is always the SNS governance canister. This is needed if new tokens should be minted for voting rewards as can be done now. Of course other designs are possible, but it might require a clearer design proposal to discuss the concrete pros and cons. Indeed in such a case, your argument should then be taken into account: that if different thresholds should hold for minting proposals, then it must be carefully considered if they make sense with this new design too.

2 Likes
19

Could you elaborate on why you think this is hard?
I haven’t fully thought about the design, but I think the governance canister could just remember how many treasury transfers already happened in a given time period and when a new treasury proposal is submitted it can check whether this is still allowed with the given limits. Do you have concerns with this approach?

Essentially, I believe that restricting DAOs to a certain percentage of the treasury is a strong opinion to implement in code. For example, if we set the limit at 10%, it may be adequate in some cases (like with a 1M ICP treasury in HOT) but insufficient in others (like with a 20K ICP treasury in Ghost). It seems that many small DAOs could be unduly constrained by this rule.

[For context, several DAOs have already withdrawn about 100K ICP (including Catalyze, Modclub, and Sonic). Meanwhile, Ghost DAO withdrew their entire treasury of 20K ICP to provide liquidity.]

If we decide to enforce this policy, it might be necessary to also establish minimum and maximum thresholds for the governance token—not just percentages—and perhaps consider the real-time fiat value. I’m concerned that this may lead to additional complications in the future.

  1. This makes the SNS code a bit harder (as now the governance canister has to keep track for each proposal in which category it falls and consider them in the right places)

I’m not familiar with the code, but I think it can be done easy by adding the new data on each proposal type.

  1. I wonder if an increase in the voting period is enough for treasury proposals if the goal is to have a larger voter base agree to those: for example if many voters don’t regularly check the proposals, it might still be easy to get treasury proposals through with little participation. Some of the other proposals encourage that more voters have to explicitly agree.

Considering that the NNS also operates under liquid democracy and taking into account the similar debates we’ve had previously, we likely wouldn’t want to go down that road (disabling following).

I’ve read a wide range of criticisms over the past weeks, and I believe most could have been avoided if there had been a set voting period that included the chance to reject the proposal and voice an opinion, even if the ultimate outcome remains unchanged. Such a provision would still be consistent with the principles of a liquid democracy.

3 Likes
20

Thanks @Seers! I see, your concern is less about the technical implementation of the thresholds, but rather about whether this would be appropriate for all SNSs and how this would affect further complications going forward.

Thanks for taking the time to elaborate on this - I think I understand your points much better now!

2 Likes
21

Hi @lara ,

Will the percent limit on withdrawing from the treasury be on the amount remaining in the treasury or on the amount initially raised? If the former then would the treasury never be able to completely withdrawn?

Also instead of a limit are there any other solutions you explored? Would it be possible to hold the funds in escrow for some time limit after a SNS transfer proposal is accepted and then a secondary vote, without following could occur that could cancel the original transfer.

3 Likes