How-To: Make your own decisions on SNS Treasury Proposals

[lara]

TL;DR We explain how SNS neurons can follow themselves on SNS treasury transfer proposals if they would like to avoid automatically supporting treasury proposals and instead make their own decisons.

Dear SNS communities,

Recently, in some SNSs, a substantial amount of ICP was moved out of the treasury with proposals that were adopted within a short period of time. This raised some concerns in the community. The quick adoption of the proposals was likely supported by the fact that many SNS neurons “follow” the neurons of the original dapp developers (more information on following below).

While we are looking into optimizations to the SNS treasury proposal design, it is already possible for individual SNS participants to disable following on SNS treasury proposals. In this post, we will recall how following works and how SNS governance participants can change their following if they wish to directly vote on treasury proposals rather than automatically supporting them.

Background - How SNS following works

In SNSs, each neuron can either directly vote on proposals or delegate their voting power to another neuron by following it. In SNSs, following is based on proposal topics.

For example, if Alice has a neuron in an SNS called TYKEH, she can choose to follow Bob’s neuron for the proposal topic Motion. As soon as Bob votes with his neuron on a motion proposal, Alice’s vote would automatically be cast too.

Following on All topics

Apart from following on individual proposal topics, neurons can also choose to follow on All Topics. If Alice chooses to follow Bob on All Topics, then whenever Bob votes on any topic where Alice has no explicit following set, Alice’s vote will also be cast.

For example, if Alice follows Charlie’s neuron on the proposal topic Motion and Bob’s neuron on All Topics, then

• Scenario A. If Bob votes on topic Motion, this has no effect on Alice’s vote, because Alice is following Charlie on motion proposals.
• Scenario B. If Bob votes on any other proposal topic, a vote will automatically be cast for Alice.

The difference between Alice following Bob on All Topics and Alice individually following Bob on each of the topics is that if a new proposal topic is added to an SNS, then this would automatically be covered in the former case but not in the latter.

How to disable following only on SNS treasury proposals

Many SNS neurons might decide to follow particular neurons that they trust, such as the original dapp developers’ neuron, on All Topics to ensure that they do not miss any rewards. This means that they also follow them on SNS treasury decisions — topic Transfer SNS treasury funds.

If this is undesired, SNS neurons can follow themselves on the topic Transfer SNS treasury funds. This avoids unintentionally following treasury decisions via the All Topics-following. These SNS neurons can then manually vote on treasury proposals. For all remaining topics, they would still have following set as before.

Following yourself on the NNS frontend dapp

We illustrate how this can be done on the NNS fronted dapp. We use an example SNS instance called TYKEH, where a neuron follows another neuron on All Topics and now decides to directly vote on treasury proposals.

1. On the My Neuron Staking page, choose the SNS. Then, choose a neuron. Then, you can find the neuron’s ID in the top right corner. Click the copy icon next to the ID to copy your neuron ID.
   
   
2. Go to “Follow Neuron” and find the topic “Transfer SNS treasury funds”. Click “Add Followee”.
   
   
3. Paste your neuron ID that you copied in Step 1 to the field “Followee’s Neuron Id”. Then, click “Follow Neuron”.
   
   
4. As a result, the neuron follows itself for Transfer SNS treasury funds and still the originally followed neuron for all other topics. This is now visible on the neuron’s page:
   
   

From now the neuron follows its trusted neuron on all topics except for Transfer SNS treasury funds, where has to directly vote.

Outlook

We wanted to share the above information as soon as possible so each SNS participant has all the required information to set following according to their intentions. In addition, as shared in a separate forum thread, we have proposed to increase the required thresholds of yes-votes for SNS treasury-related and other critical SNS proposals. Moreover, we collected additional ideas from the community, for example shared here, and are also thinking about additional improvements to the design of SNS treasury proposals. We will be sharing more of our thoughts on this topic in the coming week.

[wpb]

@lara

SNS neurons can follow themselves on the topic Transfer SNS treasury funds. This avoids unintentionally following treasury decisions via the All Topics-following. These SNS neurons can then manually vote on treasury proposals. For all remaining topics, they would still have following set as before.

This is brilliant. Thanks for sharing. Does it work for the NNS as well?

@lara

For example, if Alice follows Charlie’s neuron on the proposal topic Motion and Bob’s neuron on All Topics, then

• Scenario A. If Bob votes on topic Motion, this has no effect on Alice’s vote, because Alice is following Charlie on motion proposals.
• Scenario B. If Bob votes on any other proposal topic, a vote will automatically be cast for Alice.

