SNS Topics Plan

[Andre-Popovitch]

Hi all,

DFINITY has begun working on the SNS Topics feature. Here is a more concrete plan we would like to put forward for the community.

Problem

SNS users are able to cast votes on more proposals than they can manually track by following other neurons’ voting decisions. This maximizes their voting rewards and potential impact on the SNS community. However, setting up neuron following is currently too complicated, as a separate decision is required for each individual proposal type; some SNSs already have dozens of custom proposal types, and counting. The screenshot below illustrates the problem.

Goal

The goal is to improve how users can choose whom to follow by enabling topic-based following. Instead of having to set this up based on individual proposal types, we propose SNSs to group all their proposals into 7 clearly specified topics, as proposed in Lara’s post.

Plan

For brevity, we refer to neuron following based on proposal types as legacy following. The scope of this proposal is to introduce topic-based following and deprecate legacy following.

Recall that there are native and custom proposal types (the latter used to be called generic functions). Examples of the former include UpgradeSnsControlledCanister, TransferSnsTreasuryFunds, Motion. Custom proposals are specific to each SNS.

To simplify understanding the severity of proposals within each topic, each of the 7 introduced topics will be marked either as critical or non-critical. There will be two critical topics: Treasury & asset management and Critical dapp operations. Proposals under a critical topic will have to meet stricter requirements before being approved, which enhances security for potentially dangerous operations, e.g., TransferSnsTreasuryFunds will be under the critical topic Treasury & asset management. An example of a non-critical topic is the Governance topic which will include, e.g., proposals of type Motion.

While each native proposal type will have the same topic in each SNS, each SNS community will define the topics of their custom functions.

We propose to deliver this feature in four milestones, as outlined below.

1. Each native proposal has a topic

Frontends may start grouping proposals into topics to aid users.

• Native proposals are assigned topics (same for all SNSs)
  • Some topics are marked as critical.

While adding a new custom proposal type, a topic for that type will need to be specified. Functions that have already been added will be listed as “uncategorized.”

The neuron following will not yet be affected.

Heads-up for SNS frontends. After this milestone, frontends will be able to use topics to enhance the user interface, specifically, for the neuron following page.

2. Each custom proposal has a topic

A new SNS proposal type will be added, SetTopicsForCustomProposals, so that an SNS community can efficiently define the topics of all of its existing custom proposal types.

If a proposal type is under a critical topic, the proposals of that type will be critical.

Custom proposal types that do not yet have a topic will remain non-critical (this is the current behavior for all custom proposals).

3. Requirement of custom functions to be categorized

Users can set topic-based following for their neurons. If a neuron has topic-based following and legacy following, topic-based following is preferred; otherwise, legacy following will still have effect.

Proposals without topics can no longer be submitted until their topic is defined.

Heads-up for SNS frontends. After this milestone, frontends may support setting new topic-based following. For SNSs that did not yet upgrade to have topic-based following (if any), legacy following must still be supported.

4. Following on individual proposal types is deprecated

Users will be able to set up topic-based neuron following.

Users will no longer be able to modify legacy following. Existing following settings will not be changed as part of this plan, so users who are already happy with their (legacy) following settings will not need to take any action.

Heads-up for SNS frontends. After this milestone, frontends must support editing topic-based following. For SNSs that did not yet upgrade to have topic-based following (if any), legacy following must still be supported.

Summary and next steps

We think that this new design will radically simplify the onboarding process for new SNS community members. Currently, most users need to take dozens of actions for each individual proposal type. Our proposed design will help users make fewer, more informed decisions that do not require the knowledge about each proposal type. and reduce the number of decisions while making them more purposeful

As we make progress towards each milestone, we will communicate more details about it in this thread. In the meantime, please let us know if you have any questions regarding the plan.

[wpb]

@Andre-Popovitch

we propose SNSs to group all their proposals into 7 clearly specified topics, as proposed in Lara’s post.

There are a couple new proposal types that were not in @lara’s list according to the dashboard. I made assumptions about where they would be placed. Will you please verify that I have categorized them into topics correctly? I’d like to make sure I understand how they will be grouped.

1. DAO community settings (non-critical)

• Manage nervous system parameters
• Manage ledger parameters
• Manage SNS metadata

