This proposal was previously posted in Phase 0 discussion: [Discussion] Governance amendment Season 1 / Sprint 4
It has been copied below for legibility. This post follows the “[Template] Initiative proposals” template found here.
[Draft] Governance amendment Season 1 / Sprint 4
As we are progressing through Season 1, the 4th sprint of every season also serves for a scheduled governance review and amendment phase. We’ve gathered valuable insights from our previous sprints and identified areas for improvement and adaptation. We propose a few changes which reflect some of the learning from the previous sprints, anticipate some challenges in the future, and prepare for new technical opportunities.
We are proposing five key amendments to our governance processes:
- Introduction of partial delegation
- Revised voting mechanism for OBRA initiatives to not run into budgeting problems
- Adjustments to voting timeline to reflect Snapshot settings and voting in the last sprints
- Extension of soft launch for Season 2
- Clarification for OBRA initiatives with implementation dependencies
1. Introduction of partial delegation
Gnosis Guild is currently working with Snapshot on a technical implementation to allow partial offchain delegation (see the current OBRA proposal). Partial delegation would allow larger token holders to delegate parts of their voting power separately. This aims to increase voter turnout and foster a higher amount and more diverse range of delegates.
2. Revised voting mechanism for OBRA initiatives
To prevent initiatives from exceeding the respective budget of the strategies, we’re updating how OBRA initiatives are being voted on. While maintaining separate votes for each initiative, we will introduce a ranking system for approved initiatives based on the voting power each initiative received. This will help manage budget constraints effectively, with a cut-off point when the pre-set budget is met. Initiatives below this threshold can still be funded by the wildcard strategy if there is a remaining budget. Shoutout to @Lindsey for pointing out this problem in one of the governance calls!
3. Adjustments to voting timeline
As mentioned here, we had to deviate slightly from the timelines outlined in the governance framework as Snapshot does not allow to enforce start/end dates on a space level, but only for each proposal. Therefore we chose to enforce a 12-day voting period, which starts in the course of Wednesday instead of Thursday and still always ends on Monday. The governance framework has every deadline on a Monday (Start of new sprint, Phase 1 submission, signaling of delegates/guardians and end of voting period). The changes reflect the voting windows of the last sprints and clarify that the submission to Snapshot can be done in the course of Wednesday, not necessarily exactly 23.59 UTC.
4. Extension of soft launch for Season 2
Season 1 is operating under a soft launch which would have allowed us to deviate from the governance cycles if needed. This could be useful in two cases:
- Make changes to governance related topics such as OBRA mid-season and not just in the 4th sprint.
- Vote non-governance SEPs in Sprint 4 if needed.
For Season 1 deviations were not needed, however as OBRA only really ramps up in Season 2 this flexibility could still be beneficial. This would also be in line with the soft launch provision in OBRA.
5. Clarification for OBRA initiatives with implementation dependencies
If OBRA initiatives require a previous change in the governance processes or has any other dependency, then the funding approval shall generally be dependent on the previous approval and implementation of the dependency. This reduces the risks that initiatives are being funded for which the necessary conditions have not yet been established.
Here is a google doc representing the changes: [Discussion] Governance amendment Season 1 / Sprint 4 - Google Docs
Below are the amendments needed to implement the above changes.
Title: [SEP #11] Governance amendment Season 1 / Sprint 4
Authors: Andre Geest (Safe, @Andre) , Bernard Schmid (Areta, @bernard)
Created: 2024-26-01
Abstract
In Season 1, the 4th sprint includes a governance review and amendment phase. Based on insights from previous sprints, we propose changes to address improvements and anticipate future challenges and technical opportunities.
Proposal types
State which proposal type this proposal belongs to.
SEP: Constitutional Proposals
SEP: Governance Proposals
Other SEPs
Proposal details
Purpose and Background
What problem does it solve? What is the reasoning behind the proposal? What is the goal? Why should SafeDAO care about the proposal?
We are proposing the following changes to the SafeDAO governance processes:
- Introduction of partial delegation
- Revised voting mechanism for OBRA initiatives to not run into budgeting problems
- Adjustments to voting timeline to reflect Snapshot settings and voting in the last sprints
- Extension of soft launch for Season 2
- Clarification for OBRA initiatives with implementation dependencies
Changes to the Governance Framework
| Original | New |
|---|---|
| B. Stakeholder overview II. Delegates 1. Delegation process |
B. Stakeholder overview II. Delegates 1. Delegation process |
| The delegation process is offchain. Token holders can delegate their votes to any address of their choice. The current delegation system requires full delegation of the voting power. Partial delegation may be implemented. Token holders can redelegate or undelegate at any time. | The delegation process is offchain. Token holders can delegate their votes to any address of their choice. The current delegation system requires full delegation of the voting power. Token holders may delegate their voting power among multiple delegates in varying ratios (partial delegation). Token holders can redelegate or undelegate at any time. |
| 2. Rights | 2. Rights |
| Delegates can vote on behalf of token holders who delegated their voting rights to them. Delegates may not delegate their delegated voting right to someone else. | Delegates can vote on behalf of token holders or delegates who delegated their voting rights to them. Delegates can delegate their |
| Transition period: These changes only enter into effect in the sprint following the technical implementation on the Snapshot space. |
| Original | New |
|---|---|
| C. Scope of governance II. Proposal types |
C. Scope of governance II. Proposal types |
| SEP: Governance Proposals // Changes to the governance framework and the resource allocation framework // offchain | SEP: Governance Proposals // Changes to the governance framework and the resource allocation framework // offchain SEP: OBRA Initiative Proposals // Approval of funding for an initiative // off-/onchain |
| Original | New |
|---|---|
| D. Dynamic governance II. Governance cycles |
D. Dynamic governance II. Governance cycles |
| Other SEPs; Grants Council Nominations for SGP | Other SEPs; Grants Council Nominations for SGP, initiative approvals |
| Original | New |
|---|---|
| E. Decision-making process II. Proposal and voting sprints |
E. Decision-making process II. Proposal and voting sprints |
| Week 3 // Submission to Snapshot // Tuesday // 23:59 UTC // Deadline submission of eligible proposals to Snapshot | Week 3 // Submission to Snapshot // Tuesday // 0:01 UTC - 23:59 UTC // |
| Week 3 // Voting // Wednesday // 0:01 UTC // Start voting delay | Week 3 // Voting // Wednesday // 0:01 UTC - 23:59 UTC // End |
| Week 3 // Voting // Thursday // 0:01 UTC // Voting starts | Week 3 // Voting // Wednesday |
| Week 5 // Voting // Monday // 23:59 UTC // Voting ends | Week 5 // Voting // Monday // 0:01 UTC - 23:59 UTC // Voting ends |
| Original | New |
|---|---|
| E. Decision-making process V. Phase 2: Voting process 1. Voting system |
E. Decision-making process V. Phase 2: Voting process 1. Voting system |
| Voting type: Single choice, multiple choice, weighted voting | Voting type: Single choice, multiple choice, weighted voting, single choice approval with sequential ranking |
Additional context on the newly added voting option:
Single choice approval with sequential ranking
Single choice approval with sequential ranking is a two-step process used for SEP: OBRA Initiative proposals. It determines which OBRA initiatives can get funded within the budget of an OBRA strategy:
-
- Approval voting: Participants allocate their voting power to express approval (‘Yes’) or disapproval (‘No’) for each proposed project. This phase determines which projects have the majority support based on the accumulated weighted ‘Yes’ votes.
-
- Sequential Ranking: Projects that received a majority of ‘Yes’ votes are then ranked according to the total voting power in favor of them.
Funding is then allocated to the projects in the order of their ranking, up to the point where the budget limit of the specific strategy is reached. Projects ranked below the budget cutoff point can be funded (if available) partially by the remaining budget of the relevant strategy and the remaining amount of the wildcard strategy. Initiatives applying directly for the wildcard strategy and initiatives that would exceed the budget of a different strategy are ranked in the same category. This method ensures that only the most favored and viable projects, as determined by voter approval and ranking, are funded within the constraints of the available budget.
| Original | New |
|---|---|
| E. Decision-making process V. Phase 2: Voting process 4. Voting power b. Delegated voting power |
E. Decision-making process V. Phase 2: Voting process 4. Voting power b. Delegated voting power |
| Delegates may vote on behalf of token holders that delegated voting rights to them. Delegation does not restrict token holders from voting themselves; in the event of token holders exercising their voting rights, their vote takes precedence over any vote cast by their delegate. Token holders can delegate or redelegate any time. | Delegates may vote on behalf of token holders or delegates that delegated voting rights to them. Delegation |
| Transition period: These changes only enter into effect in the sprint following the technical implementation on the Snapshot space. |
| Original | New |
|---|---|
| H. Annex 1: Season 1 | H. Annex 1: Season 1 and 2 |
| For the inaugural season, Season 1, the goal is to utilize the new governance framework in practice and gather experience. Therefore the changes to the voting types are minimal, only adding multiple choice voting. For Season 1, the governance framework will operate under a soft launch protocol. Recognizing the need for flexibility during the formative phase of SafeDAO, the Foundation retains the prerogative to deviate from the processes laid out in D.II. Governance cycles and E.II. Proposal and voting sprints if necessary to ensure an efficient decision-making process. Any deviations will be communicated transparently and are subject to review in the review and governance amendment sprint. This exception is limited to Season 1 and is introduced to allow a smoother transition into the new governance framework. |
For the inaugural season, Season 1 and 2, the goal is to utilize the new governance framework in practice and gather experience. Therefore the changes to the voting types are minimal, only adding multiple choice voting. For Season 1 and 2, the governance framework will operate under a soft launch protocol. Recognizing the need for flexibility during the formative phase of SafeDAO, the Foundation retains the prerogative to deviate from the processes laid out in D.II. Governance cycles and E.II. Proposal and voting sprints if necessary to ensure an efficient decision-making process. Any deviations will be communicated transparently and are subject to review in the review and governance amendment sprint. This exception is limited to Season 1 and is introduced to allow a smoother transition into the new governance framework. |
| - | SEP: OBRA Initiative Proposals // 10.000.000 SAFE // Simple majority // Single choice approval with sequential ranking // Public |
Changes to OBRA
| Original | New |
|---|---|
| - | E. Implementation dependencies If the implementation of an initiative requires any prior changes in the current governance processes, e.g., amendments to the governance framework, or has any other dependency, the approval of the initiative generally shall be dependent on the previous approval and (if necessary) successful implementation of such governance amendment or any other dependency. |
| E. Implementation dependencies |
| Original | New |
|---|---|
| F. Soft launch | |
| This exception is limited to Season 1 and is introduced to allow a smoother transition into the new resource allocation framework. | This exception is limited to Season 1 and 2, introduced to allow a smoother transition into the new resource allocation framework. |
Effects and Impact Analysis
What are the effects of the proposal? What are the pros and cons? What are risks?
The proposed amendments collectively aim to streamline SafeDAO’s governance process, making it more efficient and responsive to individual circumstances. By introducing mechanisms such as partial delegation, extension of voting mechanisms, and a revised voting mechanism for OBRA initiatives, the governance framework becomes more adaptable and capable of reflecting more granular interests of its members. Further, these amendments will result in lowering barriers to participation and encouraging a broader section of the community to engage in SafeDAO governance.
The main risks are that amendments in nuanced voting processes or delegation models can increase the complexity of participation for SafeDAO members, potentially making it more difficult to engage in governance, and that executing the amendments may increase the burden on the technical implementation side. However, we believe that we can mitigate this by maintaining our focus on educating our members and by recognizing that the advantages outweigh these risks.
Alternative Solutions
What alternative solutions have been considered? Why have they been discarded?
An alternative solution is to not change the governance framework. While this is possible, it would mean not incorporating our learnings into the optimization of governance, which we aim to do continuously. This approach wouldn’t necessarily present a major blocker, but it could slow down our pace of progression.
Implementation
Does the implementation of the proposal require new code? How is the security of the code ensured? How is the implementation of the proposal carried out?
Own implementation possible
Own implementation but with funding (how much % to implementation)
Request for technical support through Safe matter experts:
-
Who is needed?
-
Did you reach out?
-
Is there a roadmap?
Open Questions
Anything that needs to be cleared up before the community can make an informed decision?
None
**Acknowledgements
Special thanks to @Lindsey (Hedgey), @auryn (Gnosis Guild) and @adamhurwitz.eth for their contributions and feedback.
Copyright
Copyright and related rights waived via CC0.