Timelock duration on upgrades
Midas's assessment for RD-F-032 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
TimelockController 0xe3eee3e0 has minDelay=172800s (48h) — meets green threshold per methodology. However: (1) Only one of three post-launch upgrades used this timelock (Dec-2025 Issuance Vault); (2) Sep-2024 mTBILL upgrade and Apr-2025 upgrade bypassed via direct ProxyAdmin EOA; (3) The timelock was only deployed ~249 days ago. Yellow: timelock exists and meets duration criteria, but enforcement is inconsistent — prior upgrades bypassed it.
Sources #
- TxSep-2024 upgrade — direct EOA bypassSep-2024 mTBILL upgrade: no TimelockController events; direct EOA 0x875c06A2 callerretrieved 2026-05-16
- Dec-2025 upgrade tx — Safe+Timelock pathDec-2025 Issuance Vault upgrade used timelock (CallExecuted from 0xe3eee3e0 visible in event log)retrieved 2026-05-16
- TimelockController — EtherscanTimelockController 0xe3eee3e0: getMinDelay()=172800 seconds confirmed in constructor args and contract readsretrieved 2026-05-16
Methodology #
Read the timelock delay (in hours) between a queued upgrade proposal and its executable state.
See the full factor methodology and distribution across all protocols →