Simple Summary

This proposal seeks to elevate the current Synthetix Governance System from V2 to V3, introducing two new governance structures (Core Contributor Committee & Treasury Committee), addresses pain-points identified in Governance V2 (first iteration of delegated governance), proposes to shift responsibilities around and defines meta-governance processes to improve the efficiency and self-autonomy of the Synthetix DAOs.

Abstract

If this proposal is approved and adopted, the following subsets of the Synthetix Governance system will be implemented

• Ratify the Core Contributor Committee through SIP-161
• Deprecate the Synthetix DAO (sDAO) and establish the Treasury Council SIP-155
• Formalise the ownership and responsibilities of the DAOs in relation to their dApps
• Amalgamation of the governance forums, elections and nomination processes into a single dApp
• Create a formal specification of the election and nomination timelines and processes
• Formally address meta-governance processes and issues that have been identified

Motivation

Since the introduction of SIP-93 which ratified the Spartan Council and paved the way for the establishment of the grantsDAO and ambassadorDAO. The protocol has been able to decentralize a majority of its decision-making responsibilities into separate governance bodies.

However, there still exists some governing bodies that are still yet to be transitioned to be in-line with the new decentralized governance of the Synthetix Protocol. These bodies still have privileged roles that are not decided in the same democratic way that the existing DAOs are. A portion of this SIP aims to finalize this transition by ratifying a Core Contributor Committee and Treasury Council.

The remainder of this proposal then addresses the cumbersome problems discovered in the Governance V2 mechanisms such as the:

• Nomination, elections and hand-off processes of the DAOs
• Transparency and accessibility of governance debates and discussions
• Review and executions of SIPs/SCCPs
• Coordination between the DAOs, especially the Spartan Council and the Core Contributors

Which have historically been addressed according to discretion and experimentation.

Specification

An high-level overview of what Synthetix Protocol Governance V3 will look like, defining the major DAOs, stakeholders and interactions between them.

Table of Topics:

1. Treasury Council
2. Core Contributor Committee
3. Empower Spartan Council with SCCP execution powers
4. Metagovernance dApp
5. Staking dApp Governance
6. Meta-Governance Processes

Treasury Council

Overview

Introduced in SIP-155

Core Contributor Committee

Overview

Introduced in SIP-161

Empower Spartan Council with SCCP execution powers

Overview

The Spartan Council has been operating for nearly 6 months autonomously signalling on SIPs/SCCPs using their NFT voting weight on snapshot. The intention of this proposal is to start deprecating the protocolDAO which requires transitioning its powers to the Spartan Council. To kick-start the initial transition of power, the Spartan Council multisig will be added to the SystemSettings contract as an owner allowing them to control most high-level SCCPs.

Rationale

The sole intention of the Spartan Council was to have it responsible for debating/executing protocol changes, so far the process has been successful with the Spartan Council owning the debating/voting and the protocolDAO handling the execution/transactions.

The protocolDAO in the current state exists as a legacy system due to the absence of a legitimate system in which the members are selected and the separation of powers have not only been attack vector for centralization but also represents a significant overhead due to the amount of communications and logistics required across different timezones. However, since the recent governance changes came after the initial V2 of the Synthetix Protocol, a lot of the contracts are not optimized for a delegated governance system except for the SystemSettings contracts which determines high-level SCCP changes.

By enabling the Spartan Council to take up the SCCP process, we can start moving towards the deprecation of the protocolDAO while still being able to conduct low-risk experiments until both the V3 contracts (which will support delegated governance) and the finalization of the V3 governance scope is achieved.

Technical Specification

In the System Settings contract, the owner which is currently set to 0xeb3107117fead7de89cd14d463d340a2e6917769 will be set to the Spartan Council Multisig Address 0x432B5fD638513bFdB6b4e5c6CC4274cB45d79bd7. They will then be able to enact any SCCPs regarding the Synthetix Protocol (with the exclusion of OVM contracts and parameters relating to inflation RewardDistribution until these contracts are reworked in V3).

The Spartan Council will then be responsible in openly communicating to the Core Contributors and Community when the Spartan Council has enacted changes in order for these Stakeholders to consider the changes in their decision-making process.

The protocolDAO which currently handles the releases, is responsible for letting the Spartan Council know when the SystemSettings contract is updated and must take steps to assign the Spartan Council multisig as the owner.

Test Cases/Examples

1. A community member has proposed to lower the collaterisation ratio to 300%, they draft up a SCCP and publish it on the SIPs Site.
2. The Spartan Council debate the change and it gets called to a vote.
3. The snapshot proposal covering the SCCP successfully passes
4. The Spartan Council stages a transaction using their multisig, to the System Settings contract calling setIssuanceRatio
5. The Spartan Council then band together, each of them signing/confirming the transaction (the number of signatures will be supermajority i.e 8 members mean 5/8 signers needed)
6. The Spartan Council announces that the changes are done and ensure that the relevant Stakeholders are aware.

