Method

How I run a security review.

A review is a test of a claim: that this system keeps its promises. My job is to check which promises hold under pressure.

Evidence outranks claims. That single rule shapes every decision I make about how to review a protocol: what to read first, what to test, what to write down, and what to keep private.

Most security work is a tight loop: understand the system, trace the risky paths, test what can actually break, and write down what a developer can act on. The order is deliberate. Reading for bugs before understanding intent produces noise; knowing the threat model first produces findings that survive being questioned.

The loop

Four passes, each with a deliverable.

01

Understand the system

Map roles, assets, trust boundaries, and intended invariants before reading for bugs. The deliverable is a threat model, not a list of files.

02

Trace the attack surface

Follow the flows that move value or change state. Test the assumptions that break in production the moment they are assumed.

03

Validate with evidence

Credible findings get a proof of concept, fork-based on authorized testnets or local forks, never against production.

04

Report to be acted on

Severity, impact, reproduction, remediation, and verification in one structured format the fixing team can use.

Privacy as a feature

Nothing goes public until disclosure terms permit it.

Private findings stay private. Active exploit paths, private reports, and sensitive protocol details are not published before a responsible-disclosure process is complete. A severity shown reflects what was validated, not the worst case that can be imagined.

Authorized testing only, always. Production is never assumed, and the evidence is shared with the team that has to act on it.

Start a review

Bring the context that makes testing count.

01

Scope

Share the repository, program list, and the exact systems or flows that need attention.

02

Risk context

Point to trusted roles, asset movement, integrations, and assumptions that cannot fail.

03

Environment

Provide authorized local or fork-based testing details. Production testing is never assumed.

Appearance