SIP-104: Spartan Council constituent epoch lock with council member vote weight dilution + enable council voting on Synthetix Improvement Proposals (SIPs).

Author	rubber^duck, Andy T CF
Status	Implemented
Type	Governance
Network	Ethereum
Implementor	TBD
Release	TBD
Created	2020-12-29

Simple Summary

This SIP proposes to iterate on the Spartan Council governance process outlined in SIP-93 by introducing a lock on the Spartan Council constituents for the duration of a Council Epoch and introduces the ability for delegators to dissent on the decisions made by their delegates by diluting their voting power on a per SCCP/SIP basis. Spartan Council members are also proposed to start voting on the Synthetix Improvement Proposals (SIPs).

Abstract

This proposal will remove liquid Democracy as defined in SIP-93. When an Election Period concludes, the n elected council members will remain on the Spartan Council for the duration of the Council Epoch (council members can only be removed or added on each new Council Epoch).

Within a Council Epoch, the council will still signal on SCCP’s proposed by the community. At the start of each proposal, each council member is assigned a voting power of 1 (comprising of the total weight debt that was assigned for them by voters during the election period). In the case where the delegator of council members dissent on their delegates vote on a proposal, they will be able to withdraw their vote (dilution event).

When a dilution event occurs, the corresponding council members voting weight is reduced by the relative dissenting parties weighted debt, in proportion to the council members total debt (see overview for examples).

This will not affect the Council Member's position on the Council.

For a proposal to be resolved, the existing supermajority rule still applies as outlined in SIP-93.

This proposal will also enable the Spartan Council members to vote on SIPs in the same manner as they have voted on SCCPs.

Motivation

The existing Spartan Council process implemented per SIP-93 featured aspects of a liquid democracy which allowed voters who qualified in the Election Period snapshot to withdraw or modify their vote. With Spartan Council nominees only separated by a marginal amount of WD, the reallocation of a vote caused frequent changes to the composition of the Council.

The frequent shifts in the Spartan Council created high friction for council members as well as introducing additional overhead for the protocolDAO which had to keep monitoring changes to the vote count.

Whilst the current implementation of liquid democracy in SIP-93 created too much overhead, the other end of the spectrum, where the Spartan Council was locked in for the duration of the Council Epoch would significantly reduce the Spartan Council’s resistance to corruption and collusion. Token holders still need a way to signal against an existing Spartan Council members decision.

Specification

Overview

There are two major components of this proposal:

Spartan Council constituent lock
Vote dilution

Spartan Council constituent lock

Upon the conclusion of an Election Period, the n number of Spartan Council members will be permanently granted a council seat for the duration of an Council Epoch.

Instead of the current election polls hosted on (council.synthetix.io) which allow voters to modify their votes for the duration of a Council Epoch. All election polls will run for an Election Period, which results in votes being locked at the end of an Election Period.

On the start of a new Election Period, voters will be able to reassign their votes to new or existing Spartan Council nominees.

Vote dilution

During an Election Epoch, Spartan Council members will be required to vote on SCCP’s. At the start of each proposal, Spartan Council members are each given a voting power of 1.

If at any stage of the proposal a token holder disagrees with their delegate’s vote, they are able to withdraw their voting weight from that particular council member, causing a dilution event to occur for that specific member.

The effect of a particular dilution event can be calculated as follows:

N = (current WD) - (voter’s withdrawn WD / total Council member’s WD)

*current WD = the current voting power the council member has for this proposal (defaulted at 1 if no prior dilution event has occurred) *voter’s withdrawn WD = how much WD the voter has assigned to the council member in the election period. *total council member’s WD = how much WD in total the council member has garnered from voters in the election period.

The dilution feature allows voters to effectively cast a “veto” against their delegates by minimising their voting weight so that the supermajority of a vote can not be met if a sufficiently large number of token holders cast vetos.

At the start of each SCCP vote, council members will have voting weights of 1 again and throughout the Council Epoch (regardless of whether they had experienced a dilution event), their seat within the council is also not affected.

Enabling council votes on SIP

The current implementation of the Spartan Council only allows the Spartan Council to vote on SCCP with SIP voting being conducted on the discord #governance-polls channel. This SIP proposes to include SIPs in the Spartan Council voting process.

Transition

