Governance

This document is better viewed at https://docs.openzeppelin.com/contracts/api/governance

This directory includes primitives for on-chain governance.

Governor

This modular system of Governor contracts allows the deployment on-chain voting protocols similar to Compound’s Governor Alpha & Bravo and beyond, through the ability to easily customize multiple aspects of the protocol.

For a guided experience, set up your Governor contract using Contracts Wizard.

For a written walkthrough, check out our guide on How to set up on-chain governance.

  • Governor: The core contract that contains all the logic and primitives. It is abstract and requires choosing one of each of the modules below, or custom ones.

Votes modules determine the source of voting power, and sometimes quorum number.

Counting modules determine valid voting options.

Timelock extensions add a delay for governance decisions to be executed. The workflow is extended to require a queue step before execution. With these modules, proposals are executed by the external timelock contract, thus it is the timelock that has to hold the assets that are being governed.

Other extensions can customize the behavior or interface in multiple ways.

  • GovernorCompatibilityBravo: Extends the interface to be fully GovernorBravo-compatible. Note that events are compatible regardless of whether this extension is included or not.

  • GovernorProposalThreshold: Restricts proposals to delegates with a minimum voting power.

In addition to modules and extensions, the core contract requires a few virtual functions to be implemented to your particular specifications:

  • votingDelay(): Delay (in number of blocks) since the proposal is submitted until voting power is fixed and voting starts. This can be used to enforce a delay after a proposal is published for users to buy tokens, or delegate their votes.

  • votingPeriod(): Delay (in number of blocks) since the proposal starts until voting ends.

  • quorum(uint256 blockNumber): Quorum required for a proposal to be successful. This function includes a blockNumber argument so the quorum can adapt through time, for example, to follow a token’s totalSupply.

Functions of the Governor contract do not include access control. If you want to restrict access, you should add these checks by overloading the particular functions. Among these, Governor._cancel is internal by default, and you will have to expose it (which the right access control mechanism) yourself if this function is needed.

Core

IGovernor

import "@openzeppelin/contracts/governance/IGovernor.sol";

Interface of the Governor core.

Available since v4.3.

name() → string public

Name of the governor instance (used in building the ERC712 domain separator).

version() → string public

Version of the governor instance (used in building the ERC712 domain separator). Default: "1"

COUNTING_MODE() → string public

A description of the possible support values for castVote and the way these votes are counted, meant to be consumed by UIs to show correct vote options and interpret the results. The string is a URL-encoded sequence of key-value pairs that each describe one aspect, for example support=bravo&quorum=for,abstain.

There are 2 standard keys: support and quorum.

  • support=bravo refers to the vote options 0 = Against, 1 = For, 2 = Abstain, as in GovernorBravo.

  • quorum=bravo means that only For votes are counted towards quorum.

  • quorum=for,abstain means that both For and Abstain votes are counted towards quorum.

The string can be decoded by the standard URLSearchParams JavaScript class.

hashProposal(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 public

Hashing function used to (re)build the proposal id from the proposal details..

state(uint256 proposalId) → enum IGovernor.ProposalState public

Current state of a proposal, following Compound’s convention

proposalSnapshot(uint256 proposalId) → uint256 public

block number used to retrieve user’s votes and quorum.

proposalDeadline(uint256 proposalId) → uint256 public

timestamp at which votes close.

votingDelay() → uint256 public

delay, in number of block, between the proposal is created and the vote starts. This can be increassed to leave time for users to buy voting power, of delegate it, before the voting of a proposal starts.

votingPeriod() → uint256 public

delay, in number of blocks, between the vote start and vote ends.

Note: the votingDelay can delay the start of the vote. This must be considered when setting the voting duration compared to the voting delay.

quorum(uint256 blockNumber) → uint256 public

Minimum number of cast voted required for a proposal to be successful.

Note: The blockNumber parameter corresponds to the snaphot used for counting vote. This allows to scale the quroum depending on values such as the totalSupply of a token at this block (see ERC20Votes).

getVotes(address account, uint256 blockNumber) → uint256 public

Voting power of an account at a specific blockNumber.

Note: this can be implemented in a number of ways, for example by reading the delegated balance from one (or multiple), ERC20Votes tokens.

hasVoted(uint256 proposalId, address account) → bool public

Returns weither account has cast a vote on proposalId.

propose(address[] targets, uint256[] values, bytes[] calldatas, string description) → uint256 proposalId public

Create a new proposal. Vote start IGovernor.votingDelay blocks after the proposal is created and ends IGovernor.votingPeriod blocks after the voting starts.

Emits a ProposalCreated event.

execute(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 proposalId public

Execute a successful proposal. This requires the quorum to be reached, the vote to be successful, and the deadline to be reached.

Emits a ProposalExecuted event.

Note: some module can modify the requirements for execution, for example by adding an additional timelock.

castVote(uint256 proposalId, uint8 support) → uint256 balance public

Cast a vote

Emits a VoteCast event.

castVoteWithReason(uint256 proposalId, uint8 support, string reason) → uint256 balance public

Cast a with a reason

Emits a VoteCast event.

castVoteBySig(uint256 proposalId, uint8 support, uint8 v, bytes32 r, bytes32 s) → uint256 balance public

Cast a vote using the user cryptographic signature.

Emits a VoteCast event.

ProposalCreated(uint256 proposalId, address proposer, address[] targets, uint256[] values, string[] signatures, bytes[] calldatas, uint256 startBlock, uint256 endBlock, string description) event

Emitted when a proposal is created.

ProposalCanceled(uint256 proposalId) event

Emitted when a proposal is canceled.

ProposalExecuted(uint256 proposalId) event

Emitted when a proposal is executed.

VoteCast(address voter, uint256 proposalId, uint8 support, uint256 weight, string reason) event

Emitted when a vote is cast.

Note: support values should be seen as buckets. There interpretation depends on the voting module used.

Governor

import "@openzeppelin/contracts/governance/Governor.sol";

Core of the governance system, designed to be extended though various modules.

This contract is abstract and requires several function to be implemented in various modules:

Available since v4.3.

Modifiers

onlyGovernance() modifier

Restrict access to governor executing address. Some module might override the _executor function to make sure this modifier is consistant with the execution model.

constructor(string name_) internal

Sets the value for name and version

supportsInterface(bytes4 interfaceId) → bool public

name() → string public

version() → string public

hashProposal(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 public

The proposal id is produced by hashing the RLC encoded targets array, the values array, the calldatas array and the descriptionHash (bytes32 which itself is the keccak256 hash of the description string). This proposal id can be produced from the proposal data which is part of the ProposalCreated event. It can even be computed in advance, before the proposal is submitted.

Note that the chainId and the governor address are not part of the proposal id computation. Consequently, the same proposal (with same operation and same description) will have the same id if submitted on multiple governors accross multiple networks. This also means that in order to execute the same operation twice (on the same governor) the proposer will have to change the description in order to avoid proposal id conflicts.

state(uint256 proposalId) → enum IGovernor.ProposalState public

proposalSnapshot(uint256 proposalId) → uint256 public

proposalDeadline(uint256 proposalId) → uint256 public

_quorumReached(uint256 proposalId) → bool internal

Amount of votes already cast passes the threshold limit.

_voteSucceeded(uint256 proposalId) → bool internal

Is the proposal successful or not.

_countVote(uint256 proposalId, address account, uint8 support, uint256 weight) internal

Register a vote with a given support and voting weight.

Note: Support is generic and can represent various things depending on the voting system used.

propose(address[] targets, uint256[] values, bytes[] calldatas, string description) → uint256 public

execute(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 public

_execute(uint256, address[] targets, uint256[] values, bytes[] calldatas, bytes32) internal

Internal execution mechanism. Can be overriden to implement different execution mechanism

_cancel(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 internal

Internal cancel mechanism: locks up the proposal timer, preventing it from being re-submitted. Marks it as canceled to allow distinguishing it from executed proposals.

castVote(uint256 proposalId, uint8 support) → uint256 public

castVoteWithReason(uint256 proposalId, uint8 support, string reason) → uint256 public

castVoteBySig(uint256 proposalId, uint8 support, uint8 v, bytes32 r, bytes32 s) → uint256 public

_castVote(uint256 proposalId, address account, uint8 support, string reason) → uint256 internal

Internal vote casting mechanism: Check that the vote is pending, that it has not been cast yet, retrieve voting weight using IGovernor.getVotes and call the _countVote internal function.

Emits a IGovernor.VoteCast event.

_executor() → address internal

Address through which the governor executes action. Will be overloaded by module that execute actions through another contract such as a timelock.

Modules

GovernorCountingSimple

import "@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol";

Extension of Governor for simple, 3 options, vote counting.

Available since v4.3.

COUNTING_MODE() → string public

hasVoted(uint256 proposalId, address account) → bool public

proposalVotes(uint256 proposalId) → uint256 againstVotes, uint256 forVotes, uint256 abstainVotes public

Accessor to the internal vote counts.

_quorumReached(uint256 proposalId) → bool internal

_voteSucceeded(uint256 proposalId) → bool internal

See Governor._voteSucceeded. In this module, the forVotes must be scritly over the againstVotes.

_countVote(uint256 proposalId, address account, uint8 support, uint256 weight) internal

See Governor._countVote. In this module, the support follows the VoteType enum (from Governor Bravo).

GovernorVotesQuorumFraction

import "@openzeppelin/contracts/governance/extensions/GovernorVotesQuorumFraction.sol";

Extension of Governor for voting weight extraction from an ERC20Votes token and a quorum expressed as a fraction of the total supply.

Available since v4.3.

constructor(uint256 quorumNumeratorValue) internal

quorumNumerator() → uint256 public

quorumDenominator() → uint256 public

quorum(uint256 blockNumber) → uint256 public

updateQuorumNumerator(uint256 newQuorumNumerator) external

_updateQuorumNumerator(uint256 newQuorumNumerator) internal

QuorumNumeratorUpdated(uint256 oldQuorumNumerator, uint256 newQuorumNumerator) event

Extensions

GovernorTimelockControl

import "@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol";

Extension of Governor that binds the execution process to an instance of TimelockController. This adds a delay, enforced by the TimelockController to all successful proposal (in addition to the voting duration). The Governor needs the proposer (an ideally the executor) roles for the Governor to work properly.

Using this model means the proposal will be operated by the TimelockController and not by the Governor. Thus, the assets and permissions must be attached to the TimelockController. Any asset sent to the Governor will be inaccessible.

Available since v4.3.

constructor(contract TimelockController timelockAddress) internal

Set the timelock.

supportsInterface(bytes4 interfaceId) → bool public

state(uint256 proposalId) → enum IGovernor.ProposalState public

Overriden version of the Governor.state function with added support for the Queued status.

timelock() → address public

Public accessor to check the address of the timelock

proposalEta(uint256 proposalId) → uint256 public

Public accessor to check the eta of a queued proposal

queue(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 public

Function to queue a proposal to the timelock.

_execute(uint256, address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) internal

Overriden execute function that run the already queued proposal through the timelock.

_cancel(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 internal

Overriden version of the Governor._cancel function to cancel the timelocked proposal if it as already been queued.

_executor() → address internal

Address through which the governor executes action. In this case, the timelock.

updateTimelock(contract TimelockController newTimelock) external

Public endpoint to update the underlying timelock instance. Restricted to the timelock itself, so updates must be proposed, scheduled and executed using the Governor workflow.

TimelockChange(address oldTimelock, address newTimelock) event

Emitted when the timelock controller used for proposal execution is modified.

GovernorTimelockCompound

import "@openzeppelin/contracts/governance/extensions/GovernorTimelockCompound.sol";

Extension of Governor that binds the execution process to a Compound Timelock. This adds a delay, enforced by the external timelock to all successful proposal (in addition to the voting duration). The Governor needs to be the admin of the timelock for any operation to be performed. A public, unrestricted, GovernorTimelockCompound.acceptAdmin is available to accept ownership of the timelock.

Using this model means the proposal will be operated by the TimelockController and not by the Governor. Thus, the assets and permissions must be attached to the TimelockController. Any asset sent to the Governor will be inaccessible.

Available since v4.3.

constructor(contract ICompoundTimelock timelockAddress) internal

Set the timelock.

supportsInterface(bytes4 interfaceId) → bool public

state(uint256 proposalId) → enum IGovernor.ProposalState public

Overriden version of the Governor.state function with added support for the Queued and Expired status.

timelock() → address public

Public accessor to check the address of the timelock

proposalEta(uint256 proposalId) → uint256 public

Public accessor to check the eta of a queued proposal

queue(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 public

Function to queue a proposal to the timelock.

_execute(uint256 proposalId, address[] targets, uint256[] values, bytes[] calldatas, bytes32) internal

Overriden execute function that run the already queued proposal through the timelock.

_cancel(address[] targets, uint256[] values, bytes[] calldatas, bytes32 descriptionHash) → uint256 internal

Overriden version of the Governor._cancel function to cancel the timelocked proposal if it as already been queued.

_executor() → address internal

Address through which the governor executes action. In this case, the timelock.

__acceptAdmin() public

Accept admin right over the timelock.

updateTimelock(contract ICompoundTimelock newTimelock) external

Public endpoint to update the underlying timelock instance. Restricted to the timelock itself, so updates must be proposed, scheduled and executed using the Governor workflow.

For security reason, the timelock must be handed over to another admin before setting up a new one. The two operations (hand over the timelock) and do the update can be batched in a single proposal.

Note that if the timelock admin has been handed over in a previous operation, we refuse updates made through the timelock if admin of the timelock has already been accepted and the operation is executed outside the scope of governance.

TimelockChange(address oldTimelock, address newTimelock) event

Emitted when the timelock controller used for proposal execution is modified.

GovernorProposalThreshold

import "@openzeppelin/contracts/governance/extensions/GovernorProposalThreshold.sol";

Extension of Governor for proposal restriction to token holders with a minimum balance.

Available since v4.3.

propose(address[] targets, uint256[] values, bytes[] calldatas, string description) → uint256 public

proposalThreshold() → uint256 public

Part of the Governor Bravo’s interface: "The number of votes required in order for a voter to become a proposer".

GovernorCompatibilityBravo

import "@openzeppelin/contracts/governance/compatibility/GovernorCompatibilityBravo.sol";

Compatibility layer that implements GovernorBravo compatibility on to of Governor.

This compatibility layer includes a voting system and requires a IGovernorTimelock compatible module to be added through inheritance. It does not include token bindings, not does it include any variable upgrade patterns.

When using this module, you may need to enable the Solidity optimizer to avoid hitting the contract size limit.

Available since v4.3.

COUNTING_MODE() → string public

propose(address[] targets, uint256[] values, bytes[] calldatas, string description) → uint256 public

propose(address[] targets, uint256[] values, string[] signatures, bytes[] calldatas, string description) → uint256 public

queue(uint256 proposalId) public

execute(uint256 proposalId) public

cancel(uint256 proposalId) public

proposalThreshold() → uint256 public

Part of the Governor Bravo’s interface: "The number of votes required in order for a voter to become a proposer".

proposals(uint256 proposalId) → uint256 id, address proposer, uint256 eta, uint256 startBlock, uint256 endBlock, uint256 forVotes, uint256 againstVotes, uint256 abstainVotes, bool canceled, bool executed public

getActions(uint256 proposalId) → address[] targets, uint256[] values, string[] signatures, bytes[] calldatas public

getReceipt(uint256 proposalId, address voter) → struct IGovernorCompatibilityBravo.Receipt public

quorumVotes() → uint256 public

hasVoted(uint256 proposalId, address account) → bool public

_quorumReached(uint256 proposalId) → bool internal

See Governor._quorumReached. In this module, only forVotes count toward the quorum.

_voteSucceeded(uint256 proposalId) → bool internal

See Governor._voteSucceeded. In this module, the forVotes must be scritly over the againstVotes.

_countVote(uint256 proposalId, address account, uint8 support, uint256 weight) internal

See Governor._countVote. In this module, the support follows Governor Bravo.

Timelock

In a governance system, the TimelockController contract is in carge of introducing a delay between a proposal and its execution. It can be used with or without a Governor.

TimelockController

import "@openzeppelin/contracts/governance/TimelockController.sol";

Contract module which acts as a timelocked controller. When set as the owner of an Ownable smart contract, it enforces a timelock on all onlyOwner maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied.

By default, this contract is self administered, meaning administration tasks have to go through the timelock process. The proposer (resp executor) role is in charge of proposing (resp executing) operations. A common use case is to position this TimelockController as the owner of a smart contract, with a multisig or a DAO as the sole proposer.

Available since v3.3.

onlyRoleOrOpenRole(bytes32 role) modifier

Modifier to make a function callable only by a certain role. In addition to checking the sender’s role, address(0) 's role is also considered. Granting a role to address(0) is equivalent to enabling this role for everyone.

constructor(uint256 minDelay, address[] proposers, address[] executors) public

Initializes the contract with a given minDelay.

receive() external

Contract might receive/hold ETH as part of the maintenance process.

isOperation(bytes32 id) → bool pending public

Returns whether an id correspond to a registered operation. This includes both Pending, Ready and Done operations.

isOperationPending(bytes32 id) → bool pending public

Returns whether an operation is pending or not.

isOperationReady(bytes32 id) → bool ready public

Returns whether an operation is ready or not.

isOperationDone(bytes32 id) → bool done public

Returns whether an operation is done or not.

getTimestamp(bytes32 id) → uint256 timestamp public

Returns the timestamp at with an operation becomes ready (0 for unset operations, 1 for done operations).

getMinDelay() → uint256 duration public

Returns the minimum delay for an operation to become valid.

This value can be changed by executing an operation that calls updateDelay.

hashOperation(address target, uint256 value, bytes data, bytes32 predecessor, bytes32 salt) → bytes32 hash public

Returns the identifier of an operation containing a single transaction.

hashOperationBatch(address[] targets, uint256[] values, bytes[] datas, bytes32 predecessor, bytes32 salt) → bytes32 hash public

Returns the identifier of an operation containing a batch of transactions.

schedule(address target, uint256 value, bytes data, bytes32 predecessor, bytes32 salt, uint256 delay) public

Schedule an operation containing a single transaction.

Emits a CallScheduled event.

Requirements:

  • the caller must have the 'proposer' role.

scheduleBatch(address[] targets, uint256[] values, bytes[] datas, bytes32 predecessor, bytes32 salt, uint256 delay) public

Schedule an operation containing a batch of transactions.

Emits one CallScheduled event per transaction in the batch.

Requirements:

  • the caller must have the 'proposer' role.

cancel(bytes32 id) public

Cancel an operation.

Requirements:

  • the caller must have the 'proposer' role.

execute(address target, uint256 value, bytes data, bytes32 predecessor, bytes32 salt) public

Execute an (ready) operation containing a single transaction.

Emits a CallExecuted event.

Requirements:

  • the caller must have the 'executor' role.

executeBatch(address[] targets, uint256[] values, bytes[] datas, bytes32 predecessor, bytes32 salt) public

Execute an (ready) operation containing a batch of transactions.

Emits one CallExecuted event per transaction in the batch.

Requirements:

  • the caller must have the 'executor' role.

updateDelay(uint256 newDelay) external

Changes the minimum timelock duration for future operations.

Emits a MinDelayChange event.

Requirements:

  • the caller must be the timelock itself. This can only be achieved by scheduling and later executing an operation where the timelock is the target and the data is the ABI-encoded call to this function.

CallScheduled(bytes32 id, uint256 index, address target, uint256 value, bytes data, bytes32 predecessor, uint256 delay) event

Emitted when a call is scheduled as part of operation id.

CallExecuted(bytes32 id, uint256 index, address target, uint256 value, bytes data) event

Emitted when a call is performed as part of operation id.

Cancelled(bytes32 id) event

Emitted when operation id is cancelled.

MinDelayChange(uint256 oldDuration, uint256 newDuration) event

Emitted when the minimum delay for future operations is modified.

Terminology

  • Operation: A transaction (or a set of transactions) that is the subject of the timelock. It has to be scheduled by a proposer and executed by an executor. The timelock enforces a minimum delay between the proposition and the execution (see operation lifecycle). If the operation contains multiple transactions (batch mode), they are executed atomically. Operations are identified by the hash of their content.

  • Operation status:

    • Unset: An operation that is not part of the timelock mechanism.

    • Pending: An operation that has been scheduled, before the timer expires.

    • Ready: An operation that has been scheduled, after the timer expires.

    • Done: An operation that has been executed.

  • Predecessor: An (optional) dependency between operations. An operation can depend on another operation (its predecessor), forcing the execution order of these two operations.

  • Role:

    • Admin: An address (smart contract or EOA) that is in charge of granting the roles of Proposer and Executor.

    • Proposer: An address (smart contract or EOA) that is in charge of scheduling (and cancelling) operations.

    • Executor: An address (smart contract or EOA) that is in charge of executing operations once the timelock has expired. This role can be given to the zero address to allow anyone to execute operations.

Operation structure

Operation executed by the TimelockController can contain one or multiple subsequent calls. Depending on whether you need to multiple calls to be executed atomically, you can either use simple or batched operations.

Both operations contain:

  • Target, the address of the smart contract that the timelock should operate on.

  • Value, in wei, that should be sent with the transaction. Most of the time this will be 0. Ether can be deposited before-end or passed along when executing the transaction.

  • Data, containing the encoded function selector and parameters of the call. This can be produced using a number of tools. For example, a maintenance operation granting role ROLE to ACCOUNT can be encode using web3js as follows:

const data = timelock.contract.methods.grantRole(ROLE, ACCOUNT).encodeABI()
  • Predecessor, that specifies a dependency between operations. This dependency is optional. Use bytes32(0) if the operation does not have any dependency.

  • Salt, used to disambiguate two otherwise identical operations. This can be any random value.

In the case of batched operations, target, value and data are specified as arrays, which must be of the same length.

Operation lifecycle

Timelocked operations are identified by a unique id (their hash) and follow a specific lifecycle:

UnsetPendingPending + ReadyDone

  • By calling schedule (or scheduleBatch), a proposer moves the operation from the Unset to the Pending state. This starts a timer that must be longer than the minimum delay. The timer expires at a timestamp accessible through the getTimestamp method.

  • Once the timer expires, the operation automatically gets the Ready state. At this point, it can be executed.

  • By calling execute (or executeBatch), an executor triggers the operation’s underlying transactions and moves it to the Done state. If the operation has a predecessor, it has to be in the Done state for this transition to succeed.

  • cancel allows proposers to cancel any Pending operation. This resets the operation to the Unset state. It is thus possible for a proposer to re-schedule an operation that has been cancelled. In this case, the timer restarts when the operation is re-scheduled.

Operations status can be queried using the functions:

Roles

Admin

The admins are in charge of managing proposers and executors. For the timelock to be self-governed, this role should only be given to the timelock itself. Upon deployment, both the timelock and the deployer have this role. After further configuration and testing, the deployer can renounce this role such that all further maintenance operations have to go through the timelock process.

This role is identified by the TIMELOCK_ADMIN_ROLE value: 0x5f58e3a2316349923ce3780f8d587db2d72378aed66a8261c916544fa6846ca5

Proposer

The proposers are in charge of scheduling (and cancelling) operations. This is a critical role, that should be given to governing entities. This could be an EOA, a multisig, or a DAO.

Proposer fight: Having multiple proposers, while providing redundancy in case one becomes unavailable, can be dangerous. As proposer have their say on all operations, they could cancel operations they disagree with, including operations to remove them for the proposers.

This role is identified by the PROPOSER_ROLE value: 0xb09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1

Executor

The executors are in charge of executing the operations scheduled by the proposers once the timelock expires. Logic dictates that multisig or DAO that are proposers should also be executors in order to guarantee operations that have been scheduled will eventually be executed. However, having additional executors can reduce the cost (the executing transaction does not require validation by the multisig or DAO that proposed it), while ensuring whoever is in charge of execution cannot trigger actions that have not been scheduled by the proposers. Alternatively, it is possible to allow any address to execute a proposal once the timelock has expired by granting the executor role to the zero address.

This role is identified by the EXECUTOR_ROLE value: 0xd8aa0f3194971a2a116679f7c2090f6939c8d4e01a2a8d7e41d55e5351469e63

A live contract without at least one proposer and one executor is locked. Make sure these roles are filled by reliable entities before the deployer renounces its administrative rights in favour of the timelock contract itself. See the AccessControl documentation to learn more about role management.