Skip to content
Quantix Security Labs

An independent laboratory for blockchain security.

Quantix Security Labs evaluates and strengthens the security of decentralised systems: smart contracts, Web3 applications and the infrastructure beneath them. It is a research organisation first; its services are built on that research.
See the research structureContact
Isometric illustration of a laboratory floor: bays for code review, formal methods, monitoring and fund-flow forensics, joined by brass conduits around the Quantix lens.

Who we are

Security researchers, engineers and analysts working as one review practice.

Quantix is organised around disciplines rather than sales lines: smart contract assessment, formal methods, protocol and infrastructure security, threat intelligence and security operations. Each is led by a role accountable for its methods and for the quality of what it reports.

The same people who review code also write the research, build the analysis tooling and design the monitoring rules. That is deliberate: findings from one discipline become checks in another, and every published conclusion can be traced to the evidence behind it.

Illustration of the Quantix lens examining a grid of contract modules on a graphite bench, with one module marked as a finding.
Security disciplines
9
Supported ecosystems
11
Assessment stages
7
Research teams
6

Mission

Make decentralised systems harder to break, and honest about their risks.

Blockchain systems hold value in code that anyone can read and anyone can call. A single overlooked assumption can be exploited within minutes of deployment, and the result is usually irreversible.

  • Find it first

    Identify the assumptions an attacker would exploit before the code holds value, and validate each finding with a reproducible test.

  • Explain it precisely

    Describe every issue with root cause, impact, preconditions and a fix specific enough for engineers to implement and verify.

  • State the residual risk

    Say plainly what was reviewed, what was not, and what remains, so users and integrators can make informed decisions.

Research philosophy

Four convictions shape how Quantix reviews.

  • Assume the adversary is competent.

    Attackers read the same code, documentation and mempool, and they are patient. Every assumption is reviewed as if someone with time, capital and no scruples will test it.

  • Systems fail at their seams.

    The most damaging issues sit between components: a contract and its oracle, a front end and its signer, a governance vote and the upgrade it executes. Reviews are scoped around those seams, not around folders.

  • Evidence over assurance.

    A clean report is not proof of safety. Quantix describes what was checked, how, and what was not, so readers can weigh the evidence rather than trust a label.

  • Research feeds the method.

    New vulnerability classes appear as protocols change. Time spent reproducing published exploits and studying failure modes becomes checks, properties and detectors in the methodology.

Technical capabilities

Eleven ecosystems across four execution models.

Review depth depends on knowing the execution model: how accounts, storage, calls and upgrades work on the chain in question. Capabilities are organised by virtual machine family.

EVM

  • Ethereum
  • BNB Chain
  • Arbitrum
  • Optimism
  • Base
  • Polygon
  • Avalanche

Languages

Solidity, Vyper, Yul, Rust (Stylus), Go (custom VMs)

SVM

  • Solana

Languages

Rust (Anchor), Rust (native)

MoveVM

  • Aptos
  • Sui

Languages

Move (Aptos), Move (Sui)

Cosmos SDK

  • Cosmos

Languages

Go (Cosmos SDK), Rust (CosmWasm)

  • Manual code review

    Line-by-line reading of every in-scope component by at least two reviewers, starting from the system’s invariants.

  • Property-based fuzzing

    Invariant suites written with the engineering team and run with stateful fuzzers such as Echidna and Foundry.

  • Static and symbolic analysis

    Slither, Semgrep rules and symbolic execution to cover paths that are expensive to reason about by hand.

  • Formal verification

    Specifications proved with SMT-based provers where the cost of a defect justifies a proof, with assumptions stated.

  • Infrastructure testing

    Authorised testing of front ends, APIs, signing services, nodes and cloud environments around on-chain code.

  • On-chain forensics

    Transaction reconstruction, trace decoding and fund-flow analysis for incidents, monitoring rules and risk scoring.

Ecosystem coverage by service

Security disciplines

Nine disciplines, one standard of evidence.

Each discipline is a different way of examining the same system. Engagements combine them where the risk calls for it.

Engineering methodology

Seven stages from scope to final report.

Every assessment follows the same sequence, with defined inputs and outputs at each stage, so that two engagements of the same size can be compared and repeated.
Read the methodology
Isometric illustration of seven ascending stages, from a scoped boundary through analysis, a validated finding and graded findings to a sealed final report.
  1. 01

    Scoping and threat modeling

    Output: Signed scope statement

  2. 02

    Architecture and code review

    Output: Annotated architecture notes

  3. 03

    Automated and manual analysis

    Output: Fuzzing harnesses and properties

  4. 04

    Vulnerability validation

    Output: Validated findings with severity rationale

  5. 05

    Findings and remediation guidance

    Output: Preliminary report

  6. 06

    Follow-up verification

    Output: Per-finding resolution status

  7. 07

    Final reporting

    Output: Final audit report (PDF)

Leadership and research structure

Roles accountable for methods, not titles for show.

The research structure is described by role: what each role owns, the expertise it requires and the services and products it is accountable for. Team leads report to the Head of Security Research.
Head of Security ResearchSecurity Research
Explore roles and responsibilities

Career areas

The disciplines Quantix hires into.

These are the areas of work and the skills each one relies on. This page describes the disciplines; it does not advertise positions.

  • Smart Contract Assessment

    Smart contract assessment

    • Reading unfamiliar codebases quickly
    • EVM, SVM or Move internals
    • Writing proof-of-concept exploits as tests
    • Clear technical writing

  • Formal Methods

    Formal methods

    • Specification languages and SMT solvers
    • Invariant design
    • Explaining assumptions to engineers

  • Protocol & Infrastructure Security

    Application and infrastructure security

    • Web and API penetration testing
    • Cloud and CI/CD security
    • Key management and signing systems

  • Threat Intelligence & Forensics

    Threat intelligence and forensics

    • Transaction tracing
    • Graph analysis
    • Attack technique research
    • Structured analytic writing

  • Security Operations

    Security operations

    • Detection engineering
    • Incident handling under pressure
    • Runbook design

  • Security Research

    Research engineering

    • Building analysis tooling
    • Fuzzing infrastructure
    • Data pipelines for on-chain analytics

Researchers who want to work with Quantix can start in the Security Research Network: research programmes and training challenges are open to anyone, and validated findings are recognised.

Responsible disclosure

Report privately. Coordinate before publishing.

Vulnerabilities in Quantix systems, or found during Quantix research in third-party code, are handled under a coordinated disclosure policy: private report, acknowledgement and triage, a coordinated fix, then publication on an agreed date with credit for the reporter if they want it.

Findings in a research programme go through the researcher submission form, which uses the same workflow.

Read the disclosure policySubmit a research finding

Contact information

Where to write.

Messages are handled through the forms on this site: the contact form for general questions, the audit request form for engagements, and the research submission form for programme findings.

Talk to the people who do the work.

Requests are read by the reviewers who scope engagements. Describe what you are building and when it ships.

Discuss Your Security RequirementsContact