★ Rescue/emergencyWithdraw without timelock
A governance & admin factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score #
**What this measures** This factor identifies whether a protocol exposes a rescue() or emergencyWithdraw() function callable by an admin address without any timelock delay on execution. Static analysis of the deployed bytecode combined with on-chain role checks determines whether such a function exists, who can call it, and whether the call path bypasses the protocol's declared timelock. The absence of a timelock on a function capable of extracting all user funds is the trigger condition, regardless of the protocol's stated operational intent.
**Why it matters** A rescue function that can be executed immediately by a single admin collapses the security model to a single key's integrity. Even when designed for legitimate emergency use, such a function creates a one-transaction full-drain vector: compromise the admin key, call rescue(), protocol is empty. Industry security research consistently flags unrestricted admin withdrawal functions as among the highest-severity centralization risks because they give the admin more power than the protocol's governance framework was designed to grant. The T-01 evidence base records approximately ten in-sample hacks where this pattern contributed to fund loss, typically in combination with a deployer-retained admin role. When a legitimate emergency mechanism exists, the correct implementation chains it through a timelock that gives users time to exit — eliminating the immediate-drain path while preserving the emergency capability.
**Green / Yellow / Red** Green is assigned when no rescue or emergencyWithdraw function exists, or when any such function is subject to the same timelock as upgrade operations (minimum 24 hours). Yellow covers protocols where a rescue path exists with a shorter-than-recommended timelock (6–24 hours) or where the function is restricted to a hardware-secured multisig above a meaningful threshold. Red is assigned when a rescue or emergencyWithdraw function is callable by a single admin role or low-threshold multisig with no timelock delay — regardless of how the function is labeled in documentation.
**Common gray cases** This factor is grayed when the source code for relevant contracts is unavailable or when the protocol uses a novel architecture where equivalent drain capability is unclear from on-chain inspection alone.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
**★ Critical factor** This factor alone is sufficient to trigger a D or F grade under rubric v1.7.0 — a single red assessment here overrides all other category scores. An immediately-executable rescue function is structurally equivalent to an admin withdrawal backdoor: any key compromise or insider threat converts it into a single-transaction full protocol drain.
Measurement what to look for #
Determine whether a `rescue(…)` or `emergencyWithdraw(…)` function exists callable by admin without a timelock delay on execution.