Timelock on sensitive actions
Cap (cUSD / stcUSD)'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 #
Upgrades route through Timelock (confirmed via Upgraded events). However, rescueERC20 and pause/unpause appear admin-executable without mandatory Timelock routing on the function call itself — the AccessControl system grants per-selector roles, and role-holders can call functions directly once granted. 3-of-5 action types timelocked (upgrade, param-change), but rescue/pause direct execution path exists.
Sources #
- DocsCap docs — admin permissionsProtocol docs: 'emergency withdraw, and rescue ERC20' listed as admin permissions alongside upgradesretrieved 2026-05-17
- Vault.sol — rescueERC20 functionVault.sol: rescueERC20() uses checkAccess(selector), not a Timelock wrapper. No mandatory delay on rescue execution.retrieved 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 →