The difference between Alice following Bob on All Topics and Alice individually following Bob on each of the topics is that if a new proposal topic is added to an SNS, then this would automatically be covered in the former case but not in the latter.

If you add a Scenario C then you can explicitly point out that the Followee selection for All Topics is not a backup for the Followee you select for individual topics.

Scenario C: If Charlie does not vote on topic Motion, and Alice does not vote manually on topic Motion, then Alice does not vote and does not earn voting rewards.

This might be helpful information to some people to know that they need to do their due diligence to seek neurons who are committed to voting on the individual topic they are configuring. vpgeek.app is now offering this service for the NNS and I hope they start offering this service to SNS in the future.

@lara

On the My Neuron Staking page, choose the SNS. Then, choose a neuron. Then, you can find the neuron’s ID in the top right corner. Click the copy icon next to the ID to copy your neuron ID.

You might want to change the screen capture for the first step in your instructions. The text indicates that you copy the neuron ID, which is off page in the screen capture. You can only see the neuron account in the current image in step 1 or your OP.

This seems like a good idea that hopefully the SNS team can also consider…

@skilesare

Blackholed and/or DAO Horizoned canisters should be able to hold neurons. This does not seem like a difficult feature to add given that a new proposal type mirroring named neuron could be added that stores whitelisted canisters at an address and at https://github.com/dfinity/ic/blob/e89564adda6ca8588f29780d9dfd7b8512e19f8c/rs/nns/governance/src/governance.rs#L2037 you could update to.

   if !neuron.controller.unwrap().is_self_authenticating() and !canister_whitelist.contains(neruon.controller))  {

You could even auto-add SNS-controlled canisters to the whitelist without a proposal by verifying that they were only controlled by the SNS.

[lara]

Thanks for the constructive feedback @wpb !

Does it work for the NNS as well?

Yes it should as following works the same.
Note though that one difference is that on the NNS a few topics (e.g., Governance and SNS-related topics) are already excluded from the “All topics”, which is called “All topics except for …” instead.

If you add a Scenario C

Thanks for adding this. I agree that this makes sense and indeed this might add further clarity!

This seems like a good idea that hopefully the SNS team can also consider…

Indeed. We will need to prioritise all ideas, but this is something on our radar - thanks!

[jwarner]

@Apollon

Maybe instead of creating lazy investors and users, we should focus on creating credible systems. Currently the flow is

1. NNS controls SNS
2. SNS Controls the Dapp and the treasury
3. Founders set the tokenomics parameters and voting powers
4. Investors invest funds without relevant information available in the Launchpad user interface
5. When an SNS is launched, the neurons do not follow anyone and is easy to exploit. There is absolutely no information about founders and delegates with their respective voting powers.
6. It takes zero effort to drain the treasury with pre-rigged launch.

3. Founders set the tokenomics parameters and voting powers: My understanding is founders do not set voting power. Your voting power is directly correlated to the amount you choose to invest. The more you invest, the more you control, that’s not something specific to the SNS. That’s just how participating in early projects works. The more money you put in, the more say you have in the decision making. If 10 people put in the majority of the money, and they do something you disagree with, too bad, they have more to lose than you do so they have more weight.

4. Investors invest funds without relevant information available in the Launchpad user interface: If someone invests funds without relevant information, that’s entirely their prerogative. If someone gets an email saying they’ll receive one million dollars at some point in the future if they send one thousand dollars to an address, and they send that thousand dollars without doing any research, they can’t blame the email protocol, email app, and internet service provider for lack of “protection”. At some point, the person sending the money has to take responsibility for their actions. If it was fraud or theft, they can report it to the local authorities and take legal action. If they don’t have the relevant information, they shouldn’t participate in an SNS.

It is not Dfinity’s responsibility to make sure investors do their due diligence. They can provide tools to do so, but if people decide not to use those tools because they’re difficult, again that’s they’re prerogative.

5. When an SNS is launched, the neurons do not follow anyone and is easy to exploit.: How is it easy to exploit if the neurons aren’t following anyone? If you change it to “Default following of Founder Neurons after the launch”, then you give all of the voting power directly to the founding members which contradicts your other suggestions.

I’m assuming you think if no one is following neurons, they won’t vote, which makes it easier for bad actors to create proposals to drain funds by just having a majority vote? But if you have default following, that just gives the founders majority voting power immediately. If people don’t want to vote, that’s their decision, but they can’t complain about the results either.

In BoomDAO’s case, I believe they were able to distribute treasury funds because they had followers who allocated them the voting power along with their own voting power. So this essentially functioned exactly how you’re saying it should function. They had a lot of followers who followed them from the beginning. On top of that, you know exactly who they are and who was responsible. I’m not seeing a broken system or infrastructure here, just decision making.

6. It takes zero effort to drain the treasury with pre-rigged launch.: It should be easy to get access to treasury funds so development and proposals can get funded through voting and the project can progress. If you don’t trust the founders and other voting members to handle your investment well, then you shouldn’t participate.

@Apollon

Its such a mess.

I disagree.

@Apollon

The launchpad and dashboard still do not display the Amount raised from Neuron Funds

There is no information on treasury contents and tokenomics in the UI

Instead you ask us to manually go through several painstaking process

I think there are improvements that can be made, and I think Dfinity is aware of this. As far as it being “painstaking”, no one said due diligence using an emerging technology would be easy.

@Apollon

We focus on shipping useful features, not just forum posts.

You used the word “we” which implies you’re doing work with or for the ICP community or Dfinity. What have you shipped or are you working on that addresses your concerns? Have you submitted proposals for voting? Are you validating releases? Running/hosting any dapps? Contribute to the wiki? Anything that would lend more weight and credibility to your criticisms?

@Apollon

Labels for Neurons on dashboard and chain to identify Founders and Representatives of the DAO and delegated voting design, that is the basis of dPOS on ICP.

Anyone can create a named neuron right now. If the founders don’t want to name their neurons, and that makes you nervous, don’t support the project. I don’t think naming neurons should be mandatory, but it would definitely go a long way in creating trust between founders and participants.

@Apollon

Default following of Founder Neurons after the launch, so users know whom to hold accountable for questionable proposals. Since they have raised funds and are developing, it makes sense to follow them by default and then decentralize progressively.

100% disagree here. Default following of anything just allows participants to blame someone else when things don’t go their way.

@Apollon

Create and set appropriate threshold for Treasury proposals, which cannot be exploited by Founder/Team neurons.

I don’t disagree here, but there’s a balance that would have to be found that wouldn’t stifle innovation.

@Apollon

Display all the relevant and available information on both NNS Front end and DFINITY maintained ICA Dashboard.

I agree there could be improvements. I think it would be helpful if you got more specific on what information you feel is “relevant”.

@Apollon

Please don’t undermine the information channels with noise. We already have seen a lot over the last few weeks. Last thing we need is principal designers of SNS to take sides and mislead investors further downplaying this disaster of these 51% attacks.

This post wasn’t noise, in my opinion. I don’t see anyone taking sides or anyone misleading anybody. Thank you @lara for the writeup.

[lara]

I would like to focus my answer on your main question “why is this shared now?”.

No matter how great a DAO (or any governance system) is designed and implemented, users can always blindly follow the decisions of a few (centralised) parties, for example by just voting as they say. Therefore, I think that a truly decentralized governance system, not only requires a great design, but also empowered end-user who can 1) make good decisions and 2) know how to express their opinion to participate in the governance. This requires, as you also state, making information more readily available to users. In addition, this requires educating end-users so they understand how participation works and what their different options are to express their opinion.

