Hey everyone! We wanted to start a discussion about the current SNS treasury limits and propose some improvements based on our experience in the WaterNeuron DAO.
The Current Situation
Most of you probably remember the BOOM DAO incident - when they moved about 80% of their treasury (327,187 ICP out of 408,985 ICP) in a single proposal. This led to some important safety measures being added to the SNS framework.
These safety measures include:
Voting requirements:
You need 2/3 of all votes for direct execution (vs 50% for regular proposals)
Otherwise, you need to wait 4 days and get 20% voting power (vs 3% for regular proposals)
Treasury limits:
300k XDR combined limit
Hard 25% treasury movement cap
Both limits apply to ICP treasury AND SNS governance tokens together
Must wait 7 days between treasury transfers
Why This Is Challenging
We’re currently running two distributions at WaterNeuron:
Moving ICP from the first SNS transfer to 8-year neurons
Distributing WTN tokens from the WTN Papaya sale
Here’s what we’re experiencing:
In our ICP distribution process, we encountered the 25% limit after just 6 proposals, leaving us needing at least 10 more proposals to move the remaining third of the treasury. Each treasury proposal cycle ends up taking about 12 days total - this includes the mandatory 7-day wait plus 4 days for execution. Even for a DAO that makes governance its primary focus, reaching the required 2/3 of all votes within that 4-day window has proven consistently challenging.
The WTN distribution situation has added another layer of complexity. Since the limits combine ICP and governance tokens, we’ve had to completely pause our ICP neuron staking. We began the WTN distribution on December 11, 2024, and at our current pace of 13 days between proposals, we don’t expect to finish until around April 7th. Only after completing this can we resume the ICP treasury transfers, which will require another 4 proposals. What should be straightforward treasury management is stretching into nearly 10 months of continuous proposal cycles.
What We’re Proposing
Adjust the caps:
Let DAOs vote to set their weekly cap between 100k to 500k XDR
Keep the current default
Remove the 25% limit as it’s causing unnecessary delays
Fix the timing:
Currently, you must wait 7 days after the last successful treasury transfer before submitting a new treasury proposal
This means even if you’re ready to submit the next proposal, you have to wait
The framework should allow a new treasury proposal submission exactly 7 days after the previous one, enabling a steady weekly transfer cadence
Separate the limits:
Apply the 300k XDR weekly limit to ICP treasury and governance tokens independently
This lets DAOs manage different token distributions without blocking each other
Make limits more transparent:
Show the current treasury transfer limit somewhere visible
Display how much of the weekly cap the DAO has used
Right now we have to submit test proposals to figure out our limits - this isn’t ideal
We understand why these safety measures exist, but they’re making routine DAO operations unnecessarily complicated. These changes would maintain security while making DAOs more efficient.
I’ve included our full distribution data in tables below if anyone wants to dig into the details. What do you all think about these suggestions?
I believe the treasury limits were an over reaction by the nns voters that created an overreach into individual projects and their treasury management.
With that being said your thoughts here lay out a reasonable adjustment to the restrictions placed onto the daos by the nns. This looks to be a great middle ground between treasury flexibility within individual daos and security for people who do not “DYOR” before buying into a sns.
One could argue that the arbitrary limits imposed on WaterNeuron is actually increasing risks for the DAO. Instead of using one proposal to make these transfers–which everyone could thoroughly scrutinize–we have to make them over the course of dozens of proposals. The more proposals we make, the greater the risk of a mistake. Why exactly should we bear additional risk here?
That is a good point. It all comes back to the fact these treasury restrictions on the daos through the nns is a complete over reach.
Instead of allowing users to learn to dyor before investing they created a guise of safety through treasury transfer restrictions. At the end of the day if a team is going to drain the treasury these restrictions do nothing but delay the inevitable.
I agree with your suggestions @EnzoPlayer0ne. Thank you for starting this conversation. I think your proposal is a pragmatic solution to this problem that provides a respectable balance between maintaining the security benefits of the limits while removing many of the pain points that SNS projects experience with treasury management. As an active member of the WaterNeuron community, I too have felt that the current limits are too restrictive and have hindered progress that needs to be made according to the will of the WaterNeuron DAO. I hope to see some changes in the relatively near future based on these suggestions.
I also want to clarify that I believe that the limits are needed for SNS projects.
I have no issue with the intent of the framework that drives these limits. The pros outweigh the cons in my opinion. I simply think they are too restrictive and should be tweaked in the ways that have been outlined.
From the governance team, we think the following adjustments are well in line with the original design intent that was discussed extensively with the community and we are happy to add them to the SNS framework once we wrapped up ongoing work.
Making sure one can actually send one proposal within the limits every 7 days (Point “2. Fixing the time”). Remark: As long as we agree on this goal, I think we should leave it up to the engineers whether the proposed solution (to submit 7d after the last submission) or an alternative that achieves the same (e.g., adjusting when the checks are made in terms of submission and/or execution time) are cleanest in terms of code and user experience.
Help users make more informed decisions (Point 4. "Make the limits more transparent”). We fully support making information transparent for users. To make this accessible to users this probably also has to be included in a dashboard. Maybe one could reach out to https://snsgeek.app/ and propose to them whether this could be added? But we are happy to add an API to the SNS governance that contains this information if this is required to realize this.
These two points would hopefully already help the WaterNeuron community as they would increase the rate of proposals by almost 2x and help the community better understand what is going on while they would not have a negative / unwanted effect on other SNSs. Here our thoughts on the other points and why we think they might affect other SNSs quite a bit and should therefore not just be changed without a larger discussion with the affected SNSs and the NNS voters:
After thinking about it, having the limits together actually gives more flexibility to SNSs compared to have them separate: if there was a separate 150K limit for the ICP and SNS treasury rather than a 300K overall limit, this would be even more restrictive. So we don’t think this is a step towards more flexibility.
Removing the 25% would change the rules for quite some SNSs at the moment: Recall that the current limits are set as follows:
SNSs with a small treasury (<100K) have no limit
SNSs with a mid-size treasury (100K-1 200K) have a limit of 25% of the treasury
SNSs with a large treasury (>1 200K) have a limit of 300K
Looking at https://snsgeek.app/ and the ICP-XDR conversion rate, today we have 11 SNSs with small treasuries (no limit), 14 mid-size treasury SNSs where the 25%-rule applies, and 8 large ones where only the 300K rule catches on. Therefore changing this would affect quite some SNSs.
Let me add that it is true that it is a bit weird that there is a this bump at the 100K. We considered this when we discussed the design and thought about alternatively have a smoother curve decide on the limits. But as long as we roughly agree that the limits are what they should be, I don’t think this will drastically improve the efficiency of many subsequent proposals while it would make the rules more complex in terms of code and explaining to users. If I am missing something here and this would in fact be a big help, then please let us know.
@lara, what if we made the restrictions the default but permitted any given DAO to lift certain (or all) of the restrictions as to that specific DAO if it receives a supermajority of votes? That way DAOs could get the protections DFINITY came up with. But DAOs could also have additional flexibility if the DAO members actively decide to get rid of certain restrictions.
After thinking about it, having the limits together actually gives more flexibility to SNSs compared to have them separate: if there was a separate 150K limit for the ICP and SNS treasury rather than a 300K overall limit, this would be even more restrictive. So we don’t think this is a step towards more flexibility.
I think, the idea was to have a separate 300k limit for the ICP and SNS treasury (and not a 150k limit) for the reasons mentioned by Enzo. Do the governance team thinks it’s too much ?
Ah, in that case to me the same answer as for other requests to change the limits applies “they might affect other SNSs quite a bit and should therefore not just be changed without a larger discussion with the affected SNSs and the NNS voters” as we would effectively double what an SNS can move at a time.
One factor to maybe keep in mind here is that there are also advantages to having certain rules be the same in all SNSs, namely that users who understand one SNS also easily know how another SNS works. Some users might be surprised if certain limits are different in different SNSs they participate which can lead to confusion or misunderstandings.
That being said, there is always this tension between a similar experience that can help with user experience and trust and having more flexibility for SNS communities.
If a lot of SNS communities think this flexibility is needed and the NNS voters agree that this tradeoff should therefore be moved slightly, I think we can consider adding this in the future.
In my opinion, we should remove the rules altogether. It’s evident that they are widely disregarded, and their introduction was both illogical and poorly timed, appearing to target specific DAOs in an arbitrary and selective manner.
@lara, thank you for the response. Here is my argument for why we should let DAOs opt out of the restrictions placed on SNS tokens held by the treasury.
A clever dev can get around the current SNS restrictions by giving tokens at genesis to a canister controlled by the DAO instead of the DAO’s treasury. The effect is the same: the DAO controls the tokens either way. But the treasury restrictions won’t apply if the tokens are held by a canister instead of the treasury.
Given that future DAOs can select to do that, they can effectively opt out of the restrictions placed on SNS tokens held by the treasury. Old DAOs, however, cannot take advantage of that because they have already had their token genesis event. Thus, the system effectively permits new DAOs to opt out of the restrictions placed on SNS tokens but not old DAOs. The reality that the restriction effectively applies only to old DAOs seems unfair and arbitrary.
A clever dev can get around the current SNS restrictions by giving tokens at genesis to a canister controlled by the DAO instead of the DAO’s treasury.
It is not possible for an SNS to assign tokens to a canister’s account at genesis. The SNS tokens are in a reserved account on the SNS token ledger and the ICP raised in the swap are in an account that is directly controlled by the SNS governance.
All further changes then need to be voted on by the SNS.
Laura, my understanding is that when a developer proposes an SNS sale, their proposal can allocate SNS tokens to specific addresses. While those addresses are typically controlled by the project’s founders/developers, a developer could decide allocate tokens to a canister address with the promise to put the canister under DAO control during the sale. That would allow the DAO to evade the restrictions we’re discussing here.