SNS topics - design

Governance SNS Project Governance
,
1

TL;DR

We propose to

  • Introduce proposal topics in the SNS and have vote-following based on topics.
  • Have a fixed set of proposal topics to cover both built-in proposals as well as custom proposals.
  • Define some topics as critical, which makes all proposals in that topic critical.

We are looking for feedback to the overall design (not yet the precise choices of topics).

Background

Those familiar with how SNS proposals currently work may want to skip this section.

The SNS is a framework that allows dapps to be put under DAO control. The SNS DAO functionality is maintained and changes are approved by the NNS. Nevertheless individual SNS DAOs can customize their DAO, for example by choosing settings that define tokenomics and voting parameters.

Built-in and custom proposals

There are two kinds of proposals:

  • Built-in proposals (also native proposals) are proposals that are built into the SNS framework and available in every SNS. This includes proposals to update the SNS DAO itself or the parameters of the SNS.
  • Custom proposals (also called generic proposals) are proposals that allow an SNS DAO community to flexibly define what kinds of decisions the DAO can make. To do so, the SNS community can register (and later deregister) custom proposals. Depending on the governed dapp, a DAO might need proposals to moderate parts of the dapp or to make very specific business decisions, such as which users are rewarded in which way.

Critical proposals

Some of the proposals are critical. In contrast to non-critical proposals, critical proposals require a larger voting threshold and a longer voting period. They also have different rules for following (see next).
Currently, only a number of fixed built-in proposals are critical.

Vote following (aka liquid democracy)

Since voters might not have time and knowledge to vote directly on all proposals, they can delegate their vote and “follow” other neurons.
Following can be set per proposal type.
For non-critical proposals, one can also use the “catch-all” - this specifies a fallback following option for proposal types that don’t have any explicit following set.

Problem statement

There are two main challenges with the current design.

  1. Setting following on SNSs is currently cumbersome. A user can either set following for each individual proposal type, which is very fine grained as some SNSs have 100 different proposal types, or they can set the catch-all which is very coarse grained.
  2. Only built-in proposals can be critical. Some SNS DAOs expressed the need to make some custom proposals critical as the associated decisions are substantial.

Proposed design

On a high level we propose the following to address these issues.

  1. Similar to the NNS, facilitate following based on proposal topics that bundle multiple proposals of a similar kind.
  2. Built-in and custom proposals can be in the same topic.
  3. Topics can be critical, which means all proposals assigned to the topic are critical.

Detailed design

The more detailed design must define which of these concepts are defined as part of the SNS framework, and thus the same for all SNSs, and which of them are customizable and defined by each SNS DAO. We propose the following.

  • The SNS framework defines a set of built-in proposals
  • The SNS framework defines a fixed set of proposal topics
  • Each built-in proposal is assigned to a single topic
  • Each SNS DAO defines and registers custom proposals
  • Each SNS DAO defines for each custom proposal to which topic it belongs
    • Custom and built-in proposals can be in the same topic
  • The SNS framework defines which topics are critical
    • All proposals assigned to a critical topic are critical

Examples

To make the design more tangible, let’s look at two possible example topics. We describe for each topic what it is about, and which built-in and custom proposals could fall in the topic. Note that the latter would be up to each SNS community.

  • Topic Treasury & asset management: Proposals to move assets that are DAO-owned, including tokens in the treasury, in liquidity pools, or in DAO-owned neurons.
    • Built-in proposals
      • Transfer SNS treasury funds
      • Mint SNS tokens
    • Possible custom proposals: Staking and managing DAO-owned NNS neurons or neurons in other SNSs (WaterNeuron), manage treasuries such as ckBTC, ckUSD etc.
    • Criticality: Critical.
  • Topic Dapp management: Proposals to manage the governed dapp canisters, including dapp upgrades via built-in or custom logic and updates to frontend assets.
    • Built-in proposals
      • Upgrade SNS controlled canister
      • Manage dapp canister settings
    • Possible custom proposals: Custom upgrades, reinstalls, frontend asset management (asset canister), management such as backup, monitor, setting timers.

Out of scope

Note that the design does not change the definition of the “catch-all” following. We propose to keep the current rules that this is a fallback only to non-critical proposals with no other following choice. We don’t exclude rethinking this concept, but propose to do so in a separate discussion.

