DeFi hacks by auditor: historical scope matters more than a badge

Method and sources: establish the relationship before naming the firm

A defensible comparison of DeFi hacks by auditor must connect an incident to the specific code and deployment an auditor reviewed. A protocol logo next to an audit logo is not enough. The same project can have several implementations, multiple reviewers and substantial changes between a report and an exploit.

Begin with two independent records.

The incident record identifies the affected component, exploit date and mechanism. The audit record identifies the reviewer, scope, source revision and review date. Only after comparing them should the cross-reference assign an in-scope or out-of-scope conclusion. If the connection is missing, the correct status is unknown.

Use original protocol statements and technical investigations for the incident, then open the report itself for scope. A later vendor announcement can identify additional work but cannot establish that the work preceded the attack. Preserve both dates and explain whether the page describes an initial review, fix review or postincident reassessment.

The cases here illustrate those evidence distinctions.

They are not a representative sample of auditor performance. We do not calculate a failure rate, rank firms by loss or infer that a named reviewer caused a later exploit. Such claims would require exposure and scope data that the opened sources do not provide.

Incident date

When the affected operation occurred, distinguished from disclosure or recovery dates.

Report date

The date stated by the report or completion announcement, with its exact meaning preserved.

Scope relationship

Whether evidence links the exploited path and deployment to the reviewed revision.

Audit age

Calendar time between the stated audit date and incident date, not the age of every line of deployed code.

Unknown

A relationship that the opened evidence does not establish; it is not an implicit clean or failed verdict.

A useful cross-reference also records disagreement.

One source may value assets at extraction while another reports an outstanding liability after partial recovery. Those numbers cannot be swapped into the same loss field without changing its meaning. Prefer an explicit definition and an unresolved comparison over a falsely precise total.

Current badges are especially weak historical evidence.

A protocol can commission a review after an incident, replace a component or rebuild its architecture. Those are relevant facts about later security work. Keep them in a later-work field rather than using them to rewrite the earlier scope.

Our catalog check: 913 DeFi rows without audit provenance fields

The retrieved DeFiLlama hacks response contained 1,253 rows.

Selecting the exact targetType value DeFi Protocol yielded 913 rows. Inspecting the union of keys across the entire response found no explicit auditor, audit-report or reviewed-revision field. A direct join from this endpoint to an auditor ranking would therefore require outside evidence.

Method

Source

DeFiLlama public hacks endpoint

Retrieved

September 5, 2026

Selection

All returned rows with targetType exactly equal to DeFi Protocol.

Schema check

Inspect keys across every returned record for explicit audit or review-scope provenance.

Denominator

913 selected records from 1,253 total records, without deduplication.

Missing-data rule

Empty and absent source information remains missing. No current audit badge is substituted for historical scope.

Results

The schema includes incident labels, amounts and other descriptive fields, but these do not establish who reviewed the exploited code. The absence is a limitation of this retrieved endpoint, not a claim that DeFiLlama or the affected protocols have no supporting information elsewhere.

Limits

• Rows are publisher catalog entries and were not deduplicated into proven unique events.
• No incident amount is independently validated by this schema census.
• A missing audit field is not evidence that a protocol was unaudited.
• The selected target type excludes other labels, including some bridge or governance contexts that may still be relevant to a specific investigation.

Reproduction uses seo/research/incident-evidence-fields-survey.py; its dated output is seo/research/incident-evidence-fields-survey-2026-09-05.json. These files remain in the repository and are not published as downloads. The output preserves source responses, retrieval outcomes and the selection rules for later verification.

Incident-to-auditor cross-reference

Beanstalk's completion announcement states that Omniscia audited its core contracts through BIP-7 and gives April 2, 2022 as completion. The protocol's incident account dates the governance attack to April 17, 2022. Subtracting those calendar dates gives 15 days. That interval establishes chronology, not proof that the attack payload was covered.

Nomad's historical Quantstamp report is dated June 6, 2022.

Coinbase's technical analysis identifies a relevant infrastructure upgrade on June 21, 2022 and the incident on August 1, 2022. The report-to-incident interval is 56 calendar days. The intervening change makes a deployed-revision comparison necessary.

Ronin's reopening account names CertiK and Verichains in a reassessment following the March 2022 exploit. The account was published on June 28, 2022. Neither that publication date nor those names establish preincident coverage. The row remains a postincident relationship.

Beanstalk's audit completion announcement, its incident account, the Quantstamp Nomad report, Coinbase's Nomad analysis and Ronin's reopening statement support the rows.

The local evidence record is seo/research/historical-audit-links-2026-09-05.json. It preserves the date inputs, subtraction method and unresolved relationships. The cases were selected to demonstrate evidence categories, not to estimate a population statistic.

Read the loss column before comparing values.

The Ronin row uses asset quantities rather than a dollar conversion. The Beanstalk figure excludes Beanstalk-native user assets under the protocol's stated definition. The Nomad figure uses the technical analysis's dollar estimate. This article does not sum those unlike measures.

An unknown scope match is deliberately visible.

It prevents the table from implying either that the auditor missed the exploit or that the exploited code was outside the engagement. Both assertions need more evidence than a dated report and a dated incident.

For Nomad, the report lists a source revision including 17f0557 for its monorepo. That identifier is a starting point for a comparison, not a deployed-bytecode certificate. A reviewer must identify the later implementation and determine whether the relevant changes, initialization state and integration assumptions were included.