Metagovernance dApp

Overview

The introduction of a Metagovernance dApp which focuses on building infrastructure to carry out self-nominations and house nominee profiles and elections aims to further automate the election process whilst helping voters make more informed decisions when voting for critical components of the Synthetix Governance System (DAOs).

Rationale

There has been significant friction in the nomination and election processes carried out every epoch in which members are voted in by the Synthetix Token holders to serve in their respective DAOs.

In the current process of nominations, there is a high-level of centralization and friction, requiring Core Contributors to monitor the Discord channels and nominees (wallet address and discord identities) to a Google Spreadsheet. This presents several attack vectors including:

1. Not being censorship resistant
2. High chance of human error (forgetting or missing discord messages)
3. Not being immutable (spreadsheets can be changed by admins)

The election process is also very fragile where voters are not well-informed and cannot easily access information relevant (nomination campaigns/pitches and voting history) to voters when making a critical decision. The process currently has a high-level of technical overhead requiring Core Contributor engineers to manually match wallet addresses to discord identities in the proposal to alleviate some voting friction.

Technical Specification

A new frontend will be designed and developed which encapsulates the nomination and election processes for all the Synthetix Community elected DAOs.

As of writing this includes the:

• Spartan Council
• Treasury Council
• ambassadorDAO
• grantsDAO

Apart from the design which will be conducted by a Core Contributor, the dApp will be closely developed with the following projects:

• Collab.Land
• Ceramic Network
• Snapshot

Collab.Land

Collab.Land will be providing infrastructure for the dApp login/registration process, allowing for users to link a discord identity to a wallet address and vice-versa. The Synthetix Discord server will also receive power-ups including: in-channel voting and notifications.

Ceramic Network

The Ceramic Network Protocol will be built on-top of the identities generated by Collab.Land, empowering users to create profiles for their wallet/identities which will be used for creating election pitches/campaigns.

Snapshot

The Synthetix Governance system heavy relies on Snapshot's gas-less voting infrastructure, we will continue to use this system but take steps to further simplify and automate the process with the addition of the identity features above.

Test Cases/Examples

Linking a wallet to discord

A user visits the meta-governance dApp, they connect their wallet via onboard.js. If they have not linked their currently selected wallet to an identity there will be a prompt to do so.

Using Collab.Land infrastructure, a custom authentication flow will allow the user to connect their wallet to a discord identity (via signatures). This will be stored and used throughout the dApp.

Editing a wallet profile

When a user has connected to the meta-governance dApp, they can visit their wallet profile page. This page will feature important governance statistics, activity and content hosted by Ceramic.Network.

A user can prove that they own the current wallet via a signature which then allows them to edit bio/pitches and other front-facing details and publish it.

Nomination Process

When the nomination period is open, users who are connected to a wallet are able to nominate themselves for a particular DAO. They do this via a signature with their wallet.

The dApp will be able to make use of their connected discord identity to help display the nominees in a familiar way.

All nominees are required to fill in their pitch to be displayed during the election process.

Election Process

When the election starts, any user can browse the current elections that are running. Here they can see the nominees for each DAO and explore their pitches, profiles and voting histories.

A connected user is then able to vote via snapshot on the election.

Staking dApp Governance

Overview

Redesign and incorporate the new meta-governance features into the staking dApp replacing the current governance flow.

Rationale

Historically the only two places the elections were being surfaced to users were the

1. Staking dApp
2. Directly on snapshot

With the introduction of the third method being the meta-governance dApp, it is still important that the elections are still accessible within the staking dApp as this is still the main destination of the Synthetix stakeholders (due to weekly rewards and debt management), ensuring that the voting of elections is low-friction and the voter engagement remains high.

With the new infrastructure being introduced to the meta-governance dApp, it is a suitable time to rework the flow in the Staking dApp to further improve this process.

Technical Specification

Rework Governance Section Positioning

The Governance Section should be surfaced on the landing page of the dApp (along side the available user actions) as its a essential responsibility of the Synthetix Stakers.

This dedicated section will be the main object returning users will see, and show important notification/information messages as well as link out to the meta-governance dApp where they can explore more.

Quick Vote Function

During an election period, Synthetix Stakers are required to vote before they can claim their rewards. A quick vote function will be integrated within the claiming rewards such that it is low-friction.

Test Cases/Examples

TBD

Meta-Governance Processes

Overview

This section attempts to address the most prevalent problems and edge-cases in the meta-governing of the DAOs.

