Timelock

Timelock Explained in Detail

A timelock delays sensitive actions such as upgrades, parameter changes, treasury transfers, and role changes. The action is queued first, then executed only after the delay expires.

The delay gives users, tokenholders, and monitoring systems time to react.

Transaction example

1. Queue: Governance schedules an upgrade.

2. Wait: The timelock delay must pass.

3. Execute: The action can be executed after the delay.

4. Monitor: Users can exit or respond before execution if the action is harmful.

Timelock in Auditing

Timelocks are part of the protocol trust model. A weak timelock can make a multisig, governance system, or upgradeable proxy look safer than it is.

Red flags in code

• Admin can bypass the delay.

• Delay can be reduced and used in the same governance cycle.

• Emergency role can execute arbitrary actions without constraints.

• Operation identity does not bind all execution-critical fields, such as target, value, calldata, predecessor or dependency, and salt.

• Timelock admin is an EOA or weak multisig.

• Upgrade authority is split across contracts without clear ownership.

How to test or review it

• Verify every privileged operation must pass through the timelock.

• Test queue, cancel, execute early, execute late, replay, and duplicate operation flows.

• Review who can change the delay and when the change takes effect.

• Check interaction with access control, multisig roles, and governance proposal execution.

• Confirm monitoring assumptions match the actual minimum delay.