SIP-274: Introduction of an Inactivity Threshold in Spartan Council SIP and SCCP Vote Participation

Simple Summary

This SIP proposes the creation of an inactivity threshold for the maximum number of protocol-issued votes that can be sequentially missed by a Spartan Councillor before a dismissal procedure is automatically begun and then put to the council owner (currently the pDAO).

Abstract

The role of a Spartan Councillor entails using power delegated by SNX stakers to vote on proposed protocol changes (SIPs and SCCPs) so that implementations can be made that optimally advance the Synthetix project. The requirement that Core Contributors abide only by those proposals that are passed by the Spartan Council, and only implement changes once they are passed by a vote, places a great deal of responsibility in the hands of the individual councillors to grant proposals their due consideration and do so in a reasonable timeframe. If voting is hampered by inactivity, this effectively stalls the protocol's ability to implement improvements and, in some cases, make important and time-critical changes. As such, in order to better ensure the project's ability to rapidly act in its interests, this SIP proposes the creation of an inactivity threshold that, if exceeded, automatically triggers a dismissal process of Spartan Councillors from their role. This inactivity threshold is one established through the measuring of occasions and durations in which a Spartan Councillor has failed to participate in protocol-issued votes.

Motivation

Conceptually, the intention of this SIP is to ensure that the Synthetix community can anticipate from the Spartan Council an ongoing and reasonable level of attentiveness to a core responsibility of their role. Rather than seeking to mitigate issues that may arise should a single vote need to be be passed quickly, this SIP, by establishing a maximum number of protocol-issued votes that can be missed sequentially over a defined period, seeks to encourage routinized participation in governance processes and decrease sustained states of inactivity. It should be noted that what is meant here by protocol-issued votes is those that are authored or co-authored by Core Contributors or members of the four councils (Spartan, Treasury, Ambassador, Grants). Specifying the authors of proposals that suffer missed votes counted towards the inactivity threshold is designed to prevent SIP and SCCP votes created without merit unduly influencing the triggering of a dismissal request.

Specification

This SIP proposes that sequentially missing five (or more) qualifying votes that meet the below-listed criteria and that have been issued by the protocol will automatically trigger a request to the council owner, currently the pDAO, to dismiss the Spartan Councillor(s) in question. The following conditions should be met when counting the five votes (the last of which is set in the interest of granting the Spartan Council some freedom to disengage from online activity for reasonable periods of time):

• A missed vote is one in which a Spartan Councillor has submitted neither a positive or a negative response prior to its end date, and assumes that no additional vote option is present

• As previously stated, the votes counted must be authored or co-authored by CCs or members of the four current councils

• The vote should be announced on project Discord within 24 hours of its creation, with the @Spartan Council tag used to alert members

• The votes counted must have a time window in which to vote of no less than three days (72 hours)

• The first and the last votes counted must have started greater than ten days apart (though this period may be adjusted, if deemed necessary, by the passing of a meta-goverance SCCP)

Once five qualifying votes have been missed over the specified period, the inactivity of the designated Spartan Councillor(s) can be raised by any member of the Synthetix community, in response to which the remaining Spartan Councillors are required to begin the dismissal process.

The dismissal process entails those members of the Spartan Council who have not been found to be inactive unanimously voting for dismissal using a Snapshot vote and then submitting the request to the council owner. The council owner would then be required to revoke the governance NFT from the relevant party. The reason for a vote being conducted prior to instigating a request for dismissal to the council owner is that carrying out such a vote removes the protocol's vulnerability to edge-cases in which a Spartan Councillor could be dismissed without the opportunity for soft-governance to step in and protect the efficacious running of the protocol.

Rationale

The rationale behind this SIP is the desire to reassure all parties concerned with the Synthetix project that the core governance body behind the protocol will be active and engaged with the governance process that facilitates its development. These parties include users of protocol-issued tokens (such as sUSD), SNX holders, SNX stakers, protocol partners, Core Contributors and members of each of the councils that manage the project, including the Spartan Council itself. Each and every one of the members of these groups benefits from a vibrant governance culture that can only flourish through participation. The goal of this SIP is to encourage this participation and dissuade inactivity at the highest level within the protocol hierarchy, a practice that sets a poor example and diminishes the perceived value of time devoted to furthering the Synthetix project. Furthermore, in stipulating an objective means of gauging activity, active Spartan Councillors are able to distance the dismissal of an incumbant from factors such as personal relationships and avoid being drawn into inefficient and disruptive discussions around whether or not an individual is being "active enough" in regards to SIP and SCCP voting.

Test Cases

The above image records the state of voting on several SIPs and SCCPs in order to illustrate where a dismissal would be triggered.

• Spartan Councillor 7 missed their first vote on SIP-X, that was begun on 14/01/2023 at 10:00 UTC.

• In order to be dismissed, Spartan Councillor 7 would need to have at least 5 missed votes occur sequentially over a period of greater than ten days.

• Spartan Councillor 7 would thus need to have missed all seven votes on the table, as SIP-Y marks the first missed vote outside of the ten-day window started with SIP-X (with SIP-Y having itself begun at 17:35 UTC on 24/01/2023). This missed vote would be the one that could trigger dismissal.

• If SCCPs 4 and 5 had not been put to vote, SIP-Y would still trigger Spartan Councillor 7's dismissal, as SIP-Y brought the sequentially missed votes to a total of five, while also falling outside of the ten-day window begun by SIP-X.

Copyright

Copyright and related rights waived via CC0.