Defining deprecated SNSs

Governance SNS Project Governance
,
1

Dear SNS community,

The Governance team would like to propose a standard definition for deprecated SNSs that could be useful for many SNS frontends and tools. Conceptually, a deprecated SNS is an SNS that did not have any transactions or proposals for a significant amount of time.

Why is this a useful definition? There’s currently no proper cleanup process for SNSs that are no longer needed. In particular, the NNS dapp cannot easily filter those SNSs out while listing all SNS projects. As a result, e.g., the ---- SNS is still being listed among projects that are actually interesting for new DAO members, which is especially confusing for new users. Ideally, the frontends should be able to list just the active (i.e., non-deprecated) SNS projects that are still attracting new members.

Proposed definition. For a precise definition, we need to agree on the following:

  • Which transactions indicate that the SNS is still relevant to the users?
    • Submitted proposals.
    • SNS ledger transactions.
  • What is a reasonable period of inactivity before an SNS would be considered deprecated?
    • Two months.
(num_submitted_proposals_past_2_months == 0 &&
 num_ledger_transactions_past_2_months == 0) ==> "Deprecated"

Recovery options. A deprecated SNS can become non-deprecated again just by executing at least one transaction (submitting proposals or transferring SNS tokens). Conversely, the frontends would not be required to maintain dynamic lists of deprecated SNSs; they could apply the standard filtering conditions and observe, in real time, which projects are currently deprecated. Assuming this definition is used by the most prominent frontends, users would observe the same information about which SNS projects are active, across different websites and tools.

Next steps. We’d like to hear your concerns and suggestions regarding how to define that an SNS is deprecated. Once we converge to a practical definition, it would become easier to improve and unify the frontends, and I’m looking forward to cooperating with their respective developers to make it work.

4 Likes
2

You might also want to consider this, as some DAOs are incorporated in the Marshall Islands:
Dissolution | MIDAO Docs. It looks like dissolution can be done with a 2/3 vote or as specified in the governing documents.

Regarding the questions:

Which transactions indicate that the SNS is still relevant to the users?

I believe the best indicator is the number of approved proposals. Most ledger transactions are just bot activity, and the number of submitted proposals alone isn’t a reliable measure.

What is a reasonable period of inactivity before an SNS would be considered deprecated?

A reasonable threshold could be 1–2 years, or perhaps a function of the maximum lock period.

1 Like
3

Hi Arshavir,

This is very interesting… :slight_smile:

I think this design is still too simplistic and lots of more work ironing out is needed.

Several questions raise up:

  • What if a DAO wants to self declare “deprecated”?
  • What if there are bots / arbitrage trading the SNS tokens, won’t it make it never “deprecated”, while the core team / token holders are not interested in it anymore, not making any proposals, etc.?
  • What happens to the treasury when a DAO becomes “deprecated”?
  • What if canisters stop having “cycles” being paid. Especially the governance canister that is “burning” a lot while active. Won’t this be a better signal that the SNS is not “useful / needed” enough for any token holder (and thus deprecated)?

Maybe the SNSs could have a somewhat similar “classification” / “process” as canisters:

  • A canister that is not being topped up, becomes “frozen”, until recovered.
  • It can stay in that state for a long time, but eventually will be “deleted/destroyed”.
  • There is no way to recover a destroyed canister, same to an SNS, eventually reaching that state will be irrecoverable. All proposals archive, all transactions archive will be destroyed as well.

The same way a Dev can destroy a canister and get back it’s cycles, a DAO should be able to self declare a termination and recover back all of it’s assets. (or refuse to terminate while Assets are still in control).

Maybe something in this direction could be more “familiar” to the core teams and IC token holders.

The dashboard would not show the “frozen” ones, unless someone selected on the filter (same as the not successful launches for example).

What do you and the community think? :slight_smile:

Hope this helps :folded_hands:

5 Likes
4

This is definitely something worth implementing, but as @tiago89 pointed out, there are many factors to consider. In the case of the Cycles Transfer Station, @aterga’s approach would work well—they refunded contributors and then effectively prevented a takeover or activity by setting extremely high rejection and transfer fees.

image
image2878×996 194 KB

The issue of unused projects also came to mind for Toolkit. One idea I had was that if an SNS remains deprecated for a year, control could revert to the NNS, allowing the community to decide its fate. Whether that means reactivating or removing the SNS, it would at least create opportunities for further discussion and action.

4 Likes
5

