No false positives
Five gates before anything is reported: hand-derived economics, compiler-true storage claims, live reachability, honest prior art, honest severity.
Methodology
The full smart-contract audit process
Every step of an audit, in order: from the first scope question to the final report. What is done, how, why it matters, and what it produces.
- 01
Scoping & rules of engagement
- What
- Define the target: the exact commit or tag, the deployed addresses, the chains, the in-scope assets, and the program's impact list and severity definitions.
- How
- Read the program page and prior audits; pin the code at the audited commit (a worktree per tag).
- Why
- Severity is judged against the program's own impact list: a "critical" elsewhere may be a Medium here.
- Produces
- A one-page scope card: target, addresses, commit hash, rules, severity mapping.
- 02
Reconnaissance: deployed vs. repo delta
- What
- Compare what was audited (or what the repo claims) with what is actually deployed.
- How
- Pin the fork, fetch the deployed bytecode, compile the audit-era source with the same solc settings, strip the CBOR metadata, and diff. Get a byte-identical control match first, then diff the rest.
- Why
- The highest-yield class on live programs is "the audits reviewed something else": guards removed, constants changed, upgrades deployed.
- Produces
- A delta report per contract: identical, metadata-only, or real divergence.
- 03
Plain-English vocabulary & architecture map
- What
- Describe the protocol in plain English before reading code: every actor, every asset, every action, every fee.
- How
- Walk the docs and interfaces; draw the module graph (who calls whom, who holds what).
- Why
- If you cannot explain the system simply, you cannot tell where the assumptions hide, and assumptions are where the bugs live.
- Produces
- A vocabulary sheet and a module diagram, used again in the final report.
- 04
The money map (accounting first)
- What
- List every tracked total, every function that writes it, and the asymmetry table: value moved without a matching write, tracked in one branch only, never tracked.
- How
- A table of asset, state variable, writers and readers, plus 5 to 15 invariants written as statements, for example
sum(userBalances) == totalSupply. - Why
- Most real exploits are accounting desyncs, not missing modifiers.
- Produces
- The invariant list: the backbone of the proof-of-concept phase.
- 05
Twelve-lens manual review
- What
- Read the code through twelve lenses: accounting desync, share and exchange rate, temporal cohort, liquidation and solvency, cross-chain state, rounding and precision, ordering and MEV, DoS and griefing, access and trust, integration assumptions, edge states, flow completeness.
- How
- One pass per lens over the same code, never one blurry read.
- Why
- Each lens catches a different bug family; a single read only catches the loudest one.
- Produces
- Candidate leads, each tagged with its lens.
- 06
Cohort attacks & the Last-User-Out test
- What
- Attack the protocol's lifecycles in worst-case orderings, not its functions one by one: everyone deposits, some attack mid-flow, everyone withdraws in the worst order.
- How
- For each invariant, write the adversarial sequence that tries to break it. Always include the Last-User-Out test: after all others exit, is the last user paid in full?
- Why
- Sequenced flows show the desyncs that single-call tests cannot see.
- Produces
- A list of concrete attack scenarios to prove on a fork.
- 07
Fork-prove every lead
- What
- Prove every candidate on a mainnet fork of the real deployed contracts, never on mocks.
- How
- The proof must assert harm (victim balance before and after), not mechanism. Then the falsification gate: change the defective line to its correct form. If the exploit still works, the proof is theatre and the lead is demoted.
- Why
- Green tests are hypotheses; pinned tests are evidence. This is what separates a finding from a story.
- Produces
- For each real finding: a pinned fork proof with before and after balances.
- 08
The five gates (no false positives)
- What
- Every surviving lead must pass five gates: (1) exploit economics derived by hand, twice, with a named victim and gainer; (2) storage and offset claims checked against the compiler's conventions; (3) live reachability on the deployed in-scope asset; (4) honest prior art, including unpublished prior submissions; (5) honest severity per the program's own impact list.
- How
- A pass/fail table per lead; one failed gate stops the report.
- Why
- One false positive destroys a reputation faster than ten true findings build it.
- Produces
- A gate table per lead.
- 09
Severity & impact calibration
- What
- Assign severity from the economics, not the mechanism: how much a real victim loses, how easily, and how recoverable it is.
- How
- Map to the program's tiers and state the worst realistic outcome, not the theoretical ceiling.
- Why
- Overclaiming severity is the fastest way to an invalid verdict.
- Produces
- A severity recommendation per finding, with the loss math shown.
- 10
The report
- What
- Write each finding as a self-contained case: summary, vulnerability details (root cause, exact lines, why the guard fails), impact (the named victim, the loss math, the worst realistic outcome), and references (prior art, similar incidents from this archive).
- How
- Follow the platform's template exactly, include the pinned proof, and state in one line which of the five gates passed.
- Why
- Triage is busy: a report that reads like evidence gets paid.
- Produces
- The submission-ready report.
Methodology
Four principles behind every step
Proofs assert harm
A proof shows the victim's balance before and after, then survives the falsification test: fix the line, and the exploit must fail.
Accounting first
Map the money before reading for bugs: every total, every writer, every asymmetry. Then run the lifecycles, not the functions.
Deployed beats audited
What was audited is not always what shipped. Diff the audit-era code against the deployed bytecode first.