Timelock Contract
OpenZeppelin Timelock Controller for governance delay on critical protocol actions.
Source: contracts/timelock/
Overview
The Timelock enforces a minimum delay on governance operations. Critical protocol changes (fee updates, asset whitelisting, contract upgrades) must be scheduled, wait for the delay to pass, and then be executed. This gives protocol participants time to review and react.
Operation Lifecycle
Unset → Waiting → Ready → DoneUnset
Operation doesn't exist yet
Waiting
Scheduled, waiting for delay to pass
Ready
Delay has passed, can be executed
Done
Successfully executed
Roles
Proposer
Can schedule new operations with a delay
Executor
Can execute operations once they are ready
Canceller
Can cancel pending operations before execution
Integration with Globals
The Timelock is set as the admin of the Globals contract during deployment. This means:
All admin-gated functions on Globals (
set_settings,add_supported_asset,set_fee, etc.) require Timelock authorisationTo change a global setting, a Proposer must schedule the operation, wait for the delay, then an Executor executes it
This prevents instant, unilateral changes to critical protocol parameters
Self-Administered
The Timelock is deployed as self-administered — it is its own admin:
No single external address can bypass the time delay
The Timelock's own settings (minimum delay, roles) can only be changed through the Timelock itself
This creates a fully decentralised governance loop
Deployment
min_delay— Minimum seconds between scheduling and executionproposers— Addresses that can schedule operationsexecutors— Addresses that can execute ready operationsadmin: None— Self-administered (no external admin)
Test Coverage
14 tests covering:
Operation lifecycle (schedule → ready → execute)
Cancellation before execution
Delay enforcement
Role-based access control
Integration with Globals contract (scheduling admin-gated operations)
Last updated