Notes on governor queuing & delayed proposal

[Amxx]

By default, the Governor is designed to be its own executor. That means any proposal's action will be executed from the Governor itself.

By default, proposals that are succesfull can be executed immediatly after the vote succeeds. There is no need to queue the proposal. This is observable through the proposalNeedsQueuing function returning false for all proposals.

---

This default behavior can however be altered by the use of an extension:

• GovernorTimelockCompound connects the Governor to a CompoundTimelock so that proposal are executed from that Timelock. This means that the executor becomes the CompoundTimelock (though it is still possible to execute call from the Governor itself using the relay function if needed). This extension turns proposalNeedsQueuing to true, and requiers all proposal to be queued before they can be executed. The delay is enforced by the CompoundTimelock and NOT by the governor itself.

• GovernorTimelockControl does everything similarly to above, but using an OZ TimelockController instead of a CompoundTimelock.

• GovernorTimelockAccess is quite different to the previous one. It is designed to help integrate with an AccessManager that may enforce delays on some function calls. Depending on the base delay, not all proposal may need queueing. If Base delay is 0, then only the proposal that call to a function that has a delay enforced by the AccessManager will need queuing. In this case, the delay is enforced by the Governor itself (in addition to the AccessManager also enforcing some delay on some actions).

---

One important thing to note is that setting proposalNeedsQueuing to true, and making _queueOperations return a non-zero value is NOT enough to enforce a delay on all operations !!!

Question:

• Do we want to provide an easy way to add a delay to all operation ?
• If yes, should that be implemented using an extension, or do we want to include it in the base Governor ?
• If no external call is needed (no need to schedule the operation on a timelock), we can possibly do with the call to queue. Do we want to keep this call, or do we want to automate the process and seamlessly start the queue period when the vote ends ?
  • If the vote is govern by a number of blocks, then the queue duration would have to be following the clock. This would create a possible inconsistency with the proposalEta that is documented to not follow the ERC-6372 CLOCK_MODE and (almost always) be a timestamp.