Timelock on sensitive actions

Convex Finance's assessment for RD-F-033 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.

Evidence summary #

Timelock presence per sensitive action: mint=N/A (operator-only, not admin); pause/shutdownPool=NO timelock (immediate multisig); rescue=N/A (no rescue function); setOracle=N/A (no oracle in core path); upgrade=N/A (immutable contracts); setFees=NO timelock; setVoteDelegate=NO timelock; forceShutdown=YES 30-day timelock via BoosterOwner. Majority of admin-callable sensitive actions have no timelock.

Sources #

GitHub
Convex BoosterOwner.sol -- GitHub sourceBoosterOwner.sol: FORCE_DELAY = 30 days; queueForceShutdown / forceShutdownSystem only timelocked callsretrieved 2026-05-16
GitHub
Convex Booster.sol -- GitHub sourceBooster.sol: setFees, shutdownPool, setOwner, setVoteDelegate -- all onlyOwner or role-gated, no timelock. BoosterOwner: FORCE_DELAY on forceShutdown only.retrieved 2026-05-16

Methodology #

For each sensitive action category (mint / pause / rescue / setOracle / upgrade), determine whether execution requires going through the declared timelock.

See the full factor methodology and distribution across all protocols →

rubric_version v1.7.0 protocol convex-finance factor RD-F-033 score yellow collected_at 2026-05-16 02:41:28