Skip to main content

Architecture Overview

ChimeraMiND is a single production backend plus five client surfaces, not a collection of ad-hoc scripts. This page maps the tiers an engineer or auditor would need to understand the system without a walkthrough from the founder.

Infrastructure tiers​

TierRoleOwner
BackendFastAPI, 500+ route handlers across 67 route files, single VPSSelf-hosted, Cloudflare-fronted
DataSupabase (PostgreSQL + Auth + RLS)Supabase managed
Cache / pub-subRedisSelf-hosted on the same VPS tier
EdgeCloudflare (DNS, Pages, Workers, Turnstile)Cloudflare
PaymentsWhop (canonical checkout, since 2026-04)Whop
Error trackingSentrySentry
Exchange execution7 gateway modules -- 6 external (Binance, OKX, Bybit, Bitget, Coinbase, Kraken) + 1 internal Paper -- via a non-custodial vault patternPer-exchange, credential-isolated

Client surfaces​

  • Desktop — Svelte 5 + SvelteKit + Tauri 2. Owns the exchange-credential vault; the backend never receives plaintext exchange keys.
  • Web — React 19 + Vite, this marketing/account/billing surface (chimeramind.com).
  • Admin — React 19 + shadcn/ui, internal operations console.
  • Mobile — Expo 54 + React Native.
  • This docs site — Docusaurus, static, deployed independently of the product surfaces above.

Runtime shape​

  • Live product state (positions, signals, portfolio, bot status) flows over Socket.IO. No REST polling on the client for live data.
  • The backend runs long-lived in-process background tasks for decision recording, alert evaluation, and model heartbeats (RL, NAS, ghost-protocol, swarm) — these are isolated-lifecycle tasks with explicit startup/shutdown handling, not one-off cron scripts; state recovery on restart depends on the task's own persisted-state design, not a single uniform guarantee.
  • Strategy decisions are produced by an ensemble (15 strategy modules coordinated through strategy_mux and decision_engine), not a single model — see Service Catalog for the full inventory.

Crawlability​

chimeramind.com is a client-rendered React SPA, which by default returns an empty shell to any client that doesn't execute JavaScript -- most search engines now render JS, but most AI/LLM crawlers (GPTBot, ClaudeBot, PerplexityBot) and social-preview unfurlers (Twitterbot, LinkedInBot, Slackbot) do not. Rather than migrating to full server-side rendering, a Cloudflare Pages Function (web/functions/_middleware.ts) detects known bot user agents at the edge and serves a build-time Playwright-rendered static snapshot for that route; ordinary browser traffic gets the unmodified SPA. Zero behavior change for humans; rendered content is served to a maintained allowlist of recognized search, AI and social-preview crawler user agents, with the client-rendered SPA as fallback for any crawler not on that list.

Multi-tenant model​

Each user's trading state (positions, calibration, portfolio) is isolated by Redis key namespace and Supabase Row-Level Security. The platform also runs a _system paper account, isolated from real tenant data, used for internal measurement and model validation.

Why this matters for continuity​

None of the above depends on tribal knowledge. Every tier in this table is an individually identified, operationally documented component — see Engineering Practice for how that documentation is enforced, and Decision Log for why each major architectural choice was made. Backend and Redis currently share a single VPS failure domain; that is a stated infrastructure boundary, not an "independent deploy per tier" claim.