2. Treasury & asset management (critical)

• Transfer SNS treasury funds
• Mint SNS tokens

3. SNS framework management (non-critical)

• Upgrade SNS to next version
• Advance SNS Target Version

4. dApp management (non-critical)

• Upgrade SNS controlled canisters
• Manage dapp canister settings
• Register dapp canisters

5. dApp operations (critical)

• Deregister dapp canisters
• Add generic nervous system function
• Remove generic nervous system function
• Execute generic nervous system function

6. Application business logic (non-critical)

• none

7. Governance (non-critical)

• Motion

@Andre-Popovitch

To simplify understanding the severity of proposals within each topic, each of the 7 introduced topics will be marked either as critical or non-critical. There will be two critical topics: Treasury & asset management and Critical dapp operations.

I’m really glad to know that topics will be explicitly marked as critical or non-critical. This is currently very confusing and it sounds like this change will help make it more readily apparent.

I strongly recommend that the DAO Community Settings topic should also be critical. It is very easy for the dev team to push changes that have profound impact on the SNS community without the community having sufficient input or time to respond. Examples of proposals that had this effect are listed below for two SNS projects that I follow. Most of these proposals were a net positive for the respective SNS, but list illustrates that there are many examples of big changes that were not discussed publicly in advance and most people were following others before they realized the implications of the proposed change. Some of these changes in the ALICE SNS happened almost instantly when the dev voted due to follow patterns in the very early stages of the SNS. I think it would be much better to hold changes like this to higher standards by making them critical.

Manage Ledger Parameters
Alice proposal 9 - transaction fee increase

Manage Nervous System Parameters
WaterNeuron proposal 602 - limit neuron controllers
WaterNeuron proposal 1654 - increase reward rate, max age bonus, and max dissolve delay bonus
WaterNeuron proposal 2084 - increase max dissolve delay
Alice proposal 2 - decrease max age bonus
Alice proposal 5 - decrease max dissolve delay, increase max age bonus
Alice proposal 6 - increase max dissolve delay
Alice proposal 16 - decrease proposal reject fee

[aterga]

Thanks for the good feedback, @wpb!

@wpb

• Execute generic nervous system function

This seems like the only case that’s different:

