★Audit scope mismatch

Methodology how we score#

What this measures
This factor assesses whether the runtime bytecode deployed on-chain for all contracts holding user funds corresponds exactly to the code covered by the protocol's most recent audit report. A mismatch is recorded when the audit document cites a specific commit hash or contract address and the live deployed bytecode differs from the bytecode at that reference point. Assessment is performed via bytecode diffing against Etherscan-verified source and audit PDF metadata.

Why it matters
Audit scope mismatch is the single most frequent factor in the cross-hack database, appearing as a contributor in more than 25 documented exploits. When deployed code diverges from audited code, the entire security assurance of the audit is voided for that surface -- yet the protocol can still truthfully claim to have been audited, creating false confidence for depositors. Trail of Bits has documented that low-level proxy upgrade patterns hinder static analysis, compounding the risk that post-audit divergence goes undetected by standard tooling. Seven of thirteen audited protocols in the dataset were exploited via code explicitly outside audit scope, making this the clearest single indicator that an audit label is not a safety guarantee.

Green / Yellow / Red
Green: all contracts holding user funds have runtime bytecode matching the commit hash cited in the most recent audit, with no unaudited modifications post-deployment. Yellow: minor peripheral contracts (fee collectors, reward distributors) are unaudited, but core lending or bridge logic is fully covered. Red: the primary contracts holding user funds contain code that was not reviewed in any audit, or the deployed bytecode hash differs materially from the audited commit with no delta-audit covering the change.

Common gray cases
Curators legitimately cannot grade this factor when the protocol does not publish its audit report with a commit hash reference, or when Etherscan source verification is absent and bytecode diffing is therefore impossible.

Notable historical examples
- Compound Finance ($147M, 2021): Proposal 62 introduced a new Comptroller upgrade not covered by prior audit; the drip() vulnerability lived in the unaudited code.
- Fei/Rari Fuse ($80M, 2022): Partial patch to CToken and Comptroller left exitMarket() uncovered; the introduced gap was in post-audit code.
- PancakeBunny ($45M, 2021): Team upgraded to VaultFlipToFlip contracts after the Haechi audit closed; the flash-loan vector was in the unaudited upgrade.
- Hedgey Finance ($44.7M, 2024): Vulnerable createLockedCampaign() function was deployed after audit completion.
- KyberSwap Elastic ($48M, 2023): Sub-microscopic precision failure survived multiple audit rounds; deployed bytecode had diverged from reviewed code.

* Critical factor
This factor is critical under rubric v1.5: a single Red assessment here is sufficient to trigger a D or F grade regardless of all other category scores, because an unaudited primary attack surface nullifies the protocol's core security assurance.

Measurement what to look for#

Check whether the commit SHA cited in the audit report matches the bytecode deployed at the production proxy/implementation address.

Data & output #

Scored protocols 0 carry this factor#

Linked hacks 65 historical incidents#