Timelock on sensitive actions
Yearn 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 #
TimelockController (7d) covers protocol-level governance changes. However, V3 individual vault role assignments (who gets EMERGENCY_MANAGER, DEBT_MANAGER etc.) are set by role_manager (ychad-controlled) without per-action timelocking. V2 vaults are immutable — no relevant sensitive actions possible. Not all 5 sensitive action types (mint/pause/rescue/setOracle/upgrade) uniformly timelocked at vault level; 2-3 of 5 timelocked at protocol level.
Sources #
- DocsyVaults V3 Overview — Yearn Docsdocs.yearn.fi/developers/v3/overview — role assignment architectureretrieved 2026-05-16
- Yearn V3 TECH_SPEC.mdyearn-vaults-v3 TECH_SPEC.md — role_manager controls all vault roles; no individual role-assignment timelockretrieved 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 →