Guide on how to use the GovernorTimelockAccess

Smart Contracts Developer Wanted
1

For GovernorTimelockControl the workflow is usually TimelockControl contract is the owner of the proposed contract, and the TimelockControl contract is referenced in the Governor contract which inherits from the GovernorTimelockControl. So after is proposal is passed, TimelockControl being the owner executes the proposal.

But how is the workflow goes for GovernorTimelockAccess. As i read, for GovernorTimelockAccess, the Governance contract can directly be the owner of the proposal contract. What will be the ideal inheritance and workflow of the contracts. Who will be the admin of AccessManager?
@ernestognw

1 Like
2

Hi @Rahul_Raj_Sarma,

First, to summarize the GovernorTimelockControl behavior; in this case the Governor executes through the TimelockController since it's the owner of the execution target (ie. the callee contract).

Are you familiar with the AccessManager?

In the case of the GovernorTimelockAccess, it works as an adapter for callees that inherit from AccessManaged and are restricted by an AccessManager. For those contracts, the Governor should decide whether to execute through the AccessManager (first scheduling the transaction if it requires a delay) or to call the target contract directly if it's not restricted.

The workflow would be:

  1. Consider you already have an AccessManager, a Governor and multiple other contracts restricted by the AccessManager
  2. The governor needs to inherit from GovernorTimelockAccess and reference the AccessManager (also set baseDelay if you want a minimum)
  3. You progressively configure permissions of the access manager and other restricted contracts. A multisig as an admin would be fine at this point.
  4. Every Governor execution will follow the manager rules in this way (which includes delays and specific restricted functions)
  5. Once the AccessManager matures enough, you can give the admin role to the Governor

The final result is a Governor that controls all the permissions of the system.

3

So for GovernorTimelockControl, TimelockController is made the owner of the proposal contracts, but here we can directly assign the Governor as the owner of various restricted proposal contracts?
As you mentioned the Governor can decide whether to call the target contract through AccessManager or directly, therefore it is not necessary for the target contract to be ownable, unlike TimelockController?

4

here we can directly assign the Governor as the owner of various restricted proposal contracts?

Correct, the GovernorTimelockAccess just follows the manager rules. Consider the restricted operations will be executed through the manager.

therefore it is not necessary for the target contract to be ownable

No, but it has to be AccessManaged and use the restricted modifier.

5

Can you also elaborate a bit about what permissions needs to be configured for the restricted contracts and after what configurations will the Governor be assigned as the admin.
Till now i had the idea that the Governor should have all control of power and should be the admin primarily.

6

Also what might be the use for salt in creating hashed Id for an operation, in what scenarios it might be useful? @ernestognw

7

Can you also elaborate a bit about what permissions needs to be configured for the restricted contracts and after what configurations will the Governor be assigned as the admin.

The permissions are up to you or the design of your system. I set up an AccessManager deployment example in the past that I think might be helpful. The deployment is written in Solidity (Foundry) and the logic is that it sets 3 roles (MINTER, CALLER and UPGRADER), each one with their corresponding guardiands and role admins, totalling 9 roles in total:

As you can see, the ADMIN role is renounced at the end of the script, in this case you can just transfer the ADMIN role to your Governor (inheriting from GovernorTimelockAccess) so that all the needed permissions are set at deployment and any change requires a governance proposal to pass.

Also what might be the use for salt in creating hashed Id for an operation, in what scenarios it might be useful? @ernestognw

Sorry, I'm not sure what you mean by salt. We use operationIds for identifying scheduled operations, which are required for those accounts in the AccessManager who have any way of execution delay (either each user's role delay granted along with the role or a target admin delay).

The benefit of setting delays is that it allows for preparing an incident response plan in case of getting keys or accounts compromised. Secondarily, it allows stakeholders to react to restricted actions performed by accounts with a role.