What a review actually looks like
This is a representative engagement flow, not a fictional client story. Exact scope, timeline, and depth depend on the code and the funds it is expected to protect.
- 01
Scope the system
We map the contracts, dependencies, privileged actors, assets at risk, deployment state, and code freeze. The result is a written scope so there is no ambiguity about what is and is not being reviewed.
- 02
Build the threat model
Before hunting patterns, we identify the invariants: who may move value, what must remain solvent, when prices are trusted, and which state transitions must be atomic.
- 03
Read and test the code
Manual review and focused tooling work together. Promising hypotheses are exercised on a local fork or realistic test harness; superficial warnings do not become report findings.
- 04
Deliver an actionable report
Confirmed issues are ranked by their actual preconditions and impact. Every one includes evidence, a runnable reproduction, and a suggested remediation. Informational notes are kept separate from defects.
- 05
Verify the fix
Once changes land, we revisit the affected path and the reproduction. The goal is to verify the remediation, not merely confirm that a diff exists.
What you receive
- ›A scope and threat-model summary that makes the review boundaries explicit.
- ›A written report with confirmed findings, their preconditions, evidence, and remediation guidance.
- ›Runnable proof-of-concept tests for confirmed issues where the environment permits one.
- ›A remediation follow-up for the agreed scope of fixes.