Timelock duration on upgrades
ether.fi'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 #
On-chain getMinDelay() = 3,600 seconds (1 hour). At $5.1B TVL this is materially below industry standard. Lido uses 24h, MakerDAO uses 48h, Compound uses 48h. A 1-hour window provides minimal user-exit protection if a malicious upgrade is proposed. Profile noted a potential '3-day operational policy' but on-chain minimum is the binding constraint.
Sources #
- EtherscanEtherFiTimelock — getMinDelay = 3600sEtherFiTimelock readContract: getMinDelay() = 3600retrieved 2026-04-28
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 →
rubric_version v1.7.0 protocol ether-fi factor RD-F-032 score yellow collected_at 2026-04-28 13:58:46