Sentryx
Request an audit
  1. Home
  2. Process

Methodology

Six stages. Every one produces an artefact.

An audit that cannot be inspected is a receipt, not a review. This page is the whole methodology — what we do at each stage, what you get, how severity is decided, and what we need from you before day one.

01

Scoping & threat model

2–4 days

We read the documentation and the code before we quote. Together we fix the boundary: which contracts are in scope, which are trusted, and which are explicitly out. Then we enumerate the actors and their privileges, the external dependencies, and the assets at risk — and we write it down. That document is what the review is measured against, and it is the artefact most teams tell us they did not know they needed.

Output

  • Scope document at a fixed commit
  • Trust-boundary map and actor list
  • Assumptions register
  • Fixed quote and review plan
02

Manual adversarial review

40–60% of the engagement

Two researchers read every in-scope line independently. We trace value flows end to end, walk each state machine through its transitions, and follow every external call to ask what a malicious implementation on the other side could do. We are looking for the assumption that holds in normal operation and breaks under an attacker's ordering. This is where the Critical findings come from — no tool found the bugs behind the largest exploits in this industry.

Output

  • Independent findings from each researcher
  • Reconciled findings register with severities
  • Questions log for the dev team
03

Tooling & invariants

Runs alongside review

Static analysis (Slither, Aderyn, Semgrep) covers the known patterns cheaply so human attention goes where tools cannot reach. Then we write the properties your protocol must never violate — solvency, share-price monotonicity, conservation of value, access-control invariants — and let Foundry, Echidna or Medusa search for counterexamples. Where core maths justifies it, we reach for Halmos or Certora.

Output

  • Triaged tool output (false positives removed)
  • Foundry invariant suite with handlers
  • Fuzzing corpus and campaign config
04

Proof of concept

Per Critical / High finding

Every Critical and High is reproduced as a runnable test against a fork, with the attacker's profit or the protocol's loss measured in the assertion. This is the discipline that keeps severity honest: a finding we cannot demonstrate gets downgraded and labelled as theoretical. It also means your engineers can verify the fix themselves rather than taking our word for it.

Output

  • Foundry PoC per Critical / High
  • Measured impact in the assertion
  • Exploit path written out step by step
05

Report & walkthrough

3–5 days

One report, two audiences. Your engineers get the location, the mechanism, the PoC and a specific remediation. Your investors and users get an executive summary that says what was reviewed, what was found and what it means — without marketing language. Then we walk your team through every finding on a call, because the questions that come up there frequently surface a second issue.

Output

  • Report as PDF and Markdown
  • Findings register as JSON
  • Walkthrough call with the researchers
06

Remediation verification

2–5 days after fixes

You fix; we re-review every changed line, re-run each PoC and the invariant suite, and confirm the fix did not introduce something new — which happens more often than teams expect. Each finding is marked Fixed, Acknowledged or Open, with your reasoning recorded where you have accepted a risk. The final report is publishable, and the invariant suite stays in your CI.

Output

  • Final report with per-finding status
  • Re-run PoC results
  • CI-ready invariant suite

Severity

Impact times likelihood. Written down.

Severity disputes waste everyone's time when the rule is implicit. Ours is a matrix, applied consistently, with our reasoning in the report. A finding we cannot demonstrate is downgraded and labelled theoretical — even when it is interesting.

Severity as a function of impact and likelihood
Impact ↓ / Likelihood →LowMediumHigh
Catastrophic — total loss / insolvencyMediumHighCritical
Severe — significant lossLowMediumHigh
Moderate — bounded loss / broken accountingLowLowMedium
Minor — no direct value at riskInfoLowLow

Likelihood accounts for preconditions: capital required, privileged access needed, market conditions, and whether the attack is a single transaction or a sequence someone can interrupt. Full definitions per level are in the Severity Explorer.

Toolchain

What we run, and what we don't trust it to find.

Tools are cheap coverage of known patterns. They do not find the flaw in your liquidation curve. We use them to free human attention, then triage every result — you never receive raw scanner output as a finding.

Static

Slither · Aderyn · Semgrep

Pattern coverage across the codebase, with custom rules for your architecture. Every hit is triaged by hand; false positives never reach your report.

Dynamic

Foundry · Echidna · Medusa

Invariant tests and coverage-guided fuzzing with handlers that reach deep protocol state, plus fork tests against real mainnet conditions.

Symbolic

Halmos · Certora · hevm

Symbolic execution and formal specs where core arithmetic or access rules justify the cost. Certora engagements are delivered with partner specialists.

Runtime

Tenderly · fork simulation

Transaction tracing and state inspection for reproducing exploits and validating fixes against live chain state.

Review

Two humans, independently

The part no tool replaces. Value-flow tracing, state-machine walks and adversarial reasoning about every external call.

Handover

Your CI, after we leave

The invariant suite and pipeline stay in your repository. Security that expires when the engagement ends is theatre.

Working with us

Practical questions.

The repository at a fixed commit, a list of the contracts in scope, whatever documentation or spec exists, the external integrations (oracles, AMMs, bridges, tokens you do not control), the list of privileged roles and who holds them, and your deployment target. If documentation is thin we will write our understanding back to you — the disagreements that surfaces are often the first finding.

Because reviewers anchor. Once you have read a contract with one mental model of what it does, you stop seeing the paths that model excludes. Two reviewers reading independently and comparing notes afterwards catches materially more than two reading together, which is why our standard audit budgets for both reads.

We stop and tell you the same day, before the report exists. If the code is live we help you evaluate containment — pause, parameter change, migration — before anything is written down or shared. Unfixed Criticals on live systems are never published.

Impact times likelihood, applied consistently, with the reasoning written out. If we cannot demonstrate a finding with a proof of concept, we downgrade it and say so. Where you disagree with a rating we record your position in the report rather than quietly changing ours.

After you fix, we re-review every changed line (not just the diff you point us at), re-run the proof of concept for each finding and the invariant suite, and mark each finding Fixed, Acknowledged or Open. That final report is the one you publish, and it is included in every audit — not an upsell.

Yes, as standard. Nothing about the engagement is published without your written approval, and you decide whether the final report becomes public.

Ready when you are

Stage one is free and takes two days.

Send the repo. You get a written scope, a threat-boundary sketch, a fixed quote and a review plan.

Start scoping See a sample report