defirisk.co
rubric v1.7.0

Incident response time (minutes)

A operational history factor in the v1.7.0 rubric. Measured per protocol on a e cadence.

Methodology how we score#

What this measures
This factor records the elapsed time in minutes between the first on-chain transaction of the most recent exploit and the first official team statement (tweet, blog post, Discord announcement, or governance forum post) acknowledging the incident. For off-chain-initiated exploits where the on-chain drain is the primary event, the clock starts at the first anomalous transaction. This factor applies only to protocols with at least one prior incident; for protocols with no incidents it is marked gray.

Why it matters
Incident response time is a direct measure of monitoring maturity and operational preparedness. Badger DAO had malicious approvals visible on-chain for twelve days before the drain; Harmony Bridge's $100M exploit had a fourteen-hour detection lag before the team publicly acknowledged it. Fast detection and communication enables depositors to take protective action (withdrawing remaining funds) and allows the protocol to invoke emergency pause functions before the drain is complete. In the dataset, median response time across Medium and High detectability hacks was approximately forty-five minutes; protocols with sub-fifteen-minute response times generally had active monitoring infrastructure and pause capabilities.

Green / Yellow / Red
Green: first official team statement within fifteen minutes of first anomalous on-chain transaction. Yellow: response time between fifteen minutes and four hours. Red: response time exceeding four hours, or no public statement within twenty-four hours of confirmed drain.

Common gray cases
For off-chain-initiated exploits (e.g., private key compromise) where the first on-chain signal is the drain itself, response time is measured from first drain transaction to first public statement, which may be instantaneous if monitoring detected the key compromise. Curator judgment required on determining the correct clock-start event.

Notable historical examples
No cross-hacked incidents currently linked in database for this factor.

Measurement what to look for#

Measure the time in minutes from the first exploit transaction to the first official team statement for the most recent incident.

Data & output #

Data source
Exploit first-tx timestamp (Etherscan) + earliest team statement timestamp (Twitter/X, Discord, governance forum)
Output format
Green / Yellow / Red
Evidence artifact
Exploit tx hash + exploit block timestamp + team statement URL + statement timestamp + minutes-delta
Confidence signal
green = ≤60 min; yellow = 61–240 min; red = >240 min or no statement; gray = no prior incidents (N/A)

Scored protocols 0 carry this factor#

No protocols have been scored for this factor yet.

Linked hacks 1 historical incident#

illustrativeVenus Protocol (zkSync Era deployment): Empty-market donation attack on a freshly-deployed market with no virtual liquidity / no `_decimalsOffset()` first-depositor protection2025-03-29 · $902K · Empty-market donation attack on a freshly-deployed market with no virtual liquidity / no `_decimalsOffset()` first-depositor protection · Part of Venus chronic-pattern cluster (this + 2026-03-15 BNB Chain incident) per PD-022
rubric_version v1.7.0factor RD-F-085category 5carried 0critical no