From e0137d4cbe14ba6be2b52c6ecfb006b515c6f780 Mon Sep 17 00:00:00 2001 From: Francisco Date: Mon, 7 Nov 2022 20:00:19 -0300 Subject: [PATCH] Fix outdated docs about timelock admin (#3806) (cherry picked from commit 47d4ebb73431fe061062963f44ee987dd0a1b517) --- docs/modules/ROOT/pages/governance.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/governance.adoc b/docs/modules/ROOT/pages/governance.adoc index 3dca902a156..315c3cbf0a6 100644 --- a/docs/modules/ROOT/pages/governance.adoc +++ b/docs/modules/ROOT/pages/governance.adoc @@ -254,7 +254,7 @@ TimelockController uses an AccessControl setup that we need to understand in ord - 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 both deployer and timelock itself, but should be renounced by the deployer after setup. +- 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. == Proposal Lifecycle