SIP-286: Reduction in the Length of Council Election Periods

Simple Summary

In the interests of greater efficiency, this SIP seeks reduce the length of time required to hold a council election by adjusting the timing of both the nominations and voting periods.

Abstract

The recent passing of SIP-278: Enable nominations during voting period has reduced the necessary length of an epochal election by allowing nominations to be made concurrently with voting. As the two can now be overlapped, the independent and week-long length of the nominations phase adds to the time it takes to stage an election with little in the way of return. With the V3GM capable of altering these variables and overlapping the two periods, this SIP can remedy the disproportionate time cost of the election process and render it more efficient.

Motivation

At present, the council election process takes in excess of three weeks to carry out when including preparatory work. At almost one quarter of the entire epoch length, this creates a excessively large drain on the attention of incumbent councillors, Core Contributors and the Synthetix community at large. Reduction in the length of the nomination and voting periods, as well as conducting them simultaneously, will allow an election to be comfortably carried out within a period of two weeks, granting all parties the ability to more effectively concentrate their efforts on either campaigning for council seats when an election is being held or developing the protocol when one is not.

Specification

The change would be achieved by:

• Calling modifyEpochSchedule on the four councils.

    function modifyEpochSchedule(
        uint64 newNominationPeriodStartDate,
        uint64 newVotingPeriodStartDate,
        uint64 newEpochEndDate
    ) external override onlyOwner onlyInPeriod(ElectionPeriod.Administration) {

• The current values would then be altered to the new, desired values.

    "nominationPeriodStartDate": "1670754297", // Sun Dec 11 2022 10:24:57 GMT+0000
    "votingPeriodStartDate": "1671359097", // Sun Dec 18 2022 10:24:57 GMT+0000
    "epochEndDate": "1672568697", // Sun Jan 01 2023 10:24:57 GMT+0000

    "nominationPeriodStartDate": "1671321600", // Sun Dec 18 2022 00:00:00 GMT+0000
    "votingPeriodStartDate": "1671667200", // Thu Dec 22 2022 00:00:00 GMT+0000
    "epochEndDate": "1672531199", // Sat Dec 31 2022 23:59:59 GMT+0000

• These changes would set the nominationPeriodStartDate to 14 days prior to the epochEndDate and the votingPeriodStartDate to 10 days prior to the epochEndDate, with the epochEndDate falling at 23:59:59 on December 31st, 2022.

Rationale

• There exists two methods for altering the above variables, modifyEpochSchedule and tweakEpochSchedule. The first of these is the more drastic, requiring a SIP rather than an SCCP. The reason for having chosen the SIP route is because it allows the maxAdjustmentTolerance, which is currently set at 604800 seconds (7 days), to be exceeded. Of the three variables being changed, nominationPeriodStartDate exceeds this limit and thus requires a SIP. Therefore, in order to avoid the creation of an unnecessary SCCP, all the changes have been incorporated within this single SIP used to appropriately authorize them.

Copyright

Copyright and related rights waived via CC0.