YIP-98 Extend Proposal Timelock Period

Summary

This proposal is to approve extending the onchain proposal timelock period.

Abstract

Currently, we feel the time delay for a proposal to be able to execute can be adjusted for a more suitable value, proposing a 5 days time length update for the delay. That will give a longer than usual time to address any matter in a timely manner.

Specification

Proceeding with an onchain proposal to extend the timelock period with the proposed value.

why not extend both the voting period and the timelock to equal 5 days? The current timeframes are 48 hours to vote and 12 hours timelock. Changing the timelock to 5 days adds security, but no more than if we add to both parts. We see a proposal immediately so whether the added time is in the timelock or voting period, we would have the same amount of time to rally guardian signers in the event of another malicious proposal.

If we only extend the timelock then it doesn’t give additional time for the community to vote, making this change less useful.

Can we make the change 4 days voting at 3 days timelock instead of the proposed 2 days voting and 5 days timelock?

This proposal would extend the propose->execute cycle to 6 which is a doubling of the current 2.5. I’m not for more than doubling that at this time as there is lot to get done coming up soon.

I’m not sure I follow, could you elaborate what you mean by this? Adding to different parts has different effects so I’m curious to understand how you see those parts.

The way I understand the relevant delays in the governance process are as follow:

  • governor.votingDelay - blocks - Delay between proposing and voting, currently 1 block (or ~14s) .
  • governor.votingPeriod - blocks - The period in which voting takes place, currently 12345 blocks (or ~48hrs)
  • timelock.delay - seconds - The delay before a queued proposal may be executed currently 43200 seconds ( or ~12 hours)

Relevant governance security features:

  • The guardian can cancel the proposal at any point between proposal to execution.
  • If the proposal’s proposer, drops to a vote power of less than the “proposalThreshold” and has yet to been executed than anyone may cancel the proposal in the next block.

@ethe, is your proposal to update the timelock.delay which is currently 12 hours to 5 days? or to extend the time period in which an active proposal may be cancelled to 5 days from the current ~2.5 days (by some combination of the above parameters)?

got an answer to this. The reason that only the timelock.delay function is being changes is because it can be done with a simple governance vote.

changing the governor.votingPeriod on the governor contract would require deploying a new governor.

E sees the short time to get a proposal passed as a security risk given our recent attack, and thinks we should extend the voting period. The easy way to achieve this is with the timelock so it is what is proposed.

I am ok with this as long as we have a plan to upgrade the governor with a longer voting period and shorter timelock (I.e. 5 days voting, 2 days timelock) in the future and have that clearly on the roadmap of things to do.

1 Like