Skip to content
Quantix Security Labs

Northstar Custody research programme.

Institutional custody with MPC signing and a policy engine. The programme targets the client API, the approvals console and policy enforcement in a dedicated test environment.
OpenOpened 20 April 2026

Programme overview

Protocol category
Custody
Ecosystems in scope
EthereumSolana
In-scope components
4 (0 contracts, 4 other)
Languages
Rust, Go, TypeScript

Focus areas

Where research is most wanted.

  • 01

    Policy-engine bypass

  • 02

    Approval-quorum integrity

  • 03

    API authentication and tenancy isolation

  • 04

    Session handling in the approvals console

Scope

In scope.

Identifiers belong to the programme’s research deployment. Test only on a local fork or the programme’s test environment.
ComponentTypeIdentifierNotes
Client APIWeb / APIapi.northstar-custody.exampleREST API for transaction requests (test tenant)
Approvals consoleWeb / APIconsole.northstar-custody.exampleWeb application with hardware-key approvals
Policy engineInfrastructurepolicy.northstar-custody.exampleReachable only through the client API
Client SDKWallet / SDKsdk.northstar-custody.exampleTypeScript SDK for request signing (programme release)

Out of scope

  • MPC node hosts and physical security
  • Other tenants’ data
  • Phishing of Northstar staff
  • 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 Northstar Custody. The full criteria are in the severity guidelines.
  • Critical
    • Signing a transaction that violates policy
    • Accessing another tenant’s wallets
  • High
    • Approving with fewer approvers than the quorum
    • Session takeover in the approvals console
  • Medium
    • Information disclosure of policy configuration
  • Low
    • Verbose error messages without sensitive data

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. 05Use only the test tenant credentials issued for the programme; never test with real customer accounts.

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.