Rationale

_The DAOs govern specific responsibilities in their domain, but who governs the DAOs? _

The answer to this is complex, on one hand it might be the Synthetix Token Voters who signal how a DAO should operate based on their who they elect and on the other hand it might be the Treasury Council who provide the stipends and incentives for the DAOs to operate.

In both cases, DAOs require some sort of guidance in their meta-governance processes to maintain consistency + accountability in their actions and this section attempts to voice the community and DAO concerns by addressing some of the uncertainty in some critical actions.

This section is by no-means final and processes should be revisited redefined with the reiteration of Synthetix Governance via meta-governance SIPs (a new sub-category of SIPs that require unanimous votes by the SC).

Specification

Election & Nomination Timeline

T -4 weeks:

• T -4 weeks Day 1
  • Automated system-wide notification / information message* (A general message stating that the Epoch is nearing its end).

T -3 weeks:

• T -3 weeks Day 1
  • Automated system-wide notification / information message* (To signify the opening of nominations).
  • Automatically open up the nominations features on the meta-governance dApp - allowing users to nominate themselves for a specific DAO.
  • Auto-post new nomination registrations (profile & pitches) to discord to dedicated a read-only Discord channel.
• T -3 weeks Day 7
  • Auto-close nominations on the meta-governance dApp.
  • Schedule an election for each DAO on snapshot with the nominees.

T -2 weeks:

• T -2 weeks Day 1
  • Automated system-wide notification / information message* (To announce that the nominations are closed and voting has started).
  • Voting starts on the election proposals.
• T -2 weeks Day 14
  • Voting ends on the election proposals.

T = 0:

• T Day 0
  • Automated system-wide notification / information message* (To announce the start of a new governance epoch).
  • Publish the voting results in discord and socials.
  • Auto assign the new Discord roles.
  • DAOs then initiate their Handover Processes**, if new members join.

*Staking dApp, Gov Website, Discord, Twitter

**Handover Processes defined below

DAO Responsibilities

Technical & Resourcing

Each DAO and Council will be responsible for the maintenance and management of their dApps, social media, auxiliary tools and smart contracts. It is important that the DAOs utilise the #all-daos channel to knowledge share.

Funding and resourcing for website & smart contract design, development and maintenance can be requested from the grantsDAO.

Funding and payment for 3rd party software need to be submitted to the Treasurey Council for approval.

Handover Process

The intent of this SIP is not to inform the Councils and DAOs on how to manage their internal Handover Process, only to ensure that they are accountable for fulfilling & managing this process.

Critical elements of the Handover Process includes:

• Internal operating procedures
• Transfer and management of multi-sig owners
• Transferring access to DAO socials (i.e Discord & Twitter) and tools.

Test Cases/Examples

The intent is to clarify the process to follow during abnormal situations outside of the normal operating procedures. We will present this in the form of an Q&A:

Q: Can someone from the community nominate another person on their behalf? A: No. The community can signal their support for someone to nominate for a DAO but an individual can only nominate themselves via the meta-governance dApp.

Q: What happens when a nominated user wants to withdraw during the voting period? A: The nominee must inform the community in ample time to allow the voters to reallocate their votes.

Q: What happens when a nominated user rejects their seat after the voting period? A: The next runner-up in the finalized election will be automatically appointed in the place of this individual, if there is no runner-up then the Stand-In Procedure applies.

Q: What is the Stand-In Procedure? A: The DAO in question approaches other DAOs to see if one of their elected members can help supplement the missing role. If other DAOs are not willing/unable to support, the Core Contributors can be called upon to help. The supplementary role may be paid a stipend at a different rate at the discretion of the Treasury Council.

Q: What happens when a appointed member resigns their position some time during the current EPOCH? A: The next runner-up is appointed, if there is no runner-up the Stand-In Procedure applies.

Q: What happens when there are not enough candidates to fill all the required positions in a DAO or Council for a specific EPOCH? A: The Stand-In Procedure applies

Q: What happens when a DAO member refuses to transfer their NFT? A: The protocolDAO (soon to be deprecated) is the only one that can control the movement of the NFTs, once the protocolDAO is deprecated another suitable entity will be assigned as the controller.

Q: What happens when there are not enough candidates to fill all the required positions in a DAO or Council for a specific EPOCH? A: The Stand-In Procedure applies

Q: What happens when there are less nominees then there are positions? A: The Stand-In Procedure applies

Q: What is the fallback plan for DAOs with less than 5 owners? A: All DAOs with less than 5 signers should appoint a backup signer from one of the other DAOs in order to mitigate the chance that there are not enough available signers at given time.

Copyright

Copyright and related rights waived via CC0.