Limit SNS treasury proposals - detailed design

Governance SNS Project Governance
,
1

Hi all,

Let’s discuss the design of limiting SNS treasury proposals!

Context & Motivation

After the community discussion here, there are four planned measures to make passing critical SNS proposals more robust. For context, critical proposals are transfers of treasury funds, minting of SNS tokens, and giving dapp canisters under DAO control to another controller (“de-registering dapp canisters”). One planned measure is introducing limits to the amount of tokens that can be moved by SNS treasury proposals during a given period of time. The main motivation for this is that it is one of the only measures that helps to slow down attacks in a malicious scenario.

This forum thread is to discuss the design of these limits in more detail.

Proposed design

We propose the following design.

  • Have separate limits on each kind of token in the SNS treasury - the native SNS tokens and ICP tokens.
  • For each of those tokens (native SNS tokens & ICP tokens), the following limits hold for each week:
    • at most 300,000 XDR worth of tokens can be taken out of the treasury
    • if there are at least 100,000 XDR worth of tokens in the treasury, then at most 25% of the treasury can be moved out.
      • In the case where there are less than 100,000 XDR worth of tokens in the treasury, this limit does not apply.
  • For the conversion rate of SNS tokens / XDR and ICP tokens / XDR, take the moving average from the last month.

Some details

Why XDR?
The ICP to XDR conversion rate is already stored on an NNS canister and therefore easily obtainable. Since the main purpose of this feature is to limit the damage that can be done in a malicious context, whether these limits are given in XDR or another currency, e.g., USD, does not seem to be relevant.

How to get the conversion rate for SNS tokens to XDR?
It is unclear how to get a reliable conversion rate from any SNS token to XDR or ICP - new SNSs might not even be in any liquidity pools yet. This first design proposes to take the SNS tokens to ICP tokens conversion rate from the SNS’s initial decentralization swap. If the SNS token increases or decreases a lot in value after the initial swap, then the limits might be a bit off.

To better understand this, let’s consider some examples:

  • Let’s assume that at the swap, 1 SNS token = 1 ICP, let’s also assume (just because this is the easiest number for the given rules), that 1 ICP = 3 XDR and that this stays constant over time.
  • Let’s now consider different scenarios for the SNS token price and see how many XDR can be taken out of the treasury according to the above rules in one week.
    • According to the above rules, we take the SNS / ICP conversion rate from the swap, so 1 SNS token = 1 ICP token. As we assume ICP / XDR is stable, this means that a treasury proposal can take out 300,000 XDR = 100,000 ICP = 100,000 SNS tokens.
    • If the SNS token to ICP exchange rate has not changed, then this is accurate.
    • Let’s assume the SNS token is now worth 10 times more: 1 SNS token = 10 ICP. This means that effectively a treasury proposal can now take out 100,000 SNS tokens = 3,000,000 XDR
    • Let’s assume the SNS token is now worth 10 times less: 1 SNS token = 0.1 ICP. This means that effectively a treasury proposal can now take out 100,000 SNS tokens = 30,000 XDR

The conclusion is that in the case where the SNS token increases a lot in value compared to ICP, the measures proposed in this thread are less effective. However, for many SNS tokens these measures would already slow down an attack scenario, which is the main goal. Later improvements, e.g., to make the limits even more robust, can still be added in the future.

Next steps

We are looking forward to discussing the design of this feature in this forum thread. Once we converge to a design, we plan to pick up the implementation and propose this to the NNS as part of the normal release process of SNS governance.

9 Likes
2

You could use ICPCoins SNS to ICP rate once it launches as SNS and we standardize dex interfaces so the data is reliable. A monthly moving average - that will be pretty safe. The data is being observed by the community so everyone will notice if there is something irregular long before the moving average gets affected.

Or for now, you could just take % of the total coins instead of limiting in XDR. Example: Can’t withdraw more than 1.5% of the total supply from the treasury per week. That will be around 300k XDR. The bigger the DAO the more they can take out.

3 Likes
3

Hi @infu , thanks for the feedback!

Yes indeed, once more DEXs are around and the interfaces are standardized this might be an option. There is still the challenge that some SNSs that just launched might not be on any DEX yet, and we might want to combine information from different DEXs too.

For you other idea,

1.5% of the total supply

Can you elaborate on how you would define the total supply here? All tokens in the SNS ledger? Or all tokens that are on the ledger but not in neuron accounts?

That will be around 300k XDR

Can you also elaborate on how you arrive at this? I don’t quite follow here as SNSs could have very different treasuries, right? Or do you just base this on the SNSs we have so far and say that this would be in the order of around this?

2 Likes
4

image
image1369×330 67.7 KB

