How an assessment runs, from scope to report.
Overview
Seven stages, one record.
Stage 1 of 7
Scoping and threat modeling
We agree exactly what will be reviewed, at which commit, and against which threats. A precise scope is the difference between a review and an opinion.
What happens
- Fix the commit hash, files and deployment targets in scope
- Identify assets, trust boundaries and privileged actors
- Draft a threat model and agree priority areas
- Confirm documentation, test coverage and known issues
What we need from you
- Repository access and commit reference
- Specifications or design notes
- Deployment and upgrade plans
What you receive
- Signed scope statement
- Initial threat model
- Engagement schedule and contacts
Stage by stage
What happens at each stage.
Stage 1: Scoping and threat modeling
We agree exactly what will be reviewed, at which commit, and against which threats. A precise scope is the difference between a review and an opinion.
Activities
- Fix the commit hash, files and deployment targets in scope
- Identify assets, trust boundaries and privileged actors
- Draft a threat model and agree priority areas
- Confirm documentation, test coverage and known issues
What we need from you
- Repository access and commit reference
- Specifications or design notes
- Deployment and upgrade plans
Outputs
- Signed scope statement
- Initial threat model
- Engagement schedule and contacts
Stage 2: Architecture and code review
Reviewers read the system end to end: first its architecture and invariants, then every in-scope line, with at least two reviewers covering each critical component.
Activities
- Reconstruct intended behaviour from specs and code
- Map external calls, state transitions and privileged paths
- Line-by-line manual review of in-scope code
- Record questions and suspected issues for validation
What we need from you
- A technical point of contact for questions
- Answers to design clarifications
Outputs
- Annotated architecture notes
- Working list of candidate issues
Stage 3: Automated and manual analysis
Tooling widens coverage; people decide what matters. Static analysis, fuzzing and property tests run alongside manual reasoning, and every tool result is triaged by hand.
Activities
- Static analysis and custom detectors
- Property-based and invariant fuzzing
- Economic and adversarial scenario analysis
- Integration review against external protocols
What we need from you
- Existing test suites and deployment scripts
Outputs
- Fuzzing harnesses and properties
- Triaged tool output
Stage 4: Vulnerability validation
A suspected issue becomes a finding only once it is demonstrated or rigorously argued. Material findings ship with a proof-of-concept test.
Activities
- Write proof-of-concept tests for material issues
- Assess impact and likelihood independently
- Classify severity against a published rubric
- Peer review of every finding before it is reported
What we need from you
- Confirmation of intended behaviour where ambiguous
Outputs
- Validated findings with severity rationale
- Proof-of-concept tests
Stage 5: Findings and remediation guidance
Findings are delivered as they are confirmed, each with a precise description, its impact, and a recommended fix that fits the codebase as written.
Activities
- Share findings through a private channel as they are validated
- Walk the team through critical and high findings
- Recommend fixes and discuss alternatives
What we need from you
- Remediation plan and owners
- Fixes on a tagged commit
Outputs
- Preliminary report
- Recommended patches or diffs where useful
Stage 6: Follow-up verification
We review the fixes themselves, not just the diff that claims to fix them, and check that remediation did not introduce new issues.
Activities
- Review the remediation commit against each finding
- Re-run proofs of concept and regression properties
- Assess any new code introduced by the fixes
What we need from you
- Remediation commit reference
- Notes on acknowledged findings
Outputs
- Per-finding resolution status
- Residual risk notes
Stage 7: Final reporting
The final report states what was reviewed, how, what was found, what was fixed, and what the assessment could not cover. Publication is the client’s decision.
Activities
- Compile executive summary and technical findings
- Document methodology, scope and limitations
- Prepare a publishable version on request
What we need from you
- Publication preference and review of the final draft
Outputs
- Final audit report (PDF)
- Optional public listing in the audit directory
Principles
The rules every review is held to.
Independence
Findings and severities are decided by reviewers, not negotiated. Clients can respond to every finding in the report, and their response is published beside it, but the rating stays as assessed.
Reproducibility
Every finding names a commit, a file and a line range. Material issues ship with a proof-of-concept test, so anyone with the code can confirm the issue and the fix.
Explicit limitations
Reports state what was not reviewed, which assumptions were made about external systems, and where time or scope limited depth. An unstated limitation is a false assurance.
Peer review
No finding leaves the team on one person’s judgement. A second reviewer checks the reasoning, the severity and the recommendation before it is shared.
Severity rubric
Impact and likelihood, rated separately.
A finding’s severity is read from the matrix once both dimensions are assessed. Each finding records the reasoning for both, so a reader can disagree with the inputs rather than the label.
- Critical
- Direct loss of funds or permanent loss of control is achievable with little or no precondition.
- High
- Material loss or protocol disruption is achievable under realistic conditions.
- Medium
- Limited loss, degraded functionality, or impact that depends on specific conditions.
- Low
- Minor impact, defence-in-depth gaps, or issues with unlikely preconditions.
- Informational
- Code quality, documentation or best-practice observations without direct security impact.
| Low likelihood | Medium likelihood | High likelihood | |
|---|---|---|---|
| High impact | Medium | High | Critical |
| Medium impact | Low | Medium | High |
| Low impact | Low | Low | Medium |
Report structure
What a final report contains.
- 01
Executive summary
What the system does, what was assessed, the most significant findings and their resolution, in language a non-specialist decision-maker can act on.
Brief, non-technical
- 02
Scope and commit references
Repository, commit hashes for the reviewed and remediated code, the files in scope and those explicitly excluded, and the review window.
Exact and verifiable
- 03
System overview
Architecture, trust boundaries, privileged roles and external dependencies as understood by the reviewers, so readers can check our model of the system.
- 04
Methodology
The techniques applied: manual review passes, tooling, fuzzing properties, economic scenarios and the severity rubric used.
- 05
Findings summary
A table of every finding with its identifier, title, severity, category and resolution status.
- 06
Detailed findings
For each finding: location, description, impact, likelihood reasoning, recommendation, the client’s response and the verified resolution.
Most of the report
- 07
Remediation review
How each fix was verified, against which commit, and whether any new code introduced by the fixes was reviewed.
- 08
Limitations and disclaimer
What the assessment could not cover, the assumptions it relied on, and the point-in-time nature of the conclusions.
Data sources
Where each figure comes from.
Connected data
Token scans, Protocol Analytics, address reads, contract monitoring and the Contract Analyzer read public blockchains and third-party providers (Alchemy or an RPC node, Etherscan, GoPlus, DefiLlama, CoinGecko) when a request is made or a job runs. The source line lists each provider, how its call ended and the time. When a provider is not connected or fails, the result says so and nothing is filled in.
Quantix Protocol Research
Security Explorer profiles, research assessments, recorded investigations, forensic case files, token research and case studies come from Quantix Protocol Research: protocol designs modelled by Quantix researchers on common DeFi architectures, with their history, contracts, events and findings. They are research subjects, not listed projects or client engagements. Their identifiers are internal and never linked to block explorers, and archived results show the date they were computed (24 October 2026).
Technical content
Vulnerability classes, standards, EIPs, tools and mitigations described across the website are real and cited to their official sources in each publication and assessment.
Start with a precise scope.
Share the repository, the commit you plan to deploy and your timeline. The first output of any engagement is a written scope you can hold us to.