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
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.
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.
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.
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_funds proposals: These proposals allow an SNS to move ICP or SNS tokens from the SNS’s treasury to a given account.
Mint_sns_tokens proposals (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_canisters proposals: 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!
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.
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.
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.
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.
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.
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.
Thanks for the feedback. Note that proposals are only executed if their result cannot be changed anymore even if all other voters would still vote.
Maybe with “changing their minds” you also refer to following not kicking in immediately so that people can still choose to vote directly?
This has also been discussed at some point in the context of the NNS. Note that this might require quite some changes to how wait-for-quiet works: in the current design, votes cannot be changed. Based on this, wait-for-quiet takes into account the votes for adoption and rejection and increases the voting period if the results flips back-and-forth - so if the proposal is controversial. This also holds for voting more generally: the trend of the vote is currently always clear and voters can adjust their behavior accordingly - which I think is a big advantage of the design.
One easy “solution” for ensuring that neurons can vote directly is that followed neurons can change their behavior to facilitate this for their followers: They can only cast their vote after a few days. This allows their followers to have enough time to vote directly if they wish to do so and at the same time followers can be sure that a vote will be sent if they didn’t get around to it in these days. Neurons that behave this way could be favored to be followed by other neurons.
How about we start with 5 days and try it out? We thought this is a nice compromise between having a bit more time but still being able to also wait for 2 proposals if this should be needed with the limits.
Once this is parametrised, it would also be easy to adjust these numbers again if the community thinks that with new learnings something else makes more sense.
I would also like to note that there is also the wait-for-quiet algorithm that makes sure that if the proposal is controversial it will automatically have a longer waiting period of up to 10 days. This is the main idea of wait-for-quiet: if a topic is controversial, the voting period will automatically be increased. On the other hand, if the result is very clear and there is no need to wait longer, the algorithm allows to make faster decisions.
Thanks for this idea.
As mentioned in another answer above, there are also quite some downsides to waiting with following until the end, so I think this would have to be carefully considered.
As also mentioned, followed neurons could be encouraged by their followers to wait longer with voting so they have the opportunity to case a direct vote.
Known neurons are there to ensure voters always get their rewards, not to remove their will.
I slightly disagree with the first part of this statement. Even though some neurons might use it this way, one of the main goals of following is also that a neuron can follow different experts on different topics. It is in every neuron’s interest to vote in the best long-term interest of the IC. Therefore, a neuron should always trust the followed neuron to make good decisions.
Of course it could be that there are scenarios where neurons gain more by the voting rewards and so they don’t care about whether the decisions were good or bad - but I think the design should not incentivise this kind of thinking but rather incentivise neurons to make sure whoever they delegate their vote to will make a good decision.
Sounds good to me. Let’s try it out as you suggested.
Thanks for this feedback. I better understand now that simply controlling time could lead to more harm than good.
After a bit of reflection I would argue that the root problem is the lack of “experts to follow”.
That is the “though nut to crack”, and if the SNS framework (and swap) can solve it, that could be a big boost in terms of success and reputation.
Think the end goal is that on any SNS swap end, it comes with 3 known neurons for voters to choose from. There is a “minimum guarantee” that is given by the SNS swap process (on the proposal it could have a field to add 3 known neurons). Later more known neurons can be onboarded.
How each project picks them up and rewards them (vested tokens), is entirely up to them. The NNS/Community can then judge if they look like independent parties and that they have the expertise to vote on the proposals.
I wouldn’t be surprised if it emerges a pattern where one known neuron is the dev team, another neuron is a reviewer/security auditor, and another one a community elected governance neuron (more for gov / treasury proposals review/consensus).
With this minimal setup, then SNSs can be more functional, more decentralized and with the right amount of tension / distributed work.
So, wrapping up, we desperately need the known neurons concept
Thanks for listening, kindly request feedback, from both Lara and community
For those following this thread, please find here the follow up on Remove critical proposals from the catch-all “All topics”.
Thanks @tiago89 for this idea!
I agree that it would be a useful goal for SNSs to get more “experts to follow”.
I see the motivation to embed this in the SNS launch process, but wonder if this is needed. Any SNS launch is approved by the NNS community, so if the “good practice” emerges that an SNS should have at least 3 initial neurons to follow, then the NNS could just reject all SNSs that do not satisfy this. However, leaving this to voting would also leave the flexibility for exceptions in case where an SNS project can convince the NNS voters that it is justified.
In terms of the “known neurons” concept: we do have it on our roadmap to also look at this for the SNSs, but don’t have a clear plan yet when this will be done.
I also think we should keep it simple and adopt one of two methods to address this:
One solution I like from another thread posted by @EmrahCoskun:
“Might I suggest considering a dynamic threshold based on average participation over the past three months, yet never dropping below 30% of the actual total voting power? It seems a fair compromise.”
I think there should be limits per weeks.
Can we get a notifications tab on the NNS tab that says something like “Your followed Neuron “blank” has voted on X proposal”. The followee can go look at it and have the ability to change their mind otherwise if no action taken then the vote is cast. Maybe cumbersome with notifications but give people the option to filter or turn them off as well perhaps. Also maybe delay the the vote 24 or so hours or until voting period ends whichever come first.
Lots of great ideas discussed in this thread. I like the last revision to the improvements for these types of proposals @lara