Here is the spreadsheet if you want to try different functions
https://docs.google.com/spreadsheets/d/1WzHD-hKXjIEVEBRotLk5r236doy0aYRIFyxLoaCT2fQ/edit?usp=sharing

Total supply - reported by ledger.
Circulating supply is total - treasury with small exceptions.
It’s around 300k$ for most, except the smallest DAOs.

If a DAO doesn’t have a large treasury, like the DAOs right now, then it won’t be able to withdraw a lot. Let’s say its treasury is 10% of the total. The amount it can withdraw will be half compared to a DAO with 50% treasury. But it makes sense since you don’t have much to withdraw anyway.

3 Likes
5

Hi Lara,

Congrats on this effort, I agree and support on this design.

I liked the idea of “setting” through XDR. It seems stable.
I also liked the idea of using exchange data, we are months away from this being a reality, and a few months afterward we can have the ICPcoins data being integrated.

I wouldn’t be too worried about SNS tokens withdrawals because the liquidity of them is very shallow, which makes the profit on a bad actor even lower.

I have been following all SNSs and don’t think it has been a single one that has moved tokens to pay their team or a grant (they always use the ICP treasury). The SNS token transfers have only been associated with Airdrop (both public, funded and seed funds) and Liquidity Pools, and none of them were remotely close to 25% of Treasury or to 300k XDR (so even in big price differences, don’t think it will limit anyone for the forthcoming months).

In short, thank you and look forward to see it’s implementation.

1 Like
6

Thanks everyone for the feedback!

So it seems that for the ICP treasury there are no big concerns and we can go ahead and implement this!

For the SNS treasury there are two ideas:

  1. Do the same as for the ICP, but since we don’t have (yet) a good SNS token conversion rate to ICP or XDR, use the SNS token / ICP token conversion rate from the swap.
  2. Limit the SNS treasury as a % from the total SNS token supply.

From my PoV, 1. has the advantage that it is more similar to what is done for ICP and can later maybe be made more accurate for SNSs that are on a DEX.
On the other hand, 2. does not depend on a conversion rate that might be outdated at some point after the swap.
In my view, both are possible and we could just take the one that is easier to implement.

3 Likes
7

Hi @lara,

Thank you for the detailed proposal and for considering various perspectives in managing the treasury. It’s encouraging to see such a thoughtful approach. Here are our thoughts and some questions for further clarity:

Proposal Creation and Market Fluctuations: With the 300,000 XDR limit, we assume it’s evaluated at the time of proposal creation. Would it be feasible to accept a proposal based on an XDR value, and then withdraw the equivalent ICP amount only after the proposal’s acceptance? This could provide a buffer against market fluctuations, especially relevant during longer voting periods for critical proposals.

Future Adjustments and Special Circumstances: Will these withdrawal parameters always be under the control of the NNS, or might SNS projects gain some autonomy in the future? Considering scenarios such as expensive CEX listings, which may necessitate quicker access to larger funds, could there be a mechanism for temporary limit increases authorized by the NNS for specific projects?

Preference for SNS Treasury Management: Regarding the SNS treasury, we lean towards the second option you proposed: limiting the treasury withdrawals as a percentage of the total SNS token supply. This approach seems more straightforward and less reliant on potentially outdated conversion rates. It could provide a clearer and more stable framework for managing SNS treasury funds, especially if we set a reasonable percentage, such as 10% of the total SNS token supply. This would also allow for scalability as the value of the SNS tokens changes over time.

We appreciate your efforts in drafting these proposals and look forward to contributing to their refinement and implementation.

3 Likes
8

Hi @modclub,
thanks for the feedback!
Let me try to answer your questions in turn.

Would it be feasible to accept a proposal based on an XDR value, and then withdraw the equivalent ICP amount only after the proposal’s acceptance?

Just to make sure I understand correctly: do you mean one could take the XDR-ICP conversion rate at the time of the proposal creation and, at the time when the proposal is executed still take this conversion rate?

If this is the right understanding then I agree with you that this would make sense. As the proposal is to take the monthly average the difference should not be huge and this would make it more predictable for the submitter and for voters wrt whether a proposal will be successful.

Will these withdrawal parameters always be under the control of the NNS, or might SNS projects gain some autonomy in the future?

I think it is worth pointing out that the big advantage of having some limits “hardcoded” by the NNS is that this can limit an attack where an SNS is taken over by some parties maliciously.
But of course all of this is up to the NNS, now as well as in the future.

we lean towards the second option you proposed: limiting the treasury withdrawals as a percentage of the total SNS token supply.

Thanks for this feedback!

1 Like
9

Hi all,
thanks a lot for the ideas and feedback!

