If there was no timelock to begin with, this step (execute) can be ran immediately after the proposal succeeds.

To me above makes more sense than adding a timelock to send another queue transaction and wait for some time to run execute afterwards. It sounds like proposer role always need to wait for proposal to succeed and run queue subsequently, which involves extra step.

What's the actual use case for queue? why is this recomended? In their doc

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

I don't quite get this, but I assume user who has already casted vote can revoke during this period? If yes, does it mean they are going against the proposal or abstain from it? how does this process work?

1 Answer 1


Timelock extensions add a delay for governance decisions to be executed. The workflow is extended to require a queue step before execution.

We want to have a queue (delay) so that if there are any significant changes in the protocol, the users/applications that use the protocol can prepare accordingly for the effects of implementation for them. since it is successful and is very likely to get executed after the delay period is over.

Also, till the proposal is executed the proposer needs to maintain the proposal threshold (including while queued in timelock). Otherwise, the cancel function can be called by the proposal creator, or any Ethereum address if the proposal creator fails to maintain more delegated votes than the proposal threshold.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.