Timelock duration on upgrades
Babylon Protocol'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 #
No Ethereum TimelockController exists. Effective delay is the governance voting period: 3 days standard (72h) or 1 day expedited (24h). V2 upgrade used a 4-day window (proposal Jun 12 → activation Jun 16). V4 upgrade had 3-day voting period (Nov 10-13). 72h meets the green threshold (≥48h) for standard proposals, but expedited path allows 24h. Graded yellow: expedited path is structurally available and reduces effective timelock to 24h for certain proposals.
Sources #
- DocsGovernance | Babylon DocsGovernance parameters: standard 3-day voting, expedited 1-day votingretrieved 2026-05-04
- Babylon Genesis V2 UpgradeV2 upgrade timeline: proposal Jun 12 → activation Jun 16, 2025 (4 calendar days)retrieved 2026-05-04
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 →