(The facts below apply to SNSs that already upgraded to the latest version of SNS Governance from https://dashboard.internetcomputer.org/proposal/135315)

• Existing custom proposal types (a.k.a. generic nervous system functions) are currently uncategorized.
• Currently, an SNS can define a topic by de-registering a custom proposal type and registering it again, during which it’s now possible to specify the topic.
  • Will are going to support a more convenient way to set topics for existing proposal types in the 2nd milestone.

I strongly recommend that the DAO Community Settings topic should also be critical.

Thank you for making this point. We’ll discuss this internally and I’ll get back to you with in the following weeks. For now, please note that SNS proposal criticality remains unchanged, as defined here.

[wpb]

@aterga

(The facts below apply to SNSs that already upgraded to the latest version of SNS Governance from https://dashboard.internetcomputer.org/proposal/135315)

So does this mean that proposal Topics are now live for SNSs that have upgraded? When will the NNS dApp be upgraded to surface these topics and allow people to set Followees based on Topic instead of based on Type? This proposal has just executed within the last 24 hours, so it is brand new. I didn’t realize this change would be implemented so quickly. This is exciting.

One other change to SNS default configuration that would be helpful is to set all neurons to follow the eldest neuron (the one with max dissolve delay) on all non-critical topics AND on all critical topics instead of just on all non-critical topics. That way people only need to set Followees on one neuron when they receive their new neurons after an SNS launch. The complexity of SNS neuron configuration is mostly that you have to set an explicit Followee for all critical topics for every neuron.

@aterga

@wpb

• Execute generic nervous system function

This seems like the only case that’s different:

Advance SNS Target Version is also different from @lara’s list. Do I have that one categorized correctly above?

@aterga

Existing custom proposal types (a.k.a. generic nervous system functions) are currently uncategorized.

Does this mean that the current Add/Remove/Execute Generic Nervous System Function proposal types are not going to be categorized in the dApp Operations proposal topic? I need further clarification on this statement. I do understand that the nervous system functions that an SNS creates (e.g. “Vote on NNS Proposal” in the WaterNeuron SNS) will also be categorized in to topics and that each SNS can define if those functions are slotted into a critical or not critical topic. I’m more interested in whether the act of creating, removing, and executing them, since those are the existing SNS types that apply to all SNS projects as part of the SNS framework, are going to be critical or non-critical and which topic they will be categorized. It seems like they will be dApp Operations based on @lara’s post, but I just want to make sure I am understanding it correctly. Maybe you already answered and I don’t realize it, so I think I need a bit more clarification.

Perhaps you are just saying that the Execute Generic Nervous System Function proposal type will go away because executing the function created by the SNS is a separate custom proposal type. I guess I don’t really understand why there is a proposal type called Execute Generic Nervous System Function. In cases like WaterNeuron and OpenChat, once the function is created (e.g. “Vote on NNS Proposal”) it gets it’s own name and is identified separately already in both the NNS dApp and on the dashboard. Executing the function occurs through the SNS specific type instead of through the Execute Generic Nervous System Function type as far as I know.

@aterga

Currently, an SNS can define a topic by de-registering a custom proposal type and registering it again, during which it’s now possible to specify the topic.

• Will are going to support a more convenient way to set topics for existing proposal types in the 2nd milestone.

@Andre-Popovitch

A new SNS proposal type will be added, SetTopicsForCustomProposals

It seems like this new proposal type called SetTopicsForCustomProposals should also be critical. Is that a correct assumption? I am imagining that these custom proposal types could be in control of a treasury or a neuron, so defining the criticality of the proposal type seems pretty important.

[Andre-Popovitch]

@wpb

So does this mean that proposal Topics are now live for SNSs that have upgraded? When will the NNS dApp be upgraded to surface these topics and allow people to set Followees based on Topic instead of based on Type?

I want to note that while custom proposals can now be categorized into topics, setting topic followees is not yet supported by SNSes. This makes topics a cosmetic feature today, but hopefully in the near future this will be supported and topics will be fully-functional.

@wpb

• Execute generic nervous system function

This proposal type doesn’t need a topic because its topic will be decided by the topic of the generic nervous system function being executed.

@wpb

In cases like WaterNeuron and OpenChat, once the function is created (e.g. “Vote on NNS Proposal”) it gets it’s own name and is identified separately already in both the NNS dApp and on the dashboard.

It’s not obvious from looking at the dashboard, but these are all secretly ExecuteGenericNervousSystemFunction proposals. Inside the proposal is a field that specifies which custom function is to be executed, and then frontends typically choose to render them using the custom function’s name and description.

[Andre-Popovitch]

@wpb

3. SNS framework management (non-critical)

• Upgrade SNS to next version
• Advance SNS Target Version

Nice observation, you’re right that Advance SNS Target Version belongs under “SNS framework management” and that’s indeed where it currently is under the version of the SNS approved on Monday.

[aterga]

@wpb

I strongly recommend that the DAO Community Settings topic should also be critical.

We discussed this internally, agreeing that this is a meaningful suggestion. However, we think it should be discussed (and potentially implemented) separately from the core changes announced in this thread. Since this would change the existing behavior, some SNS communities might contest if it’s worth doing, therefore I recommend the interested parties to raise this question in a new forum thread and be ready to submit a motion proposal in case there will be voices against it.

[aterga]

Please note the upcoming changes in SNS proposal criticality:

PSA(SNS): Proposal criticality to be defined based on proposal topics

This is a quick public service announcement for those involved in making and voting on SNS proposals. TL;DR. We propose to extend the list of critical proposal types will be extended with Add nervous system function and Remove nervous system function, with ETA = Monday, March 17, 2025. Background. What are critical proposals? Currently, some proposal types are marked as critical, so proposal of those types requiring a larger voting threshold and longer voting period compared with non-critical …

[aterga]

With https://dashboard.internetcomputer.org/proposal/135615 being adopted, it is now possible to map your custom SNS proposals to topics in one go, using a SetTopicsForCustomProposals proposal. To illustrate, here’s an example DFX command that you can already use (assuming your SNS is on the latest version):

dfx canister --ic call ${SNS_GOVERNANCE_CANISTER_ID} manage_neuron '(
    record {
        subaccount = blob "'${PROPOSER_SNS_NEURON_SUBACCOUNT}'";
        command = opt variant {
            MakeProposal = record {
                url = "https://forum.dfinity.org/t/sns-topics-plan";
                title = "Set topics for custom SNS proposals";
                action = opt variant {
                    SetTopicsForCustomProposals = record {
                        custom_function_id_to_topic = vec {
                            record {
                                1001 : nat64;
                                variant { ApplicationBusinessLogic };
                            };
                            record {
                                1002 : nat64;
                                variant { DaoCommunitySettings };
                            };
                        };
                    }
                };
                summary = "Set topics ApplicationBusinessLogic and \
                        DaoCommunitySettings for SNS proposals with \
                        IDs 1001 and 1002 resp.";
            }
        };
    },
)'

This way, it’s already possible to specify custom proposals under the two critical topics (Critical dapp operations and Treasury & asset management), but note that all custom SNS proposals (regardless of their topic) will remain de-facto non-critical until this plan is implemented: PSA(SNS): Proposal criticality to be defined based on proposal topics (ETA=March 17, 2025).

We encourage the SNS communities to use SetTopicsForCustomProposals to set topics for all custom proposals. This way, your SNS will be ready for the 3rd milestone, in which it will no longe be possible to submit custom SNS proposals that don’t have a topic (ETA=March 24, 2025).

[Dustin]

We just sent a proposal to update the topic of a proposal but now proposals cannot be viewed in the NNS FE dApp for Gold DAO anymore. (NNS Dapp). The page is no longer loading but is working perfectly well for other SNSs and it throws the error There was an unexpected issue while searching for the proposals.

If you check the proposals, #203 is the one which sets the topic for a specific function of the Gold DAO. https://dashboard.internetcomputer.org/canister/tr3th-kiaaa-aaaaq-aab6q-cai

Looks like it also broke dev.ic-toolkits.app

Will there be a fix for the NNS FE dApp coming? @chepreghy

[yhabib]

Hi @Dustin, thank you for reporting this.
We are currently investigating the issue and will update you here once it is resolved.

[Dustin]

Thank you. It seems to also affect some other views of Gold DAO on the NNS dApp and gives the impression that cycles are low which is not the case (they are at roughly 100 TC)

[yhabib]

Hi @Dustin,
We’ve identified the issue and are working on a fix. We will present a new proposal for the nns-dapp on Monday.

[wpb]

Thank you for getting this announcement out quickly.

[Lorimer]

Hi @yhabib,

Are you able to confirm that this isn’t an issue with the SNS version (one that would make it worth holding off an upgrade for the timebeing for those that have not opted into automatic upgrades)?

Thanks

[wpb]

More specifically @yhabib, the WaterNeuron SNS is currently voting on a proposal 2477 to Advance SNS Target Version. Is there any reason that we should reject that proposal based on the issue that you discovered for GoldDAO on the NNS dApp front end?

I have GoldDAO neurons and was able to see them in the NNS dApp and spawn maturity. I was also able to see the open GoldDAO proposals in OpenChat and vote on them successfully. Hence, the problem appears to be solely with rendering GoldDAO proposals in the NNS dApp. I would be curious if the problem comes from recent execution of GoldDAO proposals 199 and 200, which made changes to the GLDT ledger indexer and the GLDT ledger archive canisters including making adjustments to stable memory.

[yhabib]

Hi @Lorimer and @wpb,

The issue lies in deserializing the payload of the proposal. This is a front-end issue. We will upgrade ic-js, which should resolve it for the nns-dapp and other clients of the library.

[Dustin]

Thank you for handling this fast! @yhabib

[Dustin]

@yhabib do you have an ETA for this fix today? Could you post here once it’s out?

[yhabib]

Hi @Dustin
We’ve released a new version of ic-js.
This afternoon, we will submit a proposal to upgrade the nns-dapp, which will include the new version of ic-js. I’ll share it here as soon as it is published.

Pd: We have submitted the proposal
Pd2: The nns-dapp has been upgraded, and the issue has been fixed. You can find the post about the upgrade here.