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, reducing reliance on getting every application-layer filter right. RLS is a strong boundary, not an absolute guarantee -- its effectiveness depends on correct policy coverage, isolating privileged/service-role access paths from it, and testing policies as code changes, all of which are operational disciplines rather than one-time properties.

Public vs. internal API surface​

The platform runs 500+ internal route handlers across 67 route files. Only a small, explicitly whitelisted subset (see Endpoint Catalog) is published as anonymous public API. This is a disclosure-minimization choice, not the security boundary itself -- the actual boundary is authentication, authorization, and per-tenant rate limiting enforced on every route regardless of whether its path is publicly documented. Not publishing the full route list reduces reconnaissance value for an attacker; it is not a substitute for access control.

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.