Avg attacker reconnaissance time for peer-class protocols
A threat intelligence & recon factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score #
**What this measures** This static factor records the average number of days of documented reconnaissance activity — on-chain probing, test transactions, mixer wallet preparation — by attacker-labeled wallets before executing a strike on peer-class protocols in the hack database. The value is derived from curator analysis of the hack database and is protocol-class-specific: lending protocols, bridge protocols, and DEXes each have documented reconnaissance lead times. Output is a days-value benchmark for the class, updated when new post-mortem evidence expands the database. Category 11 context: the reconnaissance window benchmark tells curators how much advance warning time is theoretically available and frames the urgency of real-time signal response.
**Why it matters** The T-01 synthesis documents the detection window distribution across 37 hacks: High detectability hacks had reconnaissance windows up to 12 days (Badger DAO's malicious approvals), Medium detectability hacks typically had hours to days of pre-exploit on-chain activity, and Low/None detectability hacks had zero advance signal. For the lending protocol class, oracle manipulation setup is typically executed within the same transaction or within minutes, while governance attack preparation can span 24 hours or more. Bridge exploits involving social engineering (DPRK implant class) have the longest reconnaissance windows — months to years. The benchmark informs alert threshold calibration for Cat 6 signals for this protocol class.
**Green / Yellow / Red** Green is informational — a longer reconnaissance window benchmark is more favorable as it provides more actionable alert time. Yellow applies when the benchmark for the class is less than 24 hours — most signals will fire during or after the exploit. Red applies when the class benchmark is under one hour — Cat 6 signals become primarily exploit-in-progress rather than precursor alerts.
**Common gray cases** Gray applies when the hack database has insufficient examples of the specific protocol class to compute a reliable benchmark (fewer than three in-sample exploits), or when the protocol combines multiple classes making the applicable benchmark ambiguous.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for #
Report the average number of days of attacker reconnaissance activity before a strike on peer-class protocols (lending/DEX/bridge/perps), sourced from the hack database.