Given that this SIP reaches consensus, it is proposed that the Spartan Council will undergo 1 more council epoch according to SIP-93 to ensure that the Spartan Council does not sit in a locked state where voters cannot adjust nor dissent against the existing council members until the required implementation is finished.

Timelines and Planning

Staking UI to support the three snapshot spaces (council, proposals. grants) by the end of the next Election Period (February 8th 2021, 0:00 UTC) and voter dilution

After the end of the Election Period, the constituents of the Spartan Council will be locked in for a Council Epoch.

Transitionary Spartan Council lock

Due to concerns that were presented in the current council epoch (1-1-21 0:00 UTC) regarding low voter turnout, voter fatigue and low voter transparency, the timeline proposed above will need to be modified to give enough time for the development of this SIP.

It is proposed that on the conclusion of the Council Epoch (1-2-21 0:00 UTC) that the Spartan Council remains locked in until this SIP is implemented. The protocol DAO will act as a back-stop for any governance attacks that arise during this intermediary stage.

Rationale

After the conclusion of the first Spartan Council election, the Spartan Council constituents changed 10+ times before the first SCCP was proposed. The Spartan Council nominees expressed their concern about the overhead these frequent changes introduced, making it difficult to review and perform their Spartan Council duties in an effective and timely manner.

The main suggested solutions involved removing the liquid aspect of the Spartan Council, locking down the Spartan Council members for the duration of a Council Epoch. This solution alone did not satisfy the token holders, as it shifted too much power from the token holders to the council and introduced vulnerabilities to the protocol.

After some debate, the community came up with a solution which produced a balance between liquidity and stability within the council.

Technical Specification

CouncilDilution

The CouncilDilution contract will be added with the following functions

`CouncilDilution` Function	Description
`logElection`	A function to create a new ElectionLog, this is called to record the result of a Spartan Council election
`logProposal`	A function to created a new ProposalLog, this is called to record SCCP/SIPS created and allow for dilution to occur per proposal.
`dilute`	A function to dilute a council member's voting weight for a particular proposal
`invalidateDilution`	A function that allows a voter to undo a dilution
`modifySeats`	A function that can only be called by the OWNER that changes the number of seats on the Spartan Council
`modifyProposalPeriod`	A function that can only be called by the owner that changes the proposal voting period length

The basis of the contract is the logElection function which stores the metadata of the most recent election, who voted, who did they vote for, how much WD was allocated. On each new proposal that is stored on the contract, a dilution event can then occur which then impacts that members voting weight.

Test Cases

Case 1:

On the start of an Election Period, token voter 1 has a WD of 10. They assign that voting weight to council member 4.

At the end of the Election Period, council member 4 has a total WD of 100.

During a SCCP, where the vote is binary (yes or no), council member 4 votes for “yes”. Token voter 1, decides to withdraw their vote on this SCCP, triggering a dilution event.

Council member 4 now only has a voting weight of 0.9.

Case 2

On the start of an Election Period: Token voter A has a WD of 80 and assigns that voting weight to council member 1. Token voter B has a WD of 30 and assigns that voting weight to council member 2. Token voter C has a WD of 40 and assigns that voting weight to council member 2. Token voter D has a WD of 35 and assigns that voting weight to council member 3. Token voter E has a WD of 30 and assigns that voting weight to council member 3. Token voter F has a WD of 40 and assigns that voting weight to council member 4. Token voter G has a WD of 60 and assigns that voting weight to council member 5.

At the end of the Election period: Council member 1 has a total WD of 100. Council member 2 has a total WD of 95. Council member 3 has a total WD of 90. Council member 4 has a total WD of 90. Council member 5 has a total WD of 88. Council member 6 has a total WD of 85. Council member 7 has a total WD of 80.

During a SCCP, where the vote is binary (yes or no), all council members voted 7 votes for "yes". Token holders A through G have decided to withdraw their vote on this SCCP, triggering a dilution event.

Council member 1 now has a voting weight of 0.2 Council member 2 now has a voting weight of 0.25 Council member 3 now has a voting weight of 0.25 Council member 4 now has a voting weight of 0.5 Council member 5 now has a voting weight of 0.25 Council member 6 now has a voting weight of 1 Council member 7 now has a voting weight of 1

The effect of the dilution resulted in the voting weight of 3.45, which fails the supermajority requirement of 4.5 derived from (N/2 +1) where in this example N = 7 council members.