Autonomer LLM-Trading-Bot auf MEXC Futures

01Kernidee & Prinzipien

Ein LLM trifft nicht direkt Orders, sondern durchläuft eine Kette mit klarer Verantwortungs-Trennung. Jeder Bot ist eine isolierte Instanz dieser Kette.

02Gesamtarchitektur

Der Datenfluss eines einzelnen Bots — von Trigger bis Journal. Farbe = Verantwortung.

03Der Flow — 7 Schichten

04Multi-Bot & Subaccounts

Eine Control-Plane (Fleet-Manager) verwaltet beliebig viele Bots. Jeder Bot ist eine unabhängige Instanz der Pipeline mit eigenem Prompt, eigenem Tool-Set, eigenen Guardrails und eigenem MEXC-Subaccount. Geteilt wird nur der Code (Tool-Registry) und die Infrastruktur — nicht das Kapital.

Bot anlegen → Subaccount deployen (Provisioning)

1. Config: User definiert Name, System-Prompt, aktive Tools + deren Config, Guardrail-Werte, Startkapital.
2. Subaccount: System legt einen MEXC-Futures-Subaccount an, aktiviert Futures und generiert einen auf diesen Subaccount begrenzten API-Key.
3. Vault: Key verschlüsselt speichern, nur dem einen Bot zugeordnet.
4. Runtime: Fleet-Manager startet Run-Engine + Position-Manager des Bots.
5. Live: Bot erscheint im Dashboard — im Paper-Modus als Default, bis der User ihn scharf schaltet.

05Tool-Plugin-System

Ein Tool = Ordner mit Manifest (was es kann, welche Inputs) + Skript (was es tut). Der Kern kennt keine einzelne Datenquelle. Tools sind fleet-weit geteilter Code, aber pro Bot einzeln aktiviert & konfiguriert.

tools/
  x_sentiment/
    manifest.json   # Name, Beschreibung,
                    # input_schema, config_schema
    run.py          # run(input, config)->dict
  funding_rate/
    ...

{
  "name": "x_sentiment",
  "label": "X / Twitter Sentiment",
  "input_schema": { "type":"object",
    "properties": {"query":{"type":"string"}},
    "required": ["query"] },
  "config_schema": { "x_api_key":{"secret":true} }
}

1. Registry scannt tools/, lädt Manifeste.
2. Pro Bot-Run filtert sie auf die vom Bot aktivierten Tools und baut daraus die tools-Liste der Anthropic-Messages-API (Manifest = 1:1 Tool-Definition).
3. LLM ruft Tool auf → Orchestrator dispatcht an run(input, config), injiziert die bot-spezifische Config aus dem Vault, liefert tool_result zurück.
4. UI rendert Toggle + Config-Formular aus config_schema.

06Tool-Katalog (Start-Set)

Execution-/Manager-exklusiv (write, nur nach Freigabe): place_order, set_leverage, modify_sltp, close_position — nie dem Analyst gegeben.

07Analyst & Risk-LLM

Zwei getrennte Rollen mit erzwungenen Schemas (Structured Output). Default claude-opus-4-8; Manager-Loop kann claude-sonnet-5 nutzen (Kosten).

{ "action":"propose"|"no_trade",
  "asset":"BTC_USDT",
  "direction":"long"|"short",
  "suggested_leverage":5,
  "confidence":0.72,
  "thesis":"Funding negativ + …",
  "invalidation":"Schluss < 61k" }

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

Position-Manager: Aktion hold · move_sl · take_partial · close — jede Änderung erneut durch die Guardrails.

08Risiko-Guardrails deterministisch

Code, kein LLM. Nicht überredbar. Werte in der UI pro Bot konfigurierbar, der Mechanismus ist fix.

09MEXC-Integration

Contract-/Futures-API. Auth: HMAC-SHA256 (Header ApiKey / Request-Time ms / Signature, optional Recv-Window ≤60s). Signatur über accessKey+timestamp+paramString. Zeitfenster ~10s → NTP-Sync.

Pfade gemäß MEXC-Integrationsguide; vor Implementierung gegen aktuelle Doku prüfen.

10Datenmodell (Postgres)

11Tech-Stack

LLM: Claude via Anthropic-SDK. Analyst & Risk claude-opus-4-8; Manager-Loop claude-sonnet-5. Pro Bot ein Token-Budget setzen (Kosten-Deckel).

12Empfehlungen — was ich anders / zusätzlich machen würde

Konkrete Vorschläge über deine Anforderung hinaus. Nichts davon ist zwingend, aber jedes senkt Risiko oder erhöht den Research-Wert.

13Roadmap

14Offene Fragen & Risiken

• Subaccount-Zugang: Broker-API oder manuelle Anlage + Registrierung? → bestimmt Phase 4.
• MEXC-Order-Freigabe pro Subaccount vor Live verifizieren.
• Latenz vs. LLM-Dauer: schnelle Moves macht der regelbasierte Manager, nicht der Voll-Flow.
• Kosten: Manager-Loop × N Bots → Sonnet, WS-Trigger statt Polling, Token-Budgets, Prompt-Caching.
• Tool-Qualität = Entscheidungsqualität: verdichtetes Signal, kein Rohmüll.
• Slippage & Teilfills realistisch im Paper-Mock simulieren.