★ Post-audit code changes without re-audit

Methodology how we score #

**What this measures** This factor counts the number of deployed changes to previously-audited bytecode for which no subsequent audit or targeted spot review is on record. The assessment compares the deployed bytecode hash at the time of the most recent audit against the current deployed bytecode, then cross-references any changes against the protocol's published audit history. Changes introduced after the audit cutoff that are not covered by a subsequent review increment this factor's count; a non-zero count triggers a red assessment.

**Why it matters** Post-audit code changes are the most reliable predictor of upgrade-introduced vulnerabilities in the evidence base. The synthesis identifies this as the second-most impactful risk factor by dollar volume: Euler Finance ($197M) shipped a donateToReserves function that was specifically reviewed by Sherlock but contained the exploited flaw; GMX V1, Hedgey Finance, PancakeBunny, Pickle Finance, and Penpie all share the same structural failure — new code shipped without holistic re-audit, and the new code is where the vulnerability lived. The core insight is that time-since-last-upgrade is a more useful risk signal than time-since-last-audit: an audit is a point-in-time certification of a specific bytecode, and its assurance expires the moment any audited contract is modified.

**Green / Yellow / Red** Green is assigned when the current deployed bytecode hash matches the audited commit, or when any post-audit changes are fully covered by a subsequent professional audit or targeted spot review by a recognized firm. Yellow covers cases where one or two minor changes (parameter-only adjustments, non-logic updates) are unaudited but their scope can be bounded by curator review. Red is assigned when any logic change to an audited contract — particularly in reward distribution, collateral accounting, liquidation, or access control — has been deployed without subsequent audit coverage.

**Common gray cases** This factor is grayed when the bytecode comparison cannot be completed due to source verification gaps, or when the protocol uses an immutable (non-upgradeable) architecture where post-audit changes are structurally impossible.

**Notable historical examples** - **PancakeBunny** ($45M, 2021): VaultFlipToFlip upgrade was not audited by Haechi; the new vault contained the exploited flash-loan manipulation path. - **Hedgey Finance** ($44.7M, 2024): Post-audit contract version introduced the vulnerability; Ethereum and Arbitrum drained simultaneously. - **Penpie** ($27M, 2024): Post-audit permissionless market registration introduced the reentrancy path; three audit firms had reviewed earlier code. - **Pickle Finance** ($19.7M, 2020): ControllerV4 strategy added after audit completed; contained the exploited cross-strategy drain. - **Safemoon** ($8.9M, 2023): Public burn() function introduced in an upgrade six hours before exploit; no re-audit of the change.

**★ Critical factor** This factor alone is sufficient to trigger a D or F grade under rubric v1.7.0 — a single red assessment here overrides all other category scores. Post-audit code changes without re-audit are the structural mechanism by which protocols convert a high-assurance codebase into an unreviewed one — the Euler Finance lineage demonstrates that even well-resourced protocols with multiple auditors cannot treat audited status as permanent once code changes.

Measurement what to look for #

Count deployed changes to audited bytecode where no subsequent audit or spot-review covers the changed code.

Data & output #

Scored protocols 80 carry this factor #

Linked hacks 9 historical incidents #