Update staking epoch length to 7 days

[mintcloud]

Summary

We propose to decrease the current epoch length from 10 days to 7 days.
We propose to have epoch finalizations on weekends (this will influence the vote calendar for this ZEIP).
This proposal includes a change in administrative timelocks for StakingProxy and ZrxVault contracts.

Type: PARAMETERS

Motivation

During the first few months since the launch of ZRX Portal, users shared that it’s complicated to estimate the amount of rewards to be collected by staking pools. While this feedback will be addressed directly in ZRX Portal, this can be mitigated by offering users more data points to perform their analysis. This can be achieved by simply decreasing the epoch length, so that to be able to share more data points to users.

Specification

Updates of staking parameters and timelocks are described here.

Rationale

The proposal is to make an epoch last 7 days to give users a more regular cadence with which they receive rewards, and sync it to their weekly activities. Weekends seem an ideal time of the week for an epoch switchover.
Also, a shorter epoch allows tokenholders to optimize their operations (in case they want to rebalance or withdraw rewards) in times with relatively high volatility.

Implementation

Parameters will be set by the Governor contract by submitting the following transaction
TODO

We are proposing to execute this transaction on epoch 19 (starts on 05/16), as the next available window to have epoch finalizations on Saturdays.
To do that, taking into account the current timelocks of 10 days, it is required to have a vote during epoch 17, which starts on 04/26.
The rationale behind the availability windows calculation is in the notes.

This proposal will include also the modification of administrative timelocks for staking contracts upgrades. They’re currently set to be either 1 or 2 epochs long.

Contract	Function	Selector	Timelock
StakingProxy	addExchangeAddress	20 days	14 days
StakingProxy	removeExchangeAddress	20 days	14 days
StakingProxy	attachStakingContract	20 days	14 days
StakingProxy	detachStakingContract	20 days	14 days
StakingProxy	setParams	10 days	7 days
StakingProxy	addAuthorizedAddress	20 days	14 days
StakingProxy	removeAuthorizedAddress	20 days	14 days
StakingProxy	removeAuthorizedAddressAtIndex	20 days	14 days
StakingProxy	transferOwnership	20 days	14 days
ZrxVault	setStakingProxy	20 days	14 days
ZrxVault	setZrxProxy	20 days	14 days
ZrxVault	addAuthorizedAddress	20 days	14 days
ZrxVault	removeAuthorizedAddress	20 days	14 days
ZrxVault	removeAuthorizedAddressAtIndex	20 days	14 days
ZrxVault	transferOwnership	20 days	14 days
Exchange	setProtocolFeeCollectorAddress	20 days	14 days
Exchange	setProtocolFeeMultiplier	10 days	7 days

Designated team: 0x Core Team

Notes

The start day of the epoch in which the operation is effective at is what determines the weekly cadence.
The vote needs to be opened 2 epochs before since there is a 10 days lock period. If the transaction executing the update needs to be done in epoch i, the vote needs to happen on epoch i-2. If the proposal is accepted, then it’s in the early days of epoch i-1 that the transaction needs to be sent. Adding the timelock of 10 days, it results that epoch i is the first effective epoch with 7 days.

Note that the current time at which epochs are finalized is around 8PM PST, 11PM EST, 03AM GMT (+1 day).

Upcoming epochs (days according to when epoch is finalized in GMT)

Epoch 16 - Thursday (starts on 04/16)
Epoch 17 - Sunday (04/26)
Epoch 18 - Wednesday (05/06)
Epoch 19 - Saturday (05/16) (proposed epoch) → vote in Epoch 17
Epoch 20 - Tuesday (05/26)
Epoch 21 - Friday (05/05)
Epoch 22 - Monday (05/15)
Epoch 23 - Thursday (05/25)
Epoch 24 - Sunday (06/05) → vote in Epoch 22
Epoch 25 - Wednesday (06/15)
Epoch 26 - Saturday (06/25) → vote in epoch 24