Follow the Patch Trail — How Prior Audit Fixes Map the Bugs Nobody Found Yet

Most auditors read a codebase from the entry points outward. There is a faster first move: read the fix IDs.

Seasoned codebases carry their audit history in the comments — V4LE-93, AUDIT-ACCEPTED-*, issue links, "fixed:" notes. Each marker answers one question: where did previous reviewers concentrate their forces? Dense markers mean an area has been picked over, argued about, and patched — the probability that the next finder finds something there is low. Sparse markers, combined with heavy external interaction (calls into vaults, routers, oracles, NFT callbacks), mean the opposite: that is your hunting ground.

Why it works

Bug finding is not uniformly distributed. It clusters where state changes meet external calls. Prior auditors knew this too, so their attention — and their fix IDs — cluster on exactly those seams. The patch trail is a record of where attention already went. Reading it first turns an unbounded search into an allocation decision.

How to run it

1. Grep for fix markers before reading any logic. Count them per file and per function region.
2. Sort files by marker density, ascending. The bottom of the list, filtered for external interactions, is where you start.
3. Read the patches themselves, not just their locations. A fix tells you what the threat model of that area is. A fix for reentrancy tells you the authors think about reentrancy there; an unfixed neighbor function with the same shape tells you nobody asked.
4. Look for fix-shaped code without a fix ID. The most interesting files are the ones with meticulous defenses and no numbering — internal hardening after an internal review, never externally audited. Two readings are possible: truly un-reviewed, or reviewed-and-clean. The shape of the defenses tells you which: a fresh postcondition that binds settlement to the plan is a patch wearing no badge, which means somebody already hunted here.

A worked sketch

On a recent lending-protocol audit I opened seven areas. The vault core had a dozen fix IDs — I skimmed it for the fix semantics and moved on. A 1,200-line lease-auction controller had exactly six markers and a Harberger-tax mechanism with rent escrows, buyouts, and evictions. That is where the hypotheses came from: flash-lease, buyout-front-run, donation theft, insolvency-boundary manipulation. Every one of them was refuted by the code — but refuting five hypotheses in the right neighborhood beat reading a thousand lines of already-patched vault logic.

The counter-rule

Marker density is evidence about the past, not a guarantee about the present. Fixes themselves introduce bugs; a patch cluster can hide a regression. So the trail tells you where to start, and the diff between two patch waves tells you where regressions live. It never tells you where to stop.

Pair it with a hard budget: if the sparse zone yields nothing after a fixed number of hypotheses, close the zone and re-allocate. The trail is a map, not a promise — but auditing without it is searching a city with your eyes closed and hoping to bump into the crime scene.