How an engagement works

What you send us

• CodeRepository access and the commit you want reviewed
• IntentA spec, design notes, or a short write-up of what the system should do
• TestsYour existing test suite and how to run it
• DeploymentTarget chains, roles, admin keys, oracles and external integrations
• A contactSomeone on your team who can answer questions during the review

Scoping

We read the repository before we quote. You get a written scope: the files in scope, the commit, our assumptions, and dates.

Price is quoted after scoping. It depends on code size, complexity and timeline. You get a fixed quote before any work starts.

We cover Solidity on EVM chains. If part of your system falls outside that, we say so at scoping.

Timeline

• ScopingWe read the code and send a written scope and quote
• Threat modelAssets, actors and trust assumptions, written down before review starts
• ReviewManual line-by-line reading on a local fork. Invariant fuzzing in Foundry. Economic modeling where incentives matter. A confirmed Critical is reported the same day
• Findings callWe go through each finding with your team
• ReportDraft report, then final report after fix review

Dates are fixed in the scope. Length depends on the code.

What you receive

A written report. It states the repository, commit and files reviewed, then a system overview, the threat model and the findings.

Each finding has a severity, location, impact, likelihood, a written reproduction and a fix. High and Critical findings include a Foundry proof of concept against the reviewed commit. The invariant harness is yours to keep in CI.

• CriticalHigh impact, high likelihood. Direct loss of user funds or protocol control
• HighHigh impact with lower likelihood, or medium impact with high likelihood
• MediumBounded loss, or disruption that requires specific preconditions
• LowLow impact or unlikely conditions; defence-in-depth
• InformationalCode quality, documentation and gas observations

Severity reasoning is written out for every finding, so your team can challenge it. See the synthetic sample report.

Fix review

You fix, then send the commit. We check each fix and look for regressions the change introduced. Each finding is marked Fixed, Partially fixed or Acknowledged, with the commit hash.

Who does the work

You work directly with your reviewer from scoping to fix review. The reviewer reads the code, writes the proofs of concept and writes the report. Tools help with coverage. Every reported finding is confirmed by hand.

Limits

A review is time-boxed and covers one commit. It does not cover code outside scope, later changes, deployment, key management or off-chain systems unless they are listed in scope.

A review reduces risk. It does not guarantee the code is free of bugs.

Code, documents and findings stay confidential. We can sign a mutual NDA. Nothing is published without your consent. See our disclosure policy.

Request a review

Tell us where the code lives, the commit or branch, and your target dates. We reply with questions or a draft scope.

Request a review on Discord (opens in a new tab). We move confidential details to a private channel. Do not post code or vulnerability details in public channels.

Request a review (opens Discord in a new tab) Read the sample report