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

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:

  1. Make changes to governance related topics such as OBRA mid-season and not just in the 4th sprint.
  2. 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 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 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 // 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 // EndStart voting delay (24h after start of voting delay)
Week 3 // Voting // Thursday // 0:01 UTC // Voting starts Week 3 // Voting // WednesdayThursday // 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 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:

    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.
    1. 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 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, tToken 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 EF. Compliance with relevant regulations
Original New
F. Soft launch FG. 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.

6 Likes

As a delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes

As a delegate with sufficient voting power , I can confirm that this is ready to move to a vote!

1 Like

Thanks @Andre for these timely amendments to the DAO’s governance processes.

As a delegate with sufficient voting power , I consider this proposal ready to move to a vote.

1 Like

Appreciate you advocating for these changes, @Andre.
As a delegate with sufficient voting power , I believe this is ready for a vote!

1 Like

@Andre, I thought of 2 additional improvements that can help improve the quality of proposals that make it to the voting stage. This will also help save DAO member’s time of the back-and-forth of requesting basic proposal info that can be spent on higher quality discussion.

  • Proposal template: Require that proposals outline the estimated amount of time and funding for each deliverable in the “Timeline and milestones” section. StableLab and Gnosis Guild’s proposals have great examples of this format for this section.
  • Move from phase 1 to phase 2: Signaling approval requires that the proposal template is complete.

In the current form it seems that there is a risk of moving proposals to the voting stage that allocate funds to undefined activities and results.

3 Likes

I’ve submitted proposed updates to André for the OBRA proposal template to help further improve the quality of submissions moving forward and reduce the back and forth of requesting important proposal info from authors. It’s great to see many high quality submissions so far!

To update my second bullet point above, signaling approval of a proposal already requires that the proposal template is complete thanks to the governance framework passed in SEP-7.

See E. Decision-making process > III. Proposal submission > 2. Phase 1: Official draft stage

If the authors determined by a self-assessment believe that the proposal is mature enough to vote on it (either after Phase 0 or directly), then it must be

  • Submitted as a new discussion thread on the forum in Phase 1.
  • If there was a previous discussion in Phase 0 add a link to it.
  • Marked with [Draft] in the title.
  • Formatted and contain information consistent with the proposal template in Annex 2.
2 Likes