Considered Alternatives

  • Alternative: We could require that each topic either contains built-in or custom proposals but never proposals of both kinds.
    Why the current design was preferred: From a community point of view similar themes can be covered in built-in and custom proposals. As illustrated by the example, upgrades of the dapp can be done by the built-in proposal to upgrade a SNS-controlled dapp canister or require custom code implemented in custom proposals, for example if a lot of canisters are involved. From the user’s point of view it makes sense to trust the same people to verify the associated changes and code as the same knowledge and skill is required, even if the code path taken “in the DAO” may be different.
  • Alternative: Rather than taking fixed proposal topics, allow each SNS to create custom topics.
    Why the current design was preferred:
    • Many SNSs have similar concepts but might call them differently - having a fixed set of topics helps making the similarities visible.
    • Having the same topics in all SNSs helps users understand new SNS DAOs.
    • Users can build expertise for certain topics and then become established experts that can be followed on these topics in different SNS DAOs. This may make it more attractive for users to invest in building this expertise.
  • Alternative: Rather than using topics, like in the NNS, where every proposal type is associated with one proposal topic, one could have tags and each proposal could have multiple tags. This would allow expressing that a given proposal is associated with different concerns (e.g. it changes the tokenomics but also the voting rules or similar).
    Why the current design was preferred:
    • Reusing a concept that is already established in the NNS has the advantage that this is already familiar to users and experts who can be followed.
    • It is unclear how following would work on a per-tag basis. If a proposal can have multiple tags and following is set per tag, it is unclear what kind of following would be applied for a proposal that has multiple tags where the following rules do not match.

Next steps

We are looking for feedback for the design, including what is defined in the SNS framework and what is customizable. The proposed topics should for now be taken as an example. If the community agrees with this approach, we propose to discuss the concrete proposal topics that are distinguished in a next step.

We know that SNS topics are one of the most requested features and are looking forward to your feedback!

4 Likes
2

We are looking forward to this functionality for OpenChat. We have many custom proposal types and setting up following per proposal type is too cumbersome.

This proposal sounds good in general. My only concern is having a fixed set of topics. If you post this fixed set here that might alleviate my concern - perhaps all of our (current) proposal types will fit neatly into this fixed set.

Alternatively there is a set of standard built-in topics but then each SNS can choose to have supplemental custom topics (perhaps added by critical proposal).

1 Like
3

In this follow-up post we propose concrete topics to start with.

Hi all, since there were no strong objections to the above approach, let’s next discuss which proposal topics there should be for the SNSs.

Proposed topics

