Skip to main content

Security & Compliance

Non-custodial exchange model​

Exchange API credentials are encrypted client-side in the desktop app and never stored in plaintext on the backend. The vault uses AES-256-GCM for the credential payload and Argon2id (32 MiB memory cost) for key derivation. Withdrawal permissions are disabled by policy on every connected key — the platform is built to trade, not to move funds out of an account.

Trading instructions are signed by the desktop vault and relayed over an authenticated channel; the backend gateway per exchange is stateless with respect to credentials — it never has a plaintext key to leak.

Authentication layers​

  • Identity: Supabase Auth owns registration, email verification, and password reset.
  • Session: JWT access tokens plus refresh-token rotation; API keys for programmatic/developer access; role-based access control (RBAC) at the route level.
  • Transport: TLS/HTTPS everywhere. Sensitive fields are additionally encrypted at rest (Fernet for backend-held secrets, AES-256-GCM for the client-side exchange vault).
  • Row-level isolation: Supabase Row-Level Security scopes every tenant's data at the database layer, not just in application logic — a query bug cannot leak another user's rows.

Public vs. internal API surface​

The platform runs 500+ internal route handlers across 57 route files. Only a small, explicitly whitelisted subset (see Endpoint Catalog) is published as anonymous public API. This is a deliberate scoping decision, not an oversight — publishing the full internal surface would hand a scanner a map of authenticated attack surface for no benefit to a legitimate integrator.

Where to verify​

Disclaimer​

This page describes the security architecture as implemented. It is not a compliance certification. ChimeraMiND has not obtained a third-party audit or compliance certification (e.g. SOC 2) as of this writing; the architecture above is the technical baseline such an audit would be run against.