Perhaps in an emergency situation, the solution can be kept simple at first. However, it is clear that a large and comprehensive study must be carried out on the DAO management algorithm for a permanent and correct solution.
I think that is relative. Our proposal, for instance, passed with 65% (and one could argue that most of the VP knew about it, agreed with it, or even suggested it). If we increase these percentages, they might need to decrease in one year or two.
In your case the proposal would still have passed, it just wonât have been executed early. The proposal needs 2/3 majority of the votes cast, not 67% of the total voting power.
1 Like
I think we should still be allowed to follow, but it shouldnât be included in the âall topicsâ category.
3 Likes
Restricting how much of the treasury can be extracted in a given time period seems unnecessarily complex and overly opinionated since there are valid use cases where a large portion of the treasury should be extracted, for example GHOST sent pretty much their entire treasury to form liquidity pools
I think the reason why restricting the treasury movements per period makes sense is because for many actual attack scenarios this is the only measure that might allow to slow down an attacker / give the opportunity to react:
Letâs say for example we have a DAO where the original developers get little voting power, say only 10%. Letâs then say someone manages to (unnoticeably) acquire a large share of the SNS voting power, for example by participating in the swap and in the neuronsâ fund and by later getting, all of a sudden, a lot of SNS tokens on some DEX and staking them. If they manage to get the majority (or a 2/3 majority with the proposed change) of the voting power very quickly, they can then just make a treasury proposal, get the ICP, and run.
If the treasury proposal were limited at least there is a limited amount that such an attacker could get out immediately. It would also potentially allow the SNS and NNS community to take additional measures before the next proposal can be sent.
I see your point that it might of course also limit legitimate treasury proposals. But if they are well planned, couldnât they just be made over a few transfers that then would then take maybe 2 weeks?
5 Likes
Hmm interesting point.
Maybe the max withdrawal amount per period can be configured during the SNS sale.
So teams who know they will want to withdraw lots must state that publicly before accepting any investment.
Then changing that amount would also be a critical proposal and maybe it only takes effect some duration after the proposal executes.
So if someone wants to withdraw the entire treasury theyâd first have to increase the limit, which would be public and would give the other SNS voters time to organise before they can actually withdraw it.
5 Likes
This could leave the DAO exposed to minority attacks on which the attacker gets 26% of the VP and blocks all the transfer proposals up to 51% adopt, or not?
But if they are well planned, couldnât they just be made over a few transfers that then would then take maybe 2 weeks?
I think having a period of weeks instead of months makes this point much more reasonable. Or perhaps making it configurable like Hamish suggested. @lara
2 Likes
Right. Note that this part as not been designed and we could have a separate thread to define the period and the thresholds in more detail with the community.
I agree that a limit per week might be a good compromise that ensures that with some planning legitimate proposals can still be realised in a reasonable amount of time, but attackers would be slowed down a little.
2 Likes
Then changing that amount would also be a critical proposal and maybe it only takes effect some duration after the proposal executes.
I think if this time-factor is in this proposal this might achieve a similar goal and can be an alternative.
In terms of simplicity, I wonder if this is simpler than just requiring a limit on the proposals. I also think requiring a limit is probably the safer default, as often otherwise users forget to consider the âbadâ scenarios and might just set a high limit to get things done quickly in a normal situation, leading to open attack vectors later.
2 Likes
Phase-2
Establishing the DAO Board of Directors: It is elected for 1 year by voting.
From the project team: 2 people
From Definity Foundation: 1 person
2 Investor members with a wallet balance of 1% or more
It consists of 5 members in total.
In the election voting proposal, candidates should be able to apply in separate tabs from the project team, definition foundation and investor members. Each category should be subject to separate voting. Definity foundation must mandatorily provide 1 person for each DAO.
Depending on the voting results, a manager badge with a lifespan of 1 year is automatically sent to the wallets NFT elected to the board of directors. This badge contains the rights that these wallets will have on the platform.
Duties of the DAO board of directors:
1-to prapere 2 reports a year, every 6 months, about the development of the project and publish them in the platform announcements section.
2-Preparing and voting on decisions regarding the development of the platform, and monitoring these decisions.
3- Keeping track of critical voting decisions
5-
6-
2 Likes
Iâve been thinking a lot about this. DAO can be powerful, but no one has really cracked the code(and different codes likely exist depending on the DAO size). One of the things that seems to be a big issue that should seem obvious when you look âhow the world actually worksâ is that almost all functional institutions have some form of executive function. Figuring out how to decentralize that may be tilting at windmills as the definition seems to include the centralization of power.(blockchains are great at decentralizing execution when deterministic math is involved and very bad at it in most other observed situations).
Hard Fact: A $3M DAO canât afford to pay a 5 qualified member board enough to keep it interesting and pay programmers to keep building the protocol. Locked SNS tokens canât pay the mortgage. If you reach critical mass, you may have volunteers that are willing to do this kind of thing, but by the time you reach critical mass, you likely have the funds to pay. Conundrum.
2 Likes
It is a management framework prepared for discussion. When this framework is discussed and matured and put into practice, application procedure algorithms will need to be prepared to fill this framework. In other words, the procedures that will be needed, such as the audit algorithm, management renewal algorithm, service purchasing algorithm, software service acceptance algorithm, marketing sales service algorithm, will be integrated into this framework.
In the current situation, we have learned through experience how the DAO treasury was emptied by a vote based on the voting power it had.
1 Like
Osman,
Love the enthusiasm, but such decisions would need to be at the âapplicationâ level, not âprotocolâ.
If a Y DAO wants to pursue what you say, they can create a âbudget managementâ canister, that is open and added to be controlled by that Y DAO. Then the treasury proposals that are commonly accepted by the voters are transfers to that âbudget canisterâ.
Also, these more âcomplexâ constructs frequently need changes to better adapt to the mission a certain DAO is pursuing, so itâs much better that they can fully control that experience (and not at the protocol level).
Hope this is helpful in some way.
I also tend to disagree on the âcustomizationâ part.
Convention over Configuration principle. The design and code will be a lot simpler and easier to implement/maintain. It also (re)opens attack vectors as Lara said.
If itâs week(s) apart, and reasonable amounts (the OR mix). Think any legitimate case would still pass. They only have the extra proposals and extra time cost, which is small compared to the security benefit an SNS should give.
1 Like
Hi everyone,
First, I want to thank everyone for sharing their thoughts, concerns, and ideas for improvements. This was a very constructive discussion with many excellent inputs!
After revising all the ideas that were shared, we adapted the original proposal with the communityâs ideas. In the following we present the resulting proposal.
What are critical SNS proposals?
As in the original post, we propose to consider the following SNS proposal topics to be âcritical SNS proposalsâ. (See original post for motivation.)
-
Transfer_sns_treasury_fundsproposals: These proposals allow an SNS to move ICP or SNS tokens from the SNSâs treasury to a given account. -
Mint_sns_tokensproposals (name tbd): This type of proposal will allow the SNS to mint new SNS tokens. Note that this proposal type does not exist yet, but is being developed as shared here. -
Deregister_dapp_canistersproposals: These proposals allow an SNS to give up control over a dapp canister and hand it back to a (centralized) controller.
Updated overview of proposed improvements
The newly proposed high level measures, and their current status & next steps, are as follows.
-
Increase the required threshold for all critical proposals: Critical proposals are only adopted if at the end of the voting period â (67%) of the used voting power votes in favor of the proposal and at least 20% of the total voting power voted yes. Critical proposals are executed immediately if â (67%) of the total voting power votes in favor of the proposal.
Details: Increasing the thresholds was presented to the community in this and this forum post and work on this has started. In this forum thread the community proposed alternative values for these thresholds. We now propose to adjust the design according to the communityâs proposal.
Next steps: This will slightly change the ongoing work, but the changes are small and the already planned work can easily be adapted accordingly. We plan to update this forum thread accordingly and keep you posted on the progress there. -
Remove critical proposals from the catch-all âAll topicsâ: Voters can follow other neurons on critical proposals, but each neuron has to make an active decision of following for each critical proposals type as the âAll topicsâ-following is not applied to critical proposals. Users who have multiple neurons can actively vote with just one of them and follow this one neuron with all their other neurons.
It would be possible to reset following on critical proposals in all existing SNSs as an addition to this measure.
Details: This is an alternative to âRemove following for critical proposalsâ as proposed above that was proposed by the community. This means that the complete removal of following would not be pursued anymore.
Next steps: If the community does not express concerns here, we plan to remove critical proposals from the catch-all and propose it to the NNS as part of the normal SNS release process. We would then discuss in a separate forum thread whether, in addition, following on critical proposals should also be reset in existing SNSs. This addition can then be done separately if this is what the community agrees on. -
Limit SNS treasury proposals: Limit the amount of tokens that can be moved by SNS treasury proposals. This might, for example, be a limit of how many ICP and SNS tokens can be moved out of the SNS treasury per week or month.
Details: This measure was included in the original proposal above. The community expressed some concerns about this measure hindering legitimate proposals. We think this disadvantage is outweighed by the following advantages: This is one of the only measures that helps to slow down attacks where a malicious party gets a large portion of the voting power. Moreover, legitimate proposals that require a large portion of the treasury can still be done, they might just require more than one proposal and a bit more time. Since treasury movements are normally planned well in advance and not urgent, this is acceptable. The concerns about slower legitimate proposals can additionally be mitigated by choosing a time period that is not too long (e.g., only weeks or even days).
Next steps: We propose to share a more concrete design proposal in the coming weeks, which will then be discussed with the community. This will include agreeing on an appropriate time period. -
Increase the voting period for critical proposals: Increase the voting period for critical proposals to be 5-10 days (as opposed to 4-8 days for normal proposals). As these proposals require a larger voting participation it might be beneficial to give voters a bit more time to participate. On the other hand, the voting period should not be too long in order not to unnecessarily block legitimate proposals. The wait-for-quiet algorithm already ensures that controversial proposals will have a longer voting period so that voters have the time to react (now a proposal that starts with a 4 day voting period can be increased to have at most 8 days, after the change a 5 days can be increased to 10 days).
Details: This is a community proposal from this thread.
Next steps: If the community does not express concerns, we plan to realize this and propose it to the NNS as part of the normal SNS release process.
Summary of next steps
While it is important to consider all planned improvements in one overall plan, the individual improvements can be worked on, discussed in detail, and released one-by-one. If the community agrees to the high level plan, the summary of the next steps from our side are as follows.
- Add the following measures to our roadmap and, when ready, propose them to the NNS as part of the normal SNS release process.
- Increase the required thresholds for all critical proposals to 67% and 20%.
- Remove critical proposals from the catch-all âAll topicsâ.
- Increase the voting period for critical proposals to 5-10 days.
- Work on designs for the following measures and share more detailed designs with the community in a separate thread.
- Limit SNS treasury proposals.
- Clarify if following on critical proposals should be reset in existing SNSs.
As always, we are looking forward to your feedback! I wish everyone a great day!
12 Likes
Thanks @lara, this proposal suggestion looks great. We hope to learn more details soon about the treasury limits. One thing we have been considering is swapping part of the treasury for other tokens like ckBTC, ckETH or ckUSDC ( if supported in the future ). We hope that these restrictions are not too limited that this would not prevent swapping larger percents 20-30% of the treasury into these tokens.
2 Likes
In my opinion, 5 days is still too short. I donât see anything wrong with making it 14 days for a minimum voting period for critical proposals. The use of the term critical here is not in reference to security issues, so I donât see any need to be in a hurry to get them completed. These types of proposals should all be planned well in advance.
Overall it seems like this revised proposal is a very sensible path forward. Great job leading the discussion.
1 Like
Thank you, Lara, for the work youâve done. In the future, we would still appreciate having an option to disable the immediate execution of certain proposals once their threshold is reached, allowing them to continue for the full period. This might give people time to change their minds and perhaps vote manually.
2 Likes
Hi @wpb ,
We think this depends on the limit on the transfer. We would be fine to plan these in advance but if multiple proposals are necessary to cover our costs then we risk running out of funding for payroll or the value changes drastically due to market volatility.
The SNS was a complex and costly process. We worry that adding so many more restrictions will essentially increase our costs to operate effectively. If an attacker does get majority vote, we are also not sure what an additional 10 days will do.
2 Likes
Thank you Lara.
This looks great and resonable.
Following from what Seers is saying, think we still have a very important issue to solve, that is beacon neuron triggering the voters immediately, before they even have a chance to be against.
My proposal is that: By design, known neurons should only trigger around the last day of the voting period. Especially for these critical proposals.
Think this would be a very important addition. Imagine a proposal is out, and the beacon âtriggersâ out with all the followerâs. It could be hard for the ânon followersâ to still be able to win. Even after the changes suggested above.
Known neurons are there to ensure voters always get their rewards, not to remove their will.
Was wandering, any idea if the known neurons concept will happen in the SNS anytime soon? Could this âbehaviourâ be implemented to it?
If others agree and think known neurons should have a forced âdelayâ on their trigger, kindly react, second or comment your support.
Thanks, hope this is helpful. 
3 Likes
I thinK it makes sense for the DAO to try and reach members to participate, so that it indeed works like a DAO. The ones that dont become proper DAOs would be okay to die off.