Patterns: what the cross-reference can and cannot tell you

The first pattern is a date mismatch disguised as a firm relationship. A company may truthfully say it audited a protocol, and the protocol may truthfully say it suffered a hack. Those statements do not establish that the firm audited the attacked implementation before the incident. The missing predicate is the scope and timing connection.

A second pattern is component substitution. A token audit, bridge review, compiler assessment and operational penetration test examine different surfaces. Attaching the broadest project name to each report can make them look interchangeable. The cross-reference should identify the component whose behavior enabled the incident and the component the report actually reviewed.

The third pattern is revision drift. An application can preserve its public brand and contract address while an upgrade changes its logic. A report tied to the earlier revision remains useful history, but the current deployment needs another comparison. The same applies to dependencies and initialization parameters that the code assumes.

Audit age is therefore a descriptive interval, not a quality score. A short interval can coexist with an out-of-scope deployment change; a long interval can coexist with unchanged relevant code. Use the age to locate changes worth inspecting. Do not convert it into a claim that older reports are automatically invalid or newer reports guarantee safety.

A related finding deserves careful reading. For example, an initializer observation in a historical report does not automatically explain a later message-verification failure. Similar vocabulary can connect different mechanisms. Preserve the finding identifier and reconstruct the causal chain before describing it as the missed exploit.

Remediation status is another boundary. A team can acknowledge a risk, apply a fix or provide a different design assumption. Those dispositions have different meanings. A public summary that says all issues addressed can conceal whether addressed means removed, mitigated or accepted. Read the report's terminology and final revision.

The performance denominator is harder still. To compare auditors, one would need the population of their relevant engagements, code and asset exposure, observation time, deployment changes and comparable incident ascertainment. A count of hacked clients supplies only part of the numerator and can be biased toward firms with more visible or more complex work.

There is also survivorship and disclosure bias. Private engagements may never appear in a public archive, while an incident can trigger publication of reports that were previously hard to find. Treating the public sample as the whole market would confuse visibility with coverage. The schema census above establishes precisely why a simple automated table cannot resolve that gap.

Incident path

Identify affected behavior.

Reviewed revision

Open the original scope.

Deployment match

Establish the relationship.

The report reading guide and report authenticity checks help locate the evidence needed before making these judgments.

Review cadence: maintain a correction trail

Review the cross-reference when a primary source changes the incident mechanism, loss definition or audit relationship. A new postmortem can resolve an unknown field; a new deployment comparison can overturn an earlier assumption. Keep the old value and the reason for the change so another reader can follow the evidence.

Use a stable record structure for each case. Preserve the incident identifier, affected component, source revision, report URL and dates. Add the exact source supporting an in-scope conclusion rather than leaving it as an editor's unexplained verdict. If an artifact disappears, retain the retrieval evidence and mark the public link's current status.

The correction process should be symmetrical. Evidence can show that a report did cover the relevant path, that a later change introduced it or that the initial incident explanation was incomplete. The purpose is an accurate historical relationship, not a table designed to defend or accuse a particular firm.

Do not update only the headline figure. A changed loss definition may require edits to the description, key facts, table and narrative. A changed scope conclusion may also affect which examples belong in a provider comparison. Keep those dependent claims together in the editorial record.

1. Open the new primary artifact and record its publication and retrieval dates.
2. Identify which field it supports and whether it conflicts with the existing source.
3. Recompute date intervals from explicit inputs; do not overwrite a missing date with an estimate.
4. Compare report scope with the affected deployment before changing an attribution status.
5. Publish a dated correction explaining the evidence and the remaining uncertainty.

For procurement, this cross-reference supports targeted questions. Ask how the proposed engagement binds findings to the final deployment, handles fix rounds and treats later changes. Request a comparable report and a clear residual-risk record. A vendor's absence from a public incident list is not a substitute for those deliverables.

The audit RFP guide and audit-company analysis hub help structure that conversation. The Halborn profile analysis is a provider reference, not an incident-performance rating.

A release team can also improve future investigations by publishing its own revision map. Identify the report, final reviewed commit, deployed implementation and material configuration changes. That record gives later readers a way to determine which assurance claim applied at a particular time without reconstructing the relationship from marketing pages.

The question which audited protocols got hacked is answerable only at the right level of detail. A dated report can establish that an audit existed. The stronger question, whether the attacked path was in that audit, requires the scope comparison. Preserve that distinction whenever a firm name appears beside a loss.

Entity matching needs a review step too. A protocol may change its name, deploy a second version or share branding with a separate product. An auditor can also rebrand. Match the legal or operating entity and the report's own attribution before merging records, then retain the original name used by the source. Similar text is not enough to establish identity.

Apply the same care to component addresses. A proxy address can remain stable while its implementation changes, and a token address does not identify the bridge or lending component that used it. Store the affected address and its role, then compare the relevant implementation at the incident state. A current explorer page can supply current information while obscuring that historical distinction.

If the required historical artifact is unavailable, make the next evidence request specific. Ask for the report's reviewed commit, the final fix revision or the deployment transaction, depending on the missing link. An investigator can act on those requests; a generic request to prove that the project was audited is more likely to produce another badge or announcement.

Keep alternative explanations alive until that comparison is complete. The failure could involve an omitted scope, a later change, an accepted risk or an error within the reviewed code. These possibilities have different implications for future procurement and engineering, so they should not collapse into one blame label.