Timelock

Timelock​

It is good practice to add a timelock to governance decisions. This allows users to exit the system if they disagree with a decision before it is executed.

The Timelock contract can modify system parameters, logic, and contracts in a 'time-delayed, opt-out' upgrade pattern.

Timelock has a hard-coded minimum delay of 2 days, which is the least amount of notice possible for a governance action. Each proposed action will be published at a minimum of 2 days in the future from the time of announcement. Major upgrades, such as changing the risk system, may have up to a 14 days delay.

Timelock is controlled by the governance module; pending and completed governance actions can be monitored on the Timelock Dashboard.

We will use OpenZeppelin’s TimelockController in combination with the GovernorTimelockControl module.

TimelockController

TimelockController uses an AccessControl setup that we need to understand in order to set up roles.

• The Proposer role is in charge of queueing operations: this is the role the Governor instance should be granted, and it should likely be the only proposer in the system.

• The Executor role is in charge of executing already available operations: we can assign this role to the special zero address to allow anyone to execute (if operations can be particularly time sensitive, the Governor should be made Executor instead).

• Lastly, there is the Admin role, which can grant and revoke the two previous roles: this is a very sensitive role that will be granted automatically to the timelock itself, and optionally to a second account, which can be used for ease of setup but should promptly renounce the role.

GovernorTimelockControl

Extension of Governor that binds the execution process to an instance of TimelockController. This adds a delay, enforced by the TimelockController to all successful proposal (in addition to the voting duration). The Governor needs the proposer (and ideally the executor) roles for the Governor to work properly.

Using this model means the proposal will be operated by the TimelockController and not by the Governor. Thus, the assets and permissions must be attached to the TimelockController. Any asset sent to the Governor will be inaccessible.

Setting up the TimelockController to have additional proposers besides the governor is very risky, as it grants them powers that they must be trusted or known not to use: 1) onlyGovernance functions like relay are available to them through the timelock, and 2) approved governance proposals can be blocked by them, effectively executing a Denial of Service attack. This risk will be mitigated in a future release.