So we have three ingredients:

1. Improving the design - as mentioned above, we agree with this and are working on it, also taking into account the ideas shared by different community members.
2. Improving the information / accessibility to it - we agree with this and are actually also already working on how we can improve this by potential additions to the NNS frontend dapp and the dashboard.
3. Ensuring that users understand how to participate in governance effectively - this forum post was covering one aspect of this.

[wpb]

Hey @lara and @jwarner. Thank you for taking the time to reply to comments in this post today. Your thoughts and opinions were very insightful. However, each of you faced highly disrespectful reaction from someone who has been around the ICP ecosystem a long time who frequently gets banned and opens new accounts under new identities. His behavior is very disappointing to a lot of people who value intellectually honest discourse on the forum. It is unfortunate that you were shown so much disrespect after simply expressing your opinion on this important topic. Please know that his opinion does not represent the majority of people who read this thread. Keep up the good work. Your contributions are highly valued.

[jwarner]

How did I take it out of context?

Of course I support censorship in certain situations.

No user of the forum has a “right” to be heard. Dfinity owns it and can do what they want when they want. From what I see, they are pretty lenient.

@Artemi5

You call this debate? Censoring a party with help of DFINITY’s Biased Moderators and then pushing your own information?

I didn’t say anything about this being a debate or not, and this thread isn’t about censoring, debating, or biased moderators. I addressed some concerns referencing the initial post, and asked questions. If I get some answers and can have a constructive discussion, great, if not, no big deal to me.

