Timelock duration on upgrades
Convex Finance'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 general OZ TimelockController exists. BoosterOwner has a bespoke 30-day (2,592,000 second) delay ONLY on the forceShutdown emergency path (queueForceShutdown -> forceShutdownSystem). Routine admin calls (fee changes, pool management, stash factory, vote delegation, pool shutdowns) execute immediately upon 3-of-5 multisig signature with 0-hour delay. Effective timelock for routine operations: 0 hours. For forceShutdown emergency only: 720 hours (30 days).
Sources #
- DocsConvex Finance -- Known IssuesBoosterOwner forceShutdown 30-day mechanism describedretrieved 2026-05-16
- Convex BoosterOwner.sol -- GitHub sourceBoosterOwner.sol: FORCE_DELAY = 30 days; queueForceShutdown() / forceShutdownSystem() pattern; routine calls not timelockedretrieved 2026-05-16
- Convex Finance -- Multisig Admin RightsAdmin controls do not have access to user funds and thus time-lock delays are not requiredretrieved 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 →