We propose the following SNS proposal topics. For each topic, we describe what it is about, which built-in proposals fall in the topic, and which kind of custom proposals could fall in the topic. The assignment of custom proposals to topics would be up to each SNS community.

  1. Topic DAO community settings: Proposals to set the direction of the DAO by tokenomics & branding, such as the name and description, token name etc.

    • Built-in proposals
      • Manage nervous system parameters
      • Manage ledger parameters
      • Manage SNS metadata
    • Examples of possible custom proposals: Custom rewards implementation, custom burning of tokens.
    • Non-critical. Reason: already non-critical now.

  2. Topic Treasury & asset management: Proposals to move and manage assets that are DAO-owned, including tokens in the treasury, tokens in liquidity pools, or DAO-owned neurons.

    • Built-in proposals
      • Transfer SNS treasury funds
      • Mint SNS tokens
    • Examples of possible custom proposals: Staking and managing DAO-owned NNS neurons or neurons in other SNSs (WaterNeuron), manage treasuries such as ckBTC, ckUSD, manage contributions to liquidity pools on DEXs.
    • CRITICAL. Reason: already critical now. These are high risk proposals that can affect a lot of value.

  3. Topic SNS framework management: Proposals to upgrade and manage the SNS DAO framework.

    • Built-in proposals
    • Examples of possible custom proposals: probably none.
    • Non-critical. Reason: the NNS already pre-approved these changes.

  4. Topic Dapp management: Proposals to upgrade the registered dapp canisters and dapp upgrades via built-in or custom logic and updates to frontend assets.

    • Built-in proposals
      • Upgrade SNS controlled canisters
      • Manage dapp canister settings
      • Register dapp canisters
    • Examples of possible custom proposals: Custom upgrades, reinstalls, frontend asset management (asset canister), management such as backup, monitor, setting timers.
    • Non-critical. Reason: As is.

  5. Topic Critical dapp operations: Proposals to manage critical operations. This includes adding and removing nervous system functions and may include custom upgrades of dapp canisters that are considered to be high risk (e.g., hold valuable assets).

    • Built-in proposals included:
      • Deregister dapp canisters
      • Add nervous system function
      • Remove nervous system function
      • (Future?) May be extended to include upgrades of dapp canisters that should be considered critical. We propose to discuss this in a future discussion.
    • Examples of possible custom proposals: For canisters that hold valuable assets: upgrades, reinstalls, frontend asset management (asset canister), management such as backup, monitor, setting timers.
    • CRITICAL. Reason: Deregistering of dapp canisters is critical as now. Adding / removing custom proposals is critical as otherwise this could be a way to circumvent going through a higher-threshold voting to achieve certain things. This topic may also be used by DAOs that want some of the upgrade and management of their dapps to be treated as a critical proposal.

  6. Topic Application business logic: Proposals that are custom to what the governed dapp requires.

    • Built-in proposals included: none
    • Examples of possible custom proposals: everything that is custom to the logic of the dapp and not covered by a more specific topic above.
    • Non-critical.

  7. Topic Governance: Proposals that represent community polls or other forms of community opinion but don’t have any immediate effect in terms of code changes.

    • Built-in proposals:
      • Motion
    • Examples of possible custom proposals: Other forms of testing / polling community opinions, electing certain roles, e.g., for moderators in a dapp that have special permissions.
    • Non-critical.

Next steps

We are looking forward to your feedback. Since there are quite a few aspects that can be discussed, let me name a few and maybe feedback can be grouped accordingly to simplify the discussion.

  1. Selection of topics: Is the current selection of topics too little / too much?
  2. Names of selected topics: Even if you agree with the selected topics and their content, maybe you have a proposal for better names?
  3. Assignment of built-in proposals to topics: Does the assignment of built-in proposal types to the topics make sense?

Thanks all and have a great day!

4 Likes
4

Thank you @lara. This sounds like a great approach. Here are a few suggestions…

  1. Governance Motion proposals should not be included in the All Non-Critical Topics catch all. Most people follow the dev team and often even the best dev teams vote immediately after submitting a proposal. This gives the community no time to vote manually. Neuron owners should at least be required to explicitly follow someone on this topic.
  2. Manage Nervous System Parameters should be a Critical proposal. Major changes can be implemented without any discussion with the community and without adequate description in the proposal. When the dev team votes early, it gives their followers no chance to vote manually. An example is WaterNeuron proposal 602.
  3. It is very cumbersome to set Followees for the Critical proposals. Please create an All Critical Proposals catch all category.
  4. the NNS dApp should clearly identify all critical proposal topics and outline how they are different than non-critical proposals.
5

The selection of topics, their names and the assignment of built-in proposals to topics all look good to me.

1 Like
6

thanks for the feedback!
Would love to hear what others think on 1 & 2. One concern I have for proposal 1 is that it is already rather hard for new voters to understand the catch-all. Critical proposals are yet another concept. So I think it would be easier if the catch-all just applies to all non-critical proposals as then it is one concept less that people have to understand (it is just on set of voting rules for critical and one set of rules for non-critical proposals and the catch-all can be renamed a s such).

It is very cumbersome to set Followees for the Critical proposals. Please create an All Critical Proposals catch all category.

Note that with this new proposal there would only be 2 topics that are critical and following would now be set on a topic basis.
Again I wonder if it is more helping or confusing if we introduce another “level” which is overarching different topics. IMH if it is just about 2/3 topics it can makse sense to keep them separate as the work is manageable but we may have more the effect that people make good and distinct decisions for the different topics.

the NNS dApp should clearly identify all critical proposal topics and outline how they are different than non-critical proposals.

thanks for the feedback. We are already thinking about how to make setting following easier on the NNS dapp. I would though not attach this to this feature but rather the initiative where we improve following on the FE as I think this belongs more to the user story of how we can improve this (what is already there as well as the new features)