anchor.diff:  
   This role is identified by the *PROPOSER_ROLE* value: `0xb09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1`
   
  +[[timelock-executor]]
   ===== 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 executor 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.
  
positive.code: ** *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.
  
  ==== Operation structure
  
  Operation executed by the xref:api:access.adoc#TimelockController[`TimelockControler`] 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.
  
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:
  