Regarding how to limit the SNS token treasury, a teammate raised the very good point about a potential problem if we limit it by the total supply rather than an XDR value.

  • One main goal of introducing limits is that even if an attacker is able to get a majority of the voting power, these measures would still slow down a potential attack where the treasury is emptied out.
  • If the limits would depend on a % of the total supply, then an attacker could 1) mint new SNS tokens by proposal and thereby increase the supply and 2) take out the full amount of the treasury. In this case, the goal would not be achieved.

Given that there was some support for both solutions above, we therefore propose to go with the original proposal and limit both the ICP and the SNS token treasury by an XDR value. This also has the advantage that the limits for the different tokens work similarly, which might be easier for users to understand.

In summary, we thus propose the following solution:

  • limit the ICP and the SNS token treasury by week and by the XDR values introduced in the original post here
  • take the XDR-ICP, and XDR-SNS token conversion rate at the time of the proposal submission (as proposed by @modclub)

Note that this leaves the door open for future improvements, for example taking more up to date SNS token conversion rates into account or other improvements.

Next steps
If everyone here agrees that this is a good first step, we will proceed working on this and propose the final implementation to the NNS as part of the normal release process.

4 Likes
10

The proposal seems reasonable to me. I agree.

2 Likes
11

@lara I understand that there will be these 300’000 XDR / week limits for SNS treasury proposals. Do these limits also apply to minting tokens, as minting tokens are also considered “critical proposals”? Also, are there any limits to the number of tokens that can be minted by a minting proposal?

12

Hi @Dustin , we propose that the limits are also applied to minting proposals, as presented in this post by Daniel.
I hope this answers the question!

13

Isn’t impossible to do over 300k or just if you do it becomes critical? Is there any way to override this at an SNS level? (Imagine a high burn high mint type ledger?)

Can the minting account be set to a smart contract that the SNS owns as an alternative?

1 Like
14

Hi Lara, a few questions:

  • Will this be optional? Or will it be enforced to anyone using the SNS?
  • Are those limits set by the DAO?
    I think it’s a trade-off between UX and risk management.
15

Hi skilesare,

No, all TransferSnsTreasuryFunds proposals are critical, regardless of the amount involved.

The limit on the amount is determined by treasury size though.

No. See my reply to Orions, below.

No, governance is the designated minter. This is so that minting is strongly controlled.

16

Hi 0rions,

No, this proposal does not call for a way to opt out.

No, they are hard-coded.

IMHO, allowing the SNS to choose seems to defeat the purpose, because if an SNS can vote for different limits, it can do anything it wants, albeit with more steps. I guess if proposals to change the limits need to clear an even higher bar, then it would make more sense.

17

IMHO, allowing the SNS to choose seems to defeat the purpose, because if an SNS can vote for different limits, it can do anything it wants, albeit with more steps. I guess if proposals to change the limits need to clear an even higher bar, then it would make more sense.

In my opinion, it would be better to increase the bar to execute critical proposals rather than limiting the amount of tokens that can be transferred or minted. This seems to me to be more and more limiting the freedom to operate of SNSs.

18

Hi @Dustin and thanks for the feedback!
Indeed I think we should not look at individual measures but at all of them together. We have done this in a great discussion with the community here where in the end the community decided & agreed to increase the bar through different means, including the limits for treasury proposals.

I think one of the main advantages of the limits is the following: Let’s assume that there is some malicious take over of an SNS DAO - through a bug, a weird market situation, or something else, someone is able to get the majority of the voting power (whatever the majority needed at this moment). In such a case, the only thing that would help to slow down that the attacker can immediately drain the funds of the treasury is a limit such as this one.
One can also argue that large investments should be planned ahead sufficiently. If one agrees to that one can just plan to start earlier and to multiple consecutive treasury movements.

Another thing to consider is that the threshold of 2/3 is already rather high now for treasury proposals. One could also argue that making it even higher could have the consequence that in a less active DAO it would be hard to reach the threshold at all and that this in turn also can make the DAO less operational.

I hope this helps to get some more context.

19

@lara With that logic then any canister upgrade should also be considered a critical proposal. If an attacker can introduce malicious code into a dApp then they could easily drain all the funds of a users wallet if they would like. All this is doing is micromanaging projects because Dfinity does not trust them.

20

Hi @jakkorenzo,
I don’t agree with your last sentence. As stated in the previously linked forum thread, the community raised the current situation as a problem and there was a long discussion with the whole community, explicitly also including existing SNS communities, that lead to the agreed measures.

Right, this does not address all problems, but it does add some robustness for the tokens in the treasury.
For the wallet case, it matters on the exact setup: if the wallet is implemented directly in the dapp, then indeed this can happen. However, if the dapp just integrates with a wallet, the user could be asked to approve large transactions on the wallet again and in that case it would be harder to drain a user’s funds. I think this is an interesting problem to solve but does not take away from the benefits of the feature discussed here.