I have more important things to do than engage in unproductive discussions here. When I see an individual becomes unreasonable or doesn’t address my questions, I move on. Which, if Apollon was banned, I’ll be moving on now.

[jwarner]

Just for reference, that’s me flagging your posts as off topic.

This thread is titled “How-To: Make your own decisions on SNS Treasury Proposals.” Since your posts have nothing to do with the topic, I flagged them in hopes they’ll be deleted so when someone else comes along, or conducts a search, they can see information directly related to the original topic. It’s not about your content or concerns, it’s where you’re placing them. In my opinion, this thread is not the place for it, and I flagged it as such (off topic). They can feel free to delete this post as well to keep the thread informative.

[ckMood]

@jwarner

I agree there could be improvements. I think it would be helpful if you got more specific on what information you feel is “relevant”.

What I’ve been doing when I decide to vote on a proposal is use ChatGPT. Here is what I prompt it with:

"This code is from a proposal titled “Assign Node Operator ID (NOID)”:

{
“ipv6”: null,
“node_operator_principal_id”: “xbvdm-vrdwg-wcvpo-dwsdp-akpmo-sresk-53cg5-mwpn3-adhco-rwzym-gqe”,
“node_allowance”: 1,
“rewardable_nodes”: ,
“node_provider_principal_id”: “3oqw6-vmpk2-mlwlx-52z5x-e3p7u-fjlcw-yxc34-lf2zq-6ub2f-v63hk-lae”,
“dc_id”: “li1”
}

What does this code do and what does it mean in the greater context of the IC?"

This is the response: "The provided JSON object is part of a proposal titled “Assign Node Operator ID (NOID)” within the context of the Internet Computer (IC). Let’s break down the key components:

1. "ipv6": null: This field appears to be the specification for the IPv6 address associated with the node. In this case, it is set to null, indicating that there is no specific IPv6 address provided or that IPv6 is not relevant for this proposal.

2. "node_operator_principal_id": "xbvdm-vrdwg-wcvpo-dwsdp-akpmo-sresk-53cg5-mwpn3-adhco-rwzym-gqe": This is the unique identifier assigned to the node operator. Each node operator in the IC network is identified by a principal ID, and this ID uniquely identifies the entity responsible for operating the node.

3. "node_allowance": 1: This field specifies the allowance or the number of nodes that the operator is allowed to run. In this case, the operator is allowed to run one node.

4. "rewardable_nodes": []: This array is currently empty, indicating that there are no specific nodes listed for rewards in this proposal. It might be relevant in the context of reward distribution based on node performance or other criteria.

5. "node_provider_principal_id": "3oqw6-vmpk2-mlwlx-52z5x-e3p7u-fjlcw-yxc34-lf2zq-6ub2f-v63hk-lae": This is the principal ID associated with the node provider. The node provider is the entity that provides the physical or virtual resources for running the node.

6. "dc_id": "li1": This field specifies the data center identifier. Each node is associated with a specific data center, and this identifier helps in organizing and managing nodes within the broader network infrastructure.

Meaning in the Greater Context of the IC:

1. Node Operator and Provider Identification: The proposal is assigning a Node Operator ID (NOID) and Node Provider ID to a particular node. This is crucial for tracking and managing the responsibilities of different entities within the IC network.

2. Allowance and Resource Allocation: The “node_allowance” field indicates the number of nodes that the operator is allowed to run. This is part of the broader governance and resource allocation mechanisms within the IC, ensuring fair distribution and utilization of network resources.

3. Reward Mechanism: The presence of the “rewardable_nodes” array suggests that the proposal may be related to rewarding node operators based on their performance or other criteria. However, in this specific proposal, the array is empty, indicating that there are no specific nodes listed for rewards.

4. Data Center Assignment: The “dc_id” field associates the node with a specific data center. This is important for managing the geographic distribution of nodes and ensuring redundancy and fault tolerance in the network.

In summary, this proposal is about assigning identification, allowances, and provider information to a node operator within the Internet Computer network. It plays a role in the governance, resource allocation, and operational aspects of the decentralized infrastructure."

This is very useful when it comes to making an informed decision. If every proposal had this info or integrated an AI response like this. It would greatly empower individual voters to make more informed decisions and not blindly follow neurons to do voting for them.