Skip to content
Quantix Security Labs

Quantix Security Research Network.

Independent researchers work alongside Quantix on protocols from Quantix Protocol Research: research programmes with defined scope and rules, training challenges built from real vulnerability classes, and a coordinated disclosure process that recognises every validated finding.
Browse programmesSubmit a finding
Illustration of a researcher network: stations spread across a dark field send findings along brass arcs to one coordinated intake.

How it works

Three ways to take part.

Programmes and challenges award recognition — acknowledgement, a ledger entry and standing in the network. No programme offers or pays money.

  • Research programmes

    8

    6 open, covering 37 in-scope components across smart contracts, APIs, infrastructure and SDKs.

    • Quillon VaultsOpen
    • Fenwick LendingOpen
    • Corvid AMMOpen
    • Helion ProtocolOpen
    All programmes

  • Security challenges

    6

    Intentionally vulnerable training code in Solidity and Anchor, each with hints and a worked fix.

    • Introductory1
    • Intermediate3
    • Advanced2
    All challenges

  • Coordinated disclosure

    7 steps

    From preparation to publication. The submission form confirms receipt only after the server has accepted the report.

    Submission form

Vulnerability categories

What researchers look for.

Submissions are classified under these categories. Each programme lists the focus areas most relevant to its architecture.

  • Smart contract logic

    • Business logic errors
    • Reentrancy and read-only reentrancy
    • Precision and rounding
    • First-depositor and share inflation

  • Access and privilege

    • Missing access control
    • Unprotected initializers
    • Unsafe proxy upgrades
    • Governance and timelock bypass

  • Economic and oracle

    • Spot-price oracle manipulation
    • Flash-loan amplified attacks
    • Liquidation and incentive flaws

  • Cross-chain

    • Message validation and replay
    • Verifier configuration
    • Nonce and ordering issues

  • Signatures and cryptography

    • Signature replay across chains or contracts
    • EIP-712 domain errors
    • Weak randomness

  • Programs and accounts

    • Missing signer and owner checks
    • Account substitution
    • PDA seed and bump issues
    • Capability leakage in Move

  • Web, API and infrastructure

    • Authentication and session flaws
    • Transaction-construction integrity
    • Tenant isolation
    • Secrets exposure

  • Something else

    A finding outside these classes is still in scope. Submit it; the reviewer assigns the category and explains the choice.

    Submission form

Background reading for each class is in the Research Hub.

Severity guidelines

One rubric for every programme.

Researchers propose a severity when they submit; the reviewer confirms or adjusts it against these criteria and explains any change.
SeverityCriteriaExamples
Critical
  • Direct theft or permanent freezing of user or protocol funds
  • Unauthorised minting or control of privileged roles
  • Exploitable without special privileges or unlikely conditions
  • Draining a vault
  • Forging a cross-chain message
  • Signing outside policy in a custody system
High
  • Material loss or disruption under realistic conditions
  • Temporary freezing of funds
  • Bypass of an important control with some preconditions
  • Liquidating healthy positions
  • Redeeming at a manipulated price
  • Session takeover in an admin console
Medium
  • Limited or conditional loss
  • Degraded functionality or griefing at a cost to the attacker
  • Information disclosure that aids further attacks
  • Rounding that leaks value over many transactions
  • Blocking withdrawals for a bounded period
Low
  • Minor impact or very unlikely preconditions
  • Defence-in-depth gaps
  • Missing events on privileged changes
  • Missing input validation that only causes reverts
Informational
  • No direct security impact
  • Code quality, documentation or best-practice observations
  • Floating pragma
  • Unused code paths

Submission workflow

From private report to coordinated disclosure.

Every submission follows the same steps. The status tracker on the submission form shows the first three; later steps continue by email.
  1. 01

    Prepare

    Read the programme scope and rules. Reproduce the issue on a fork or test deployment and write it up.

  2. 02

    Submit

    Send one finding per submission through the form, with steps to reproduce and impact.

  3. 03

    Received

    The submission is delivered or stored and you receive a reference. Only this step is confirmed on screen.

  4. 04

    Triage

    A reviewer checks scope, duplicates and plausibility, then replies by email.

  5. 05

    Validation

    The finding is reproduced and rated against the severity guidelines. You can respond to the rating.

  6. 06

    Remediation

    The protocol team fixes the issue; Quantix reviews the fix and shares the outcome with you.

  7. 07

    Disclosure and recognition

    Details are published on an agreed date. You are credited by name or handle if you want to be.

Coordinated disclosure

Nothing is published before it is fixed and agreed.

Disclosure policy

  • Private first

    Findings are reported only through the submission form and stay confidential while they are triaged and fixed.

  • Agreed dates

    Publication happens on a date agreed between the researcher, the protocol team and Quantix, normally after a fix is deployed.

  • Fix reviewed

    Quantix reviews the remediation and tells the researcher whether it addresses the root cause before anything is published.

  • Credit by consent

    Researchers are credited by name or handle if they want to be, and never without consent.

Recognition

Validated work is credited, recorded and built on.

Recognition is the only reward in the network. There are no prize pools, bounty amounts or payouts.

  • Acknowledgement in the report

    Validated findings are credited in the protocol’s research assessment or advisory, by name or handle, with your consent.

  • Recognition ledger

    Each validated finding becomes a ledger entry recording programme, vulnerability class, severity and validation date. Entries are published only with the researcher’s consent.

  • Researcher standing

    Standing reflects validated findings over time: Contributor after the first, Recognised after three, Distinguished after a validated critical or high finding with a published write-up.

  • Research collaboration

    Researchers with standing are invited to closed challenge rounds and to co-author research on the vulnerability classes they reported.

Recognition ledger entry

The ledger records validated findings in this format. Entries are added only after validation and published only with the researcher’s consent.

FieldFormatMeaning
Entry IDQR-L-2026-0001Sequential identifier assigned at validation
ResearcherName or handle chosen by the researcherPublished only with consent; otherwise "Anonymous"
ProgrammeQuillon VaultsProgramme the finding was submitted to
ClassFirst-depositor attackVulnerability class from the submission form
SeverityHighSeverity after validation, using the guidelines
ValidatedDateDate the reviewer reproduced the finding
DisclosureDate or "Coordinated"Public disclosure date once agreed

Start with a challenge, or go straight to scope.

Challenges teach the vulnerability classes programmes are most exposed to. When you find something real, report it privately.

Browse programmesSecurity challenges