Timelock on sensitive actions
Veda (BoringVault)'s assessment for RD-F-033 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
setManageRoot() in ManagerWithMerkleVerification requires only requiresAuth — no on-chain timelock. This is the most critical admin action (controls the entire strategist action set for ~$1.07B). pause()/unpause() on Manager: requiresAuth, no timelock. Rate updates in Accountant: minimumUpdateDelayInSeconds is a soft pacing guard, not a governance timelock. Admin role changes via RolesAuthority now route through TimelockController with minDelay=0 — effectively no delay. The 3-of-5 Safe path adds coordination cost but zero time delay for any of these actions.
Sources #
- GitHubAccountantWithRateProviders.sol — rate update pacing onlyAccountantWithRateProviders.sol: minimumUpdateDelayInSeconds max 14 days (soft pacing, not governance timelock)retrieved 2026-05-17
- ManagerWithMerkleVerification.sol — setManageRoot no timelockManagerWithMerkleVerification.sol: function setManageRoot(address strategist, bytes32 _manageRoot) external requiresAuth — no delay mechanismretrieved 2026-05-17
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 →