Personally, I like the control reverting to the NNS concept. It flags that something is inactive and encourages the community as a whole to decide what happens. Funds remaining in the treasury could either be returned to the original contributors, or if the project is reactivated, maybe the community could set targets that the SNS needs to meet to be able to access the treasury funds. Something that could encourage the SNS to fulfil its original aims and prevents funds being drained to benefit individuals.

1 Like
6

Hi @marcio

Thanks for pointing out the fact that different DAOs operate in different jurisdictions which might have special rules for how a DAO registered there should be operated.

Note that in this thread, we proposed a definition for deprecated (not dissolved) DAOs, as observed from various frontend websites and SNS tools. The key difference is the active and irreversible nature of dissolution, while deprecation happens naturally, e.g., if users lose interest, but it does not necessarily entail any permanent change. Deprecation isn’t caused by an operation that the DAO performs.

I believe the best indicator is the number of approved proposals. Most ledger transactions are just bot activity, and the number of submitted proposals alone isn’t a reliable measure.

So there are two questions here:

  1. Would proposal submission or adoption be a better activity indicator?
  2. Are ledger transactions a good indicator?

Our proposed definition was purposefully chosen to be quite liberal, in the sense that even if only a bot makes a single ledger transaction, that would be enough for the frontends to consider this SNS active again. Making the definition stricter would be possible in the future, but there’s currently no pressing need for that; we just need a systematic way to keep the frontends nice and tidy.

A reasonable threshold could be 1–2 years, or perhaps a function of the maximum lock period.

Conversely, I think it would defeat the purpose of this proposal to have such a long period until an inactive SNS stops taking up space in the frontends.

Here’s a recent screenshot of NNS dapp. In my view, it doesn’t benefit most users to have ​---- (formerly CYCLES-TRANSFER-STATION) next to highly active projects, e.g., WaterNeuron, KongSwap, etc.

Screenshot 2025-03-11 at 16.56.19
Screenshot 2025-03-11 at 16.56.192784×2182 494 KB

Moreover, I’d argue that if a new user opens the ​---- page in the frontend, only to discover that all that info is irrelevant to them, there’s a high chance they would simply give up and don’t even explore the other SNSs. The frontends should present information that is highly valuable to the users.

2 Likes
7

Hi @tiago89,

What if a DAO wants to self declare “deprecated”?

Taking into account the distinction between deprecated and dissolved SNSs, it doesn’t make sense to declare deprecation, as if a DAO has enough active users to make any decision, it is by definition not deprecated.

Note that we do see the need to support sunsetting (i.e., active dissolution) for SNSs, but that’s a different discussion.

What if there are bots / arbitrage trading the SNS tokens, won’t it make it never “deprecated”, while the core team / token holders are not interested in it anymore, not making any proposals, etc.?

From the perspective of an SNS, there’s no conceptual difference if the transactions are performed by bots or humans. We don’t currently have KYC or any other system to ensure that SNS DAO participants are all distinct people. Note that, e.g., if there’s a bunch of bots actively trading on an SNS ledger, users can join them at any time, so I don’t see a problem with that.

What happens to the treasury when a DAO becomes “deprecated”?

Nothing would happen, as deprecation is not an active operation that an SNS would perform, but an observed state that the frontends can agree is indicative of sufficiently long inactivity to stop shoring those projects.

What if canisters stop having “cycles” being paid. Especially the governance canister that is “burning” a lot while active. Won’t this be a better signal that the SNS is not “useful / needed” enough for any token holder (and thus deprecated)?

This is a very interesting idea; indeed, we could wait until all or some SNS framework canisters (e.g., Governance) run out of cycles. The problem with this approach is that, as you point out, a lot of cycles are consumed while the SNS is active, but an inactive SNS would still have some cycles for potentially a very long time, taking up valuable frontend real estate away from more active projects.

8

Interesting suggestion, thanks.

I suggest that we first focus on a simpler problem discussed here (observing that an SNS is inactive / declaring it deprecated); as mentioned, we do want to address sunsetting SNSs in the near future, but the timeline for that is less clear.

9

I think it still largely depends on the DAO. You can create a proposal type to hide it from the frontend and/or even handle it manually yourself, as it shouldn’t happen too often.

I’d probably just do the whole thing since it’s still not that much work.

10

You’d want to make sure it’s not a malicious DAO that can just use a feature like that to hide themselves from the UX and Boom! take the money.

1 Like