The Section “List short-term pain points for discussion” was updated on March 14 to include previous feedback. To review the changes, see the version history by clicking on the numbered “pen” icon in the top right-hand corner, next to the date.
Towards a Governance Framework for SafeDAO
It is clear that SafeDAO eventually needs a sophisticated governance framework which defines the scope of decisions SafeDAO takes decisions on, improves our current governance process and ensures that processes governance represents all stakeholders in the SafeDAO ecosystem appropriately, e.g. through a revised delegation system.
Blockers and Road Ahead
At this time, some uncertainties around the product vision of SafeDAO, legal questions around holding and managing funds and other open questions would likely lead to a suboptimal governance framework if it is unclear what the legal requirements are and which outputs governance processes should be optimised for. Still, we have repeatedly realised that the current governance process should be revisited.
Purpose and Output of this Thread
I’d like to use this thread (not a proposal just yet!) to gather problems around our current process and give everybody the chance to direct our attention to particular areas where you see room for improvements.
The output of this thread could be a ‘Governance Process v2’ proposal which should fix the most urgent shortcoming of the current governance process, while not covering other domains that are blocked by the open questions mentioned above.
I’ll start with a list of issues below and will update this first post based on further responses.
List short-term pain points for discussion
The current process restricts SafeDAO proposal to using single-choice voting, which is a good choice for binary votes leading to a clear winner (like with SEPs #1, #2 and #4), but a poor choice when there are several options to choose from (like with SEP #3). See also Voting systems - snapshot.
“Abstain” votes count towards the quorum which, theoretically, could lead to a situation when a proposal is decided by a relatively small amount of votes voting “For” or “Against” which do not reach quorum on their own, but the proposal passes quorum with a significant number of “Abstain” votes which arguably should not indirectly count towards “For” or “Against”.
Note: Deleted based on feedback, including comments from @b3nnnp, @auryn and @links.
Currently, phase 1 proposals need to be open for discussion for at least six day before they could move on to Snapshot. The current process does not define an extended review period after the proposal has been changed. For clarity it may be worth defining that if and when the review period is reset after a proposal has been edited.
The use of SafeSnap is desired, but not defined in any detail. A useful requirement may be that phase 1 proposals must can include a code snippet of the exact SafeSnap specification and parameters, as long as they also use the voting system “Basic voting”. There should also be a mechanism to audit the SafeSnap specification to ensure that it in fact does what the proposal suggests. To differentiate between proposals with onchain execution and those without, we may want to consider introducing Snapshot sub-spaces for each kind.
Note: Revised based on feedback, including comments from @auryn and @links.
The process of moving proposals from phase 0 (pre-SEP) to phase 1 (SEP) should be improved. Currently, labelling SEPs is done by forum admins on a case-by-case decision with the author evaluating whether a proposal is mature enough so that can realistically be finalised in six days. Mature proposals that deserve wider attention are featured on the official Safegovernance-Twitter. To introduce more transparency, we may want to consider defining what makes a “mature” proposal. To decentralise the decision-making process, we may want to consider extending the group of admins, e.g. to selected Guardians.
Note: Thanks to @links for highlighting this issue again.
…
Looking forward to hearing your thoughts on the above and additions to this list.
After some days of brainstorming, we can start evaluating the list, prioritise them and transform the output into a first proposal towards a governance framework for SafeDAO.
I think start with the understanding that not all items being voted on are created equal. In the interests of gov minimisation it’s better to know when an abstain is problematic and just start with that (i.e. changing governance itself is a good example where abstention should be limited because people SHOULD care about changes to the system itself)
Also re the framing, abstention does not count “towards” for or against which is why it’s so valuable. Deferring to the crowd when you don’t care or to experts when you’re not knowledgeable is a net benefit and a much more intuitive way to wield your individual governance power
I’d suggest that this is a feature, not a bug. In fact, I’d go as far as to say this is just about the whole point of the abstain option . If you don’t want to your vote weight to count towards quorum, then you can simply not cast a vote for any option.
I’d suggest that the only proposals that should make it to the Snapshot space with SafeSnap enabled are those that would trigger some on-chain action. In which case, voting should probably be limited to the “Basic voting” option, rather than the current “Single choice voting” option. Perhaps a sub-space could be used for proposals that aren’t intended to have on-chain execution, and this could be more permissive about the type of voting.
Appreciate the desire to improve the governance process, thanks for putting this together @theobtl
I feel that if there were ways to gain more soft consensus, we could massage some of the options before they ever reach snapshot. For instance on SEP #3, if we had a way to soft-signal which of the milestones were desirable to the community, the snapshot vote could have been yes/no without much fuss and muss. Non-binding polls on Discourse, for instance, could have helped.
Agree with others that abstain counting towards quorum is actually a feature, not a bug. The way you have described abstentions is exactly how they are supposed to work in Robert’s Rules of Order
Who is it that desires the use of SafeSnap? I fear that requiring a code snippet for all proposals will really reduce who can participate in governance. Personally I feel strongly that a governance process should be accessible.
In general my biggest issue with the current governance is the lack of clarity and certain centralized points (i.e. how proposals get numbered as SEPs, which proposals end up on Twitter, etc). Perhaps @adamhurwitz.eth 's work on HackMD could be used to start creating a governance handbook, so that we can point new contributors to a documented governance process?
Excited about the discussion of the governance framework. hope that we are able to quickly discuss the shaping scheme and provide a complete operational efficiency impetus for safedao to make the governance process be accessible.
1/ The snapshot voting time should be shortened, three days is enough for those who pay attention to safe, and the extra time for those who do not pay attention to safe is useless.
2/ The time for discussing proposals should be shortened. It is obviously meaningless to discuss some proposals for one month or even two months. Opinions can be quickly reached and voted on. If there is any problem, they can vote again to change.
3/ Efficiency Efficiency Efficiency, the time wasted in every link of our governance is too long. If we don’t speed up the progress, the earth will perish.
Depends what you mean by “efficient”. If you are trying to optimize time to change, less time is desirable, but if you are trying to optimize outcomes, additional time will allow additional people to weigh in and (maybe) create a more optimal output.
In bureaucratic governments, the time to change is high, but this weakness is also a strength - slow changes mean that the government machinery isn’t constantly switching directions, which allows slower, but reliable progress.
Obviously no one wants Safe to be a bureaucratic entity, but I think over correcting for speed at the cost of everything else would also be a mistake. That’s how exploits happen. We need a balanced approach.
1/You are right, we need enough time to discuss proposals, but what I want to say is that we need to set a deadline for this time and strictly implement it. I have seen that some proposals have been discussed for more than three months. In the discussion, and there are very few people discussing it, which drags down the progress of Safe’s governance. To sum up, we need to set a definite time limit for each governance process and strictly enforce it instead of meaningless delays.
I get where you’re coming from and I agree that we can use some structure to check on proposals over their lifetime and archive them, if appropriate. However, I wonder whether a strict rule is the solution here. I wouldn’t want to introduce a rule when no rule is needed (less bureaucracy, minimising governance). Rules are never complete and, at some point, there will probably a proposal that must be discarded as specified in a rule while author+community in fact agree that it should not be discarded.
To mention examples of proposal currently in phases 1 or 0:
all proposal in phase 1 have been uploaded to Snapshot or are on track
SAFE Token Utility Proposal deals with a particularly complex matter (token design) which should prioritise quality and not be constrained by an artificial deadline, IMO
[SEP #X] Improve Communication in SafeDAO has partially been implemented without requiring a formal vote (Discord channel), was partially already in place (community call) and remains a useful thread to discuss how we can improve our communication. For that reason, I’d rather not archive it but keep it open, either as a proposal or as a non-proposal thread for continued discussion.
Instead, I’d rather suggest that we focus on soft governance here, e.g. moderation guidelines that me and the team will follow as well as guidelines for authors to communicate where they stand with their proposal and what kind of support they need to bring it to a final vote.
Technically, proposals that reach phase 1 have actually very few constraints and can move quickly. The current governance process requires a proposal to be in phase 1 for no more than six days, while the amendment proposal discussed in this thread considers an extension of six days after edits. Practically, a proposal author could ignore any comments and move their proposal to Snapshot as soon as a week after it has moved to phase 1 - nobody can prevent that. If there are substantial concerns voiced in the comments which the author ignores, I would expect the proposal to be voted down by the community out of principle – my point is just that the proposal author is free to do so.
This is different for phase 0 proposals:
I agree with @links that the labeling of SEPs (i.e., moving proposals from phase 0 to phase 1) is more of an issue. Currently, labelling SEPs is done by forum admins, usually myself. This has so far been a case-by-case decision where I was in touch with the author, evaluating whether a proposal is mature enough so that can realistically be finalised in six days. There’s also a trade-off in preserving attention span of our vast community: Relatively speaking, we have many proposal in phase 0 and few in phase 1 at any given time. Phase 1 proposal arguably deserve wider attention (including a Twitter shoutout on safegovernance), whereas phase 0 proposal should be refined first.
No doubt that this process can be improved. I’m thinking of at least two parts here:
Defining what makes a “mature” proposal and introducing some transparency on what has been case-by-case decision making
Extending the group of admins from myself and team members to others, e.g. selected Guardians
I’ll add this point to the list in the original thread above.
Alongside adding this point, I’ve revised the section “List short-term pain points for discussion” to reflect previous comments on 2. “Abstain” and 4. “SafeSnap”.
Does anyone have further comments on the list of five issues in the first thread?
Would anyone like to add further issues to this list which should be considered for a “Governance Process v2” amendment proposal, improving our current governance process?
Once we have broadly evaluated the scope of such a “Governance Process v2” amendment proposal, I would write that up in an actual phase 0 proposal. Worth discussing here at this time is the scope: Some improvements are needed and useful to introduce in the short-term. Other governance improvements are useful too, but blocked by other issues (see introduction to this thread) and should be discussed here, but not yet included in a short-term “Governance Process v2” amendment proposal.
Another potential solution would be to have soft-signal quorum requirements. i.e. you need at least x SAFE holders voting this proposal is ready to move onto the next step. It might not work this early in the governance process, but I thought I’d post it as a possible solution that could work in concert with the others you mentioned.
I think people who participate in governance should be rewarded, which will increase people’s enthusiasm for participating in governance and improve the efficiency of governance. You can get the governance token wsafe by pledging safe, and vote with wsafe to get safe rewards.
Standards for proposal initiation can also be introduced. For example, a certain amount of safe is required to initiate a proposal. For malicious proposals, sanctions can be used to punish the safe pledged by the proposer. This is my initial idea, everyone can give their own opinions, thank you.
I think one of the very obvious shortcomings of SafeDAO is: Those participating in the forum discussions are only a small percentage of safedao members(also small percentage in voting power), and many people will only participate in the discussions after the official Twitter @safe@safegovernance announces the proposal.
In fact, the proposals under discussion need to receive more attention to ensure that the opinions of the majority of DAO members are fully considered before the proposals enter the vote.
I think these proposals need to be retweeted by the official twitter immediately, because the proposal author is obviously trying to solicit the opinions of the community, if there is not enough feedback during the discussion stage, the proposal may enter the vote in an imperfect status.
And there is another important point, I think all temperature check votes must retweet by the official twitter, otherwise the temperature check is meaningless, SafeDAO needs to make full use of and play the role of temperature check.
In other words, I propose that temperature checks become a necessary part of the governance process, and that all temperature check votes must be announced by the official twitter to ensure full participation.
I don’t think people with 12 million safe will not look at the forum, they just don’t want to express their opinion and then express their thoughts through the final vote, I think it is completely wrong to look at how many safe votes are used to determine whether the vote is mature, but to see how many addresses participated in the vote. The situation now is that even if most of us are in favor of a proposal, the owner of 12 million safe addresses can control the outcome of the proposal. So to sum up, the problem you raised is simply not a solution, because giant whales are always arrogant.
It can be seen from the security check snapshot that the first security snapshot has 617 people participating in the vote, the second time is 836 people, and the safe governance is getting healthier and healthier, but it is so that 836 people have 3 million safes, but the whale has 8 million sa fe at a single address, so it is really wrong to use the number of safe to judge whether the proposal is mature, I can only say that the results of our proposal are currently manipulated by giant whales.
So I think it’s necessary to allocate unclaimed airdrops to active governors to make governance more decentralized, and in cases where safe can’t be transferred, I think it’s the best option to make safe more decentralized.
Establish a clear path for revisiting rejected proposals
Initial ideas
Introduce temperature check phase for SEPs
Implement a process for re-evaluating unsuccessful proposals
I appreciate the initiative taken in starting this thread to gather feedback and identify areas for improvement within the SafeDAO Governance Process. Based on the purpose and desired output of this thread, I’d like to contribute by addressing the issue of:
Lack of Initial Proposal Screening: right now there is not official process for screening SEPs, where proposals that lacks community interest or support could advance to the voting stage, resulting in wasted time and effort. Proposals that do not generate sufficient interest can consume valuable community resources that could be allocated to more promising initiatives.
No Clear Path for Revisiting Rejected Proposals: In the absence of a defined process for re-evaluating unsuccessful proposals, valuable ideas may be lost or overlooked due to initial rejection.
Here are some of my initial ideas on how we could effectively tackle these problems:
Temperature Check Phase for SEPs - The temperature check serves as an initial indicator of community interest and sentiment towards a proposed change. This helps ensure that only proposals with substantial support progress to the voting stage, promoting active community engagement and meaningful discussions. Eg. Uniswap temperature check.
Re-evaluating Unsuccessful Proposals
Implementing a process for re-evaluating unsuccessful proposals could address the current lack of guidelines for revisiting rejected proposals, fostering continuous improvement within the SafeDAO ecosystem. Here are some suggestions for integrating this aspect into the governance process:
Introduce a “cooling-off period” for unsuccessful proposals, granting authors time to refine their proposals and gather additional feedback from the community.
Urge authors of rejected proposals to collaborate with other community members or stakeholders to refine their ideas and address concerns raised during the initial voting process.
Create a dedicated forum section or thread for discussing and refining rejected proposals, offering a platform for community members to exchange thoughts and suggestions.
Adopt a transparent tracking system for rejected proposals, enabling community members to monitor the author’s progress and refinements, and express their interest in reconsidering a specific proposal.
I look forward to further discussions and insights from fellow community members to help refine these ideas and help ultimately shape the upcoming ‘Governance Process v2’ proposal.
. If you don’t want to your vote weight to count towards quorum, then you can simply not cast a vote for any option.
Safe open guides
