LLM-Trading-Fleet auf MEXC Futures

01Was sich ändert — und was bleibt

Ehrliche Einschätzung: Der Kern von v2 war richtig (2-LLM, Guardrails, 1 Bot = 1 Subaccount, Modi, Telegram). Er bleibt. Drei Dinge werden aber von „Empfehlung" zu „Fundament" — getrieben vom echten Test. Kein Teardown, sondern gezielte Verstärkung. (Telegram fällt vorerst weg, die Infrastruktur wird bewusst schlanker — siehe §02.)

02System & Services

End-to-end TypeScript, damit das Event-Modell zwischen Backend und Frontend 1:1 geteilt wird — genau das macht die Live-Visualisierung ohne Schema-Drift möglich. Bewusst schlank gehalten: 2 Services + 1 DB, alles auf Railway.

Wie der Live-Bus ohne Redis geht: Der worker schreibt jedes Event in run_events und feuert ein NOTIFY. Der web-Service LISTENt, liest die neue Zeile und schiebt sie per SSE in den Browser. Postgres ist damit Wahrheit und Nervensystem in einem — robust bei dem Volumen, das hier realistisch ist.

03Der Run als State-Machine + Event-Stream

Das Rückgrat. Ein Run ist eine explizite Zustandsmaschine; jeder Übergang erzeugt ein typisiertes Event, das (a) in Postgres landet (Audit) und (b) live per SSE ans Frontend geht. Die grafische „wo ist der Bot gerade"-Ansicht liest genau diesen Strom.

Event-Beispiele (alle typisiert, ein runId je Run): run.queued · context.built · analyst.tool_call · analyst.tool_result · analyst.thesis · risk.decision · approval.requested · execution.order_placed · position.opened · manager.action · position.closed. Das Frontend rendert daraus die animierte Pipeline; dieselben Events sind der Audit-Trail.

04Account-Mirror — weil MEXC die Subaccounts versteckt

Da im MEXC-Web nichts von den Subaccounts sichtbar ist, spiegelt market-sync jeden Subaccount kontinuierlich in unsere DB. Alles — UI, Risk-Berechnung, Manager — liest aus dem Mirror, nicht direkt von MEXC.

05Universal Tool-Layer — „hook anything"

Dein Wunsch: wirklich alles anhängen können. Lösung: jedes Tool erscheint dem LLM als normale Anthropic-Tool-Definition — dahinter steckt aber ein austauschbarer Provider. Fünf Arten decken praktisch alles ab.

Alle teilen dasselbe Schema: Input-Schema (treibt Tool-Definition und das UI-Config-Formular), Secret/Config-Schema (Vault), Enable-pro-Bot, Timeout, Rate-Limit, Kosten-Logging. In der UI: eine „Tool-Studio"-Ansicht zum Anlegen & Testen (Sample-Input rein, Output sehen) — das ist die Flexibilitäts-Oberfläche.

06Bots & Subaccounts

Ein Fleet-Manager verwaltet N Bots; jeder Bot ist eine isolierte Instanz der Pipeline mit eigenem Prompt, Tool-Set, Guardrails und eigenem MEXC-Subaccount. Geteilt wird nur Code & Infra — nie Kapital.

Provisionierung (getestet, funktioniert): Bot-Config → Subaccount per Broker-API anlegen → Futures aktivieren → Startkapital transferieren → scoped API-Key erzeugen → Vault → market-sync startet Spiegelung → Runtime läuft → Bot live (Paper-Default). Bot-Vielfalt offen: verschiedene Strategien und gleiche Strategie in Varianten (A/B für Confidence-Kalibrierung).

07Analyst · Risk · Guardrails

{ "action":"propose"|"no_trade",
  "asset":"BTC_USDT",
  "direction":"long"|"short",
  "suggested_leverage":5,
  "confidence":0.72,
  "thesis":"…", "invalidation":"< 61k",
  "used_tools":["funding_rate","mcp:news"] }

{ "approved":true, "leverage":3,
  "size_usdt":40, "stop_loss":60800,
  "take_profit":[63500,65000],
  "reason":"Event-Risiko → halbe Größe",
  "guardrails_applied":["lev_cap"] }

Deterministische, nicht LLM-überschreibbare Limits (pro Bot konfigurierbar): max_leverage, max_pos_pct, max_total_exposure, min_confidence, mandatory_stop, daily_loss_stop (Kill-Switch), max_open_positions, cooldown, fleet_correlation (≤N Bots gleiche Richtung/Asset), global_kill_switch. Equity/Exposure kommen aus dem Mirror. Manager-Aktionen (hold/move_sl/take_partial/close) laufen erneut durch die Guardrails.

08Betriebsmodi

Zwei orthogonale, zur Laufzeit umschaltbare Achsen — pro Bot, gesteuert über das Frontend.

Steuerung im Frontend: Modus umschalten, Trades freigeben/ablehnen, Kill-Switch pro Bot + global, Status/PnL & Positionen (aus dem Mirror), Drift-Alerts als In-App-Benachrichtigung. später optional Telegram als dünner Zusatz-Kanal — ändert nichts an der Architektur.

Paper-Trading — bewusst einfach, ohne Fees

MEXC bietet keine Paper-/Testnet-API (nur Demo im Web-Interface), also simulieren wir selbst — und halten es zunächst schlank: Paper füllt Orders ohne Gebühren, PnL = reine Preisbewegung. Fees & Funding kann man sich vorerst überschlägig selbst dazurechnen; ein echtes Fee-/Funding-Modell ist später einsteckbar, ohne die Architektur zu ändern.

Ein Interface, zwei Backends. Der ExecutionAdapter (place / modify / cancel / close) — der Modus-Schalter wählt nur aus:

Weil die Gebühren-Logik hinter dem sim-Backend gekapselt ist, lässt sich ein Fee-/Funding-Modell (Sätze live aus contract/detail / funding_rate) jederzeit nachrüsten — ohne dass Analyst, Risk oder UI etwas merken.

09Live-Frontend — sehen, was gerade passiert

Das Herzstück deiner Anforderung. Der SSE-Event-Stream treibt eine animierte Pipeline: man sieht in Echtzeit, bei welchem Schritt jeder Bot steht — Analyse, Risiko, Order, Management — inkl. der Tool-Calls, während sie passieren.

10Tech-Stack & Railway

Zwei deploybare Services + eine Managed-DB. Falls der worker später mehr Isolation braucht (Mirror darf nicht mit einem Run mitsterben), in worker-runtime + worker-sync splittbar — aber erst wenn es weh tut.

Sobald du „go" sagst, lege ich das Railway-Projekt mit genau diesen Services an (dein Account + Credit) und richte das Monorepo-Deployment ein.

11Datenmodell (Postgres)

12Roadmap & offene Fragen

• Subaccount-WS: hat MEXC pro Subaccount einen privaten WebSocket, oder nur REST? → bestimmt Mirror-Latenz (Poll-Fallback ist eingeplant).
• Broker-API-Umfang pro Subaccount vor Phase 5 gegen die aktuelle Doku prüfen (Sub-Key-Scopes, Transfer-Endpoints).
• Kosten: Manager-Loop × N Bots → Sonnet für den Loop, WS-Trigger statt Polling, Token-Budget pro Bot.
• Sandbox für script-Tools: Isolation wählen (isolated-vm / Container) — untrusted Code.