anchor.diff:  * xref:api:access.adoc#TimelockController-isOperationReady-bytes32-[`isOperationReady(bytes32)`]
   * xref:api:access.adoc#TimelockController-isOperationDone-bytes32-[`isOperationDone(bytes32)`]
   
  +[[timelock-roles]]
   ==== Roles
   
  +[[timelock-admin]]
   ===== 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`
   
  +[[timelock-proposer]]
   ===== 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.
  
positive.code: 
  {{TimelockController}}
  
  ==== 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 xref:access-control.adoc#operation_lifecycle[operation lifecycle]). If the operation contains multiple transactions (batch mode), they are executed atomically. Operations are identified by the hash of their content.
  
negative.code: 
  In the case of batched operations, `target`, `value` and `data` are specified as arrays, which must be of the same length.
  
  [[timelock-operation-lifecycle]]
  ==== Operation lifecycle
  
  Timelocked operations are identified by a unique id (their hash) and follow a specific lifecycle:
  