You might have noticed that OpenZeppelin’s 3.3.0 includes a contract called
TimelockControler. This contract is different from other contract published by OpenZeppelin in the sense that it is not designed to be inherited from (such as
Ownable for example) but rather to work as a standalone contract).
The details of this contract are already described in the documentation, so I won’t go over it here.
What I’d like to present here, is a small CLI tool to help you interact with this timelock. Bear in mind this is work-in-progress, and that this code will be improved in the future. Consequently, your feedback will be greatly appreciated!
Here is the code! It is in the same repo as a similar tool to interact with erc1538 proxies … because I use my timelock as the owner of an erc1538 contract … but you don’t have to worry about this part.
To launch it, just install the dependencies with
npm i or
yarn i and then run
npm run start:timelock or
yarn start:timelock. You’ll then be asked many question to prepare and trigger the timelock operation of your choice.
In the first two cases, the CLI will ask you the details of the operation. This includes:
- A complete description of all the sub-call that are to be performed by the timelock.
- Each has a target address, a data field (default: empty) and a value (default: zero).
- A predecessor (default: 0x0)
- A salt: when scheduling this is by default filled with a random value, you’ll have to save it for the execution phase!
In addition, when scheduling an operation, you will be asked for a delay in seconds (default: 7 days) that should not be lower than the minimum delay of your timelock.
In the third case (cancel), only the operation id should wish to cancel is requested.
Once you entered all the details of the operation you wish to perform, you have the choice between:
- encoding the operation, which will give you a hexdump of the data you should send to the timelock to perform the corresponding operation
- executing the operation.
In the second case, you’ll have to provide additional information such as:
- The blockchain you are targeting
- The address of the timelock instance
- Details of the wallets you want to use. For now, this supports:
- private keys
- ledger hardware wallet
Additional tolling will come, depending on requests by the community. I’m thinking of:
- tooling to compute operation id from operation details
- tooling to read the details of the timelock contract
- tooling to manage the different roles (this goes way beyond just the timelock)