★ Rescue/emergencyWithdraw without timelock
Veda (BoringVault)'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 #
[U18 RE-CITED — score unchanged] No discrete rescue/emergencyWithdraw function. The manage() + setManageRoot() pathway is the structural equivalent. Control path [U18 CONFIRMED]: 3-of-5 Safe (0xD6E47E0F34ECc031E676254fd8b0E61b656a15a5) → TimelockController (0x80Ce8a917beec6Db0f632F2710916fcaA621874A, minDelay=0) → RolesAuthority → setManageRoot(). The 3-of-5 Safe adds a coordination requirement (3-of-5 signer agreement) but does NOT add a time delay — a coordinated 3-of-5 can change the merkle root in a single transaction with zero enforced delay for user exit, authorizing the strategist to drain ~$1.07B in assets. This is structurally equivalent to an un-timelocked rescue/drain pathway. Critical for vault-infrastructure protocol at this TVL.
Sources #
- GitHubManagerWithMerkleVerification.sol — setManageRoot no timelockManagerWithMerkleVerification.sol: setManageRoot(address strategist, bytes32 _manageRoot) external requiresAuth — no delay, no timelockretrieved 2026-05-17
- Safe Transaction Service mainnet — 3-of-5 confirmed (U18), zero delay pathSafe Transaction Service mainnet API: Safe 0xD6E47E0F confirmed threshold=3, owner_count=5 — 3-of-5 coordination required but no time delay (U18)retrieved 2026-05-17
- TimelockController — zero delay for admin actionsTimelockController constructor minDelay=0 — no enforced delay before admin execution; proposer/executor = 3-of-5 Safe 0xD6E47E0F (U18 confirmed threshold=3)retrieved 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 →