Skip to content
Quantix Security Labs

Corvid AMM research programme.

Constant-product AMM on Solana written in Anchor. Account validation, PDA derivation and token-vault authority are the main research areas.
OpenOpened 4 August 2026

Programme overview

Protocol category
DEX
Ecosystems in scope
Solana
In-scope components
4 (4 contracts)
Languages
Rust (Anchor)

Focus areas

Where research is most wanted.

  • 01

    Account substitution and owner checks

  • 02

    PDA seeds and bump handling

  • 03

    Swap invariant and fee rounding

  • 04

    Token-2022 extension behaviour

Scope

In scope.

Identifiers belong to the programme’s research deployment. Test only on a local fork or the programme’s test environment.
ComponentTypeIdentifierNotes
corvid_amm programSolanaSmart contracts7FKSoCWE2132VGWgnPAPwAHcUMXB6uhVEsCP6g8WfVdzPool initialisation, swaps, deposits and withdrawals
Pool PDASolanaSmart contractsHtYk1iQo8LTSdrXxwMDrByKrKCLa8RBiYNmwduKVn2sPHolds pool state and authority over token vaults
Token vaultsSolanaSmart contracts296FUhmZq23WDDYcNhcsmB3VfA53kGn194q8hmm1E1pXSPL token accounts owned by the pool authority
Fee collectorSolanaSmart contractsGZWZc9eHfwjRxNN7U83Tfix4rN4EmTQ6DxYAXRRdQxNRProtocol fee accounting and withdrawal

Out of scope

  • SPL Token and Token-2022 programs
  • RPC providers and front end
  • Issues already reported in the research assessment
  • Findings that require compromised keys or privileged access the attacker could not obtain

Severity

How findings in this programme are rated.

Examples specific to Corvid AMM. The full criteria are in the severity guidelines.
  • Critical
    • Withdrawing pool vault tokens without burning LP tokens
  • High
    • Swapping against a substituted pool account
    • Breaking the constant-product invariant
  • Medium
    • Fee accounting errors that leak value over time
  • Low
    • Missing validation that only causes failed transactions

Rules of engagement

Research within these rules.

  1. 01Test only against a local fork or the programme’s test deployment. Never interact with production systems or other users’ funds.
  2. 02Do not run denial-of-service, spam or social-engineering tests, and do not access data that is not yours.
  3. 03Report privately through the submission form. Keep details confidential until a disclosure date is agreed.
  4. 04One finding per submission, with a reproducible proof of concept where code is involved.
  5. 05Issues already listed in the protocol’s research assessment as acknowledged or open are not eligible for recognition.

These rules, together with the disclosure policy, define what the programme authorises. Testing outside them is not authorised.

Recognition

Validated findings receive recognition. This programme offers no monetary reward.

  • 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.

Report a finding in this programme.

One finding per submission, with steps to reproduce. Keep details private until a disclosure date is agreed.