Most repeat exploits arrive through a different door: 63 protocols, and what that might mean for remediation evidence

[Foreshock]

I run an independent risk scoring dataset for DeFi protocols, and something in it keeps bothering me that seems relevant to how remediation evidence gets weighed here. So I wanted to put it in front of people who price this for a living.

Our incident ledger holds 63 protocols that have been exploited more than once. Only 19 of them were hit the same way twice. The other 44 came through a different door: reentrancy then oracle, key compromise then frontend, governance then access control.

Median gap between the first hack and the second is 269 days, and 57% land inside a year. Long enough for the fix to look like it worked.

That is the part I keep turning over. A post-incident fix proves one class of failure got closed. It does not seem to say much about the next one. And if that holds, a second incident looks closer to a property of the team and its surface area than of the bug that was fixed.

I would rather be argued with than agreed with here, so the caveats. The ledger is built from public incident reporting and is certainly incomplete, especially for smaller protocols and non-EVM chains. The attack class boundaries are ours, so 19 of 63 moves if you draw them somewhere else. And our own rubric is not a predictive model: more than half our readings, 54 of 104, rest on no comparable history at all, and every one of those pages says so.

Method and sources are published alongside every reading: https://foreshock.tech

What I actually want to know is this. When you assess cover for a protocol with one prior incident, does “same class as before” get weighted differently from “any class”? On these numbers those look like very different bets, and I suspect people here have a view I do not.

[BraveNewDeFi]

We have an extensive database where we track loss events across different loss categories. For onchain losses, our database tracks events going back to 2016. We use this loss information to create the histograms we use for pricing protocols/platforms after we complete our due diligence process.

When a protocol is exploited, the expected loss is higher as a result. There are many indicators, though, that will heighten EL even if a loss event hasn’t occurred. We track numerous factors and datapoints during our due diligence process.

[Foreshock]

That is useful, thank you. The part I am still turning over is whether the vector matters to expected loss or only the event.

In our ledger the second incident usually arrives through a different class than the first, and the median gap is long enough that the original fix looked like it held. If expected loss rises on the event alone, then a team that closed a reentrancy bug and was later taken through an oracle is priced the same as one taken the same way twice. If your due diligence factors already separate those two cases, that answers it.

So the narrow question: does a repeat loss through a new class move expected loss differently from a repeat through the same class, or does the histogram treat both as one loss event with a higher count?