★ Rescue/emergencyWithdraw without timelock
Cap (cUSD / stcUSD)'s assessment for RD-F-041 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
[★ CRITICAL] rescueERC20(address _asset, address _receiver) exists in Vault.sol gating cUSD/stcUSD TVL, callable by whoever holds the per-selector role via checkAccess(). The AccessControl system allows direct execution by the role-holder without mandatory Timelock delay on the rescue call itself. Deployer EOA (0xc1ab...b52) holds Timelock EXECUTOR role independently (can execute scheduled operations without Safe co-sig). Protocol docs confirm 'rescue ERC20' as an admin emergency permission. Single-tx drain risk if role is currently held by an address other than the dev multisig.
Sources #
- GitHubVault.sol — rescueERC20 function (no timelock on execution)Vault.sol: function rescueERC20(address _asset, address _receiver) external checkAccess(this.rescueERC20.selector) — no Timelock wrapper on executionretrieved 2026-05-17
- Cap docs — emergency permissionsProtocol docs: 'emergency withdraw, and rescue ERC20' listed as admin permissions; AccessControl-gatedretrieved 2026-05-17
- Cap TimelockController — executor role includes deployer EOATimelock executors include 0xc1ab5a9593E6e1662A9a44F84Df4F31Fc8A76B52 (deployer EOA) — can execute scheduled operations without Safe co-sigretrieved 2026-05-17
Methodology #
Determine whether a `rescue(…)` or `emergencyWithdraw(…)` function exists callable by admin without a timelock delay on execution.
See the full factor methodology and distribution across all protocols →