Timelock Operations¶

The governor enforces a minimum deployment delay of seven days through MINIMUM_LONG_TIMELOCK. Each operation still needs human monitoring; a timelock is useful only if someone watches it and can cancel.

Operation Data¶

hashOperation commits to:

• target type (TransparentProxy or Beacon);
• target address;
• implementation address;
• contract kind;
• implementation version;
• economic policy hash;
• salt;
• calldata;
• expected initialized version.

Reviewers must reproduce the operation id independently before queueing.

Before Proposal¶

• Build implementation from reviewed source.
• Confirm metadata functions return expected values.
• Confirm code hash from on-chain address matches artifact.
• Verify storage-layout compatibility.
• Decode initializer/reinitializer calldata.
• Confirm target registration and kind.
• Confirm blast-radius review and rollback/cancel plan.

Proposal¶

PROPOSER_ROLE calls proposeUpgrade. The governor validates target registration and implementation metadata, stores the operation, and emits UpgradeProposed. Proposal alone does not start the delay.

Queue¶

QUEUER_ROLE calls queueUpgrade. This sets queuedAt and readyAt. From this point until execution, monitoring must treat the operation as actionable risk.

Monitoring Window¶

During the delay:

• decode every event and compare to release plan;
• re-read implementation code hash;
• watch role changes and registrar changes;
• keep CANCELLER_ROLE online;
• publish internal go/no-go status before readyAt.

Execute¶

EXECUTOR_ROLE can execute after readyAt. For transparent proxies, the governor calls upgradeToAndCall and can verify proxyInitializedVersion. For beacons, calldata must be empty because per-vault reinitialization is not atomic.

Cancel¶

CANCELLER_ROLE can cancel before execution. Cancel if metadata drifts, artifact evidence is incomplete, threat intelligence changes, calldata is wrong, target registration is suspicious, or a signer compromise is suspected.