[SEP #11] Governance amendment Season 1 / Sprint 4

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

[X] 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 overviewII. Delegates1. Delegation process | B. Stakeholder overviewII. Delegates1. 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 ~~delegated~~ voting power (including voting power delegated to them by others) to someone else. | | | Transition period: These changes only enter into effect in the sprint following the technical implementation on the Snapshot space. |

| Original | New | |---|---| | C. Scope of governanceII. Proposal types | C. Scope of governanceII. 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 // offchainSEP: OBRA Initiative Proposals // Approval of funding for an initiative // off-/onchain |

| Original | New | |---|---| | D. Dynamic governanceII. Governance cycles | D. Dynamic governanceII. Governance cycles | | Other SEPs; Grants Council Nominations for SGP | Other SEPs; Grants Council Nominations for SGP, initiative approvals |

| Original | New | |---|---| | E. Decision-making processII. Proposal and voting sprints | E. Decision-making processII. 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 // ~~Deadline~~ Submission of eligible proposals to Snapshot + start voting delay | | Week 3 // Voting // Wednesday // 0:01 UTC // Start voting delay | Week 3 // Voting // Wednesday // 0:01 UTC - 23:59 UTC // End~~Start~~ voting delay (24h after start of voting delay) | | Week 3 // Voting // Thursday // 0:01 UTC // Voting starts | Week 3 // Voting // Wednesday~~Thursday~~ // 0:01 UTC - 23:59 UTC // Voting starts | | 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 processV. Phase 2: Voting process1. Voting system | E. Decision-making processV. Phase 2: Voting process1. 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:

• 1. 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.
• 2. 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 processV. Phase 2: Voting process4. Voting powerb. Delegated voting power | E. Decision-making processV. Phase 2: Voting process4. Voting powerb. 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 ~~does not~~ restricts 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.~~ However, t~~T~~oken holders can delegate or redelegate any time. | | | 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 | ~~E~~F. Compliance with relevant regulations |

| Original | New | |---|---| | F. Soft launch | ~~F~~G. 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?

[X] 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.