LLM-Trading-Fleet · MEXC Futures · Review + Umsetzungsplan

Fleet v3.1 — vom schönen System zum messbaren System

Das Konzept v3 ist als Software-Architektur stark. Als Trading-System optimiert es die falsche Sache: ~90 % „schnell live", ~10 % „messen ob überhaupt Edge da ist". Dieser Plan dreht das um — ohne die guten Kern-Entscheidungen anzufassen — und zieht, weil Echtgeld das Hauptziel ist, die Execution-Härtung von Anfang an mit.

Kostenmodell ab Paper v1 exchange-native Stops Kill + Flatten Manager = Regeln, LLM nur bei Invalidierung Risk-LLM v1 raus Provisioner isoliert Tool-Layer: builtin·http·mcp

01 · Mein Review — was bleibt, was ich anders mache

Kurzurteil

BLEIBT

Die Architektur-Grundpfeiler sind erfahren und richtig. Account-Mirror als Single Source of Truth (der wichtigste Insight), event-sourced Runs, Postgres-only statt Redis (LISTEN/NOTIFY + pg-boss), 1 Bot = 1 Subaccount, TS-Monorepo mit geteiltem Schema, Approve als Default, getestetes Auto-Provisioning. Da erfinde ich nichts um.

KERN-RISIKO

Es gibt keinen nachgewiesenen Edge. Ein LLM, das „mit Tools recherchiert" und eine gehebelte Richtungswette rausgibt, handelt auf Perps gegen ein Negativ-Summen-Spiel (Taker-Fees, Funding, Spread, Slippage, Liquidationsjagd). Basisannahme im Real-Modus: es verbrennt Geld. Konsequenz — nicht „lass es", sondern: Das Projekt ist primär ein Research-Harness, und das Design muss aufs ehrliche Messen optimiert sein, bevor Kapital skaliert wird.

Anders entscheiden — Trading

1Paper ohne Fees ist gefährlich, nicht nur „einfach". Fee/Funding/Slippage entscheiden bei gehebelten Perps über +/−EV. Kostenmodell ab Paper v1 (~1 Tag). → übernommen.
2Backtest ist hier fast unmöglich (News-Leakage + LLM kennt Vergangenheits-Charts → Hindsight). Ehrliche Evaluation = Forward-Paper + Kostenmodell + walk-forward + Benchmark (vs. BTC halten, vs. Random-Entry gleiches Risiko).
3Manager-LLM raus aus der schnellen Schleife. Trailing-Stop, Break-even, Partial@R sind Regeln. LLM nur langsam / bei Thesis-Invalidierung. Löst die „Kosten Manager×N"-Frage.
4Risk-LLM in v1 streichen. Sizing deterministisch (Vol-Targeting / fixed-fractional). Guardrails sind die Autorität. LLM-Risk nur später, mit Evidenz.

Anders entscheiden — Software / Betrieb

5Stops müssen exchange-nativ sein. mandatory_stop als reduce-only Stop-Order auf MEXC — schützt auch bei totem Stack (Single-Worker = SPOF).
6Kill-Switch zweistufig: Halt (nichts Neues) + Flatten (alles sofort market-close), Flatten umgeht die ganze Pipeline — direkter Draht zur Exchange-API.
7Prompt-Injection → Fund-Transfer. Tool-Layer führt fremden Output aus, im selben Worker der Trading-Keys hält. Provisioner (Master-Key) als eigener, IP-allowlisted Deploy — nicht „später".
8Tool-Layer v1 abspecken auf builtin·http·mcp. script/sub-agent + Tool-Studio später (dort liegt die Sandbox-Frage).
9Echtes Ledger statt nur Snapshots (Deposits, Transfers, Fills, Fees, Funding, realized PnL) → Equity erklärbar. Decimal, keine Floats.
10MEXC hat kein Testnet. Marktdaten vom Venue abstrahieren; ExecutionAdapter-Plumbing gegen Bybit/Binance-Testnet validieren, bevor MEXC-Echtgeld läuft.

Deine Vorgaben, eingearbeitet: Kostenmodell ab v1 ✓ · Frequenz offen/A-B → horizont-agnostisch, Bots tragen ihr eigenes Fee-/Manager-Profil · Echtgeld = Hauptziel → Härtung front-loaded · Kapital ab ~100 $ flexibel → Mindest-Notional- & Fee-Drag-Guard pro Bot.

02 · Delta zum Konzept v3

Was sich konkret ändert

Thema	Konzept v3	Plan v3.1	Warum
Paper-Fills	ohne Fees, „bewusst einfach"	Fees + Funding + Slippage ab v1	Sonst ist jeder Track-Record geschönt
Evaluation	Backtest zuletzt (Phase 6)	Forward-Test-Rig + Scorecard früh (Phase 2)	LLM-Backtest ist leakage-verseucht; Forward misst ehrlich
Risk	Risk-LLM (opus) + Guardrails	Deterministisches Sizing + Guardrails; LLM-Risk später	Reproduzierbar, billig, real-money-tauglich
Manager	LLM-Loop (sonnet) pro Position	Regel-Engine; LLM nur bei Invalidierung / langsamem Takt	LLMs sind schlecht in schneller Risikoführung; Kosten
Stops	Guardrail `mandatory_stop`	Exchange-native reduce-only Stop-Order	Schutz auch bei App-/Worker-Ausfall
Kill-Switch	Bot + global	+ zweistufig: Halt vs. Flatten (pipeline-bypass)	Echtgeld braucht harten, un-umgehbaren Notaus
Services	web + worker (+ „später splittbar")	web + worker + provisioner + Postgres	Master-Key vom Tool-ausführenden Worker isolieren
Tool-Layer	5 Provider + Tool-Studio + Sandbox	builtin·http·mcp; script/sub-agent später	Kleinste Angriffs-/Komplexitätsfläche bei unbewiesenem Edge
Marktdaten	MEXC direkt	Venue-abstrahiert (Daten ↔ Execution getrennt)	Testnet-Validierung + robuster gegen MEXC-Ausfall
Accounting	Mirror-Tabellen + Snapshots	+ Ledger (Buchungen), Decimal überall	Equity & Reconciliation erklärbar statt geraten

03 · Architektur

Services & Datenfluss

Drei Deploys + Postgres. Der provisioner ist neu und bewusst isoliert: nur er kennt den Broker-Master-Key. Der worker hält nur scoped Trading-Keys und führt LLM/Tools aus — so kann eine Prompt-Injection nie an den Master-Key.

web (UI/API/SSE) worker (runtime, scoped keys) provisioner (master-key, isoliert) Postgres (truth + bus + queue)

Später splittbar: worker-runtime (LLM/Execution) vs. worker-sync (market-sync/Reconciliation), und Redis kommt sauber dazu, sobald SSE über mehrere web-Instanzen skaliert. Kein Dogma — kein vorzeitiges Splitting.

04 · Run = State-Machine + Event-Stream

Ein Trade, von Idee bis Close

Jeder Übergang = typisiertes Event in Postgres (Audit + rückspulbar) und live per SSE. Neu: Order platziert gleichzeitig die exchange-native reduce-only Stop-Order; manager.action läuft über die deterministische Regel-Engine, das LLM wird nur bei Thesis-Invalidierung geweckt. Reproduzierbarkeit: pro LLM-Entscheidung Prompt-Snapshot + Modell-ID + Temperatur mitloggen.

05 · Risk, Guardrails & Manager

Deterministische Kette (Autorität)

Analyst-LLM liefert nur die These. Alles danach ist Code — clampt und vetot.

Sizing: Vol-Targeting oder fixed-fractional, Equity aus dem Mirror
Guardrails: max_leverage · max_pos_pct · max_total_exposure · min_confidence · daily_loss_stop · max_open_positions · cooldown · fleet_correlation · global_kill
mandatory_stop: als exchange-native reduce-only Order
Mindest-Notional-Guard: Trade ablehnen wenn Size < MEXC-Minimum oder Fee-Drag > X % des erwarteten Moves (wichtig bei ~100 $ Bots)

Manager = Regel-Engine

Regeln (schnell, deterministisch): Break-even nach +1R, Trailing-Stop, Partial@R-Vielfache, Time-Stop
LLM (langsam, selten): nur bei Thesis-Invalidierung oder auf grobem Takt neu bewerten → hold / close
Jede Manager-Aktion erneut durch die Guardrails
Modelle: opus-4-8 Analyst · deterministisch Risk · sonnet-5 nur für seltene Re-Evaluation

Kill-Switch: Halt stoppt neue Runs. Flatten feuert reduce-only Market-Closes direkt an die Exchange — umgeht Queue, Manager, LLM. Ein Button, un-umgehbar.

06 · Umsetzung — Step by Step

Reihenfolge: erst Wahrheit & Messung, dann Kapital

Reihenfolge ggü. v3 umgestellt: Mirror + Ledger, dann ehrliches Paper mit Kostenmodell und Scorecard — bevor überhaupt eine These generiert wird. Real-Härtung (native Stops, Flatten, Provisioner-Isolation) sitzt vor dem ersten Echtgeld-Euro.

Skelett & Bus

Fundament

TS-Monorepo, packages/shared = Event- + Tool-Schema (web/worker geteilt, Zod)
Railway: webworkerprovisionerPostgres
Event-Bus: run_events + NOTIFY → web LISTEN → SSE. Queue: pg-boss. Migrations, CI.

Account-Mirror + Ledger zuerst

Kontosicht = Wahrheit

market-sync: WS (Fills/Order/Position) + REST-Poll-Fallback → balances/positions/orders (synced_at)
Ledger (Buchungen: transfer/fill/fee/funding/realized) → Equity erklärbar; equity_snapshots → PnL-Kurve
Reconciliation Soll vs. Ist → Drift-Alert + Auto-Pause. Marktdaten venue-abstrahiert.
UI: Fleet-Board + Konto-Ansicht liest aus dem Mirror (noch ohne Trading)

Kostenmodell + Paper-Adapter + Scorecard

ehrlich messen

ExecutionAdapter sim: füllt zum Kurs mit Taker-Fee + Funding-Accrual + simpler Slippage (Sätze live aus contract/detail / funding_rate)
Scorecard ab Tag 1: Sharpe/Sortino, MaxDD, Hit-Rate, avg R, Turnover, Fee-Drag, Funding-Drag — plus Benchmark (BTC-hold, Random-Entry gleiches Risiko)
Forward-Test-Rig: walk-forward, out-of-sample, pro Bot & Fleet

Analyst + Live-UI

These → Pipeline

Analyst-LLM (opus-4-8) → Thesis (action, asset, direction, suggested_leverage, confidence, invalidation, used_tools)
Tool-Layer v1: builtinhttpmcp · Output = untrusted, nur Daten
SSE-Pipeline: aktive Stage pulsiert, Tool-Calls live, Thesis inline; Run rückspulbar aus Events
Reproduzierbarkeit: Prompt-Snapshot + Modell-ID + Temp pro Entscheidung

Deterministische Risk-Schicht + Dry-Run

Guardrails scharf

Deterministisches Sizing + volle Guardrails (Equity aus Mirror), Mindest-Notional-Guard
Exchange-native Stop-Order als Teil jeder Order — auch im Paper simuliert
Voller Paper-Loop end-to-end: Analyse → Risk → sim-Order → managed → Close, alles auf der Scorecard

Real klein — Härtung vor dem ersten Euro

Echtgeld-Gate

ExecutionAdapter real: Plumbing zuerst gegen Bybit/Binance-Testnet validieren (MEXC hat keins)
Kill/Flatten zweistufig · Approve-UI (Pending-Trade-Karte) · Orphan-Position-Detection beim Restart
Provisioner scharf: Master-Key nur dort, IP-allowlisted, scoped Keys → Vault → worker
Dann MEXC mit Mini-Size (ab ~100 $), 1 Bot, Approve-Modus. Modi: Paper↔Real × Approve↔Autonom

Fleet — Auto-Provisioning

N Bots, A/B

Fleet-Manager: Config → Subaccount → Futures an → Transfer → scoped Key → sync → Runtime → live (Paper)
Verschiedene Horizonte/Strategien pro Bot (deine „offen/A-B"-Vorgabe): jeder Bot trägt sein Fee-/Manager-/Frequenz-Profil
fleet_correlation-Guard greift über Bots hinweg

Ausbau

wenn Zahlen tragen

Manager-LLM-Re-Evaluation feiner · optional LLM-Risk-Advisory (nur mit Evidenz aus der Scorecard)
Tool-Layer erweitern: script (Sandbox-Entscheidung) + sub-agent + Tool-Studio-UI
Fee-/Funding-Kalibrierung verfeinern · Telegram als dünner Zusatz · worker-split / Redis bei Bedarf

07 · Datenmodell

Tabellen

bots            (id, name, mode_exec[paper|real], mode_appr[approve|auto],
                 horizon, strategy_profile, fee_profile, subaccount_id)
subaccounts     (id, bot_id, mexc_ref, status, provisioned_at)
tools           (id, art[builtin|http|mcp], manifest, input_schema, config, enabled_bots[])
secrets         (id, scope, ciphertext)                 -- Vault; master-key NUR im provisioner
runs            (id, bot_id, state, created_at)         -- State-Machine
run_events      (id, run_id, type, payload_jsonb, ts)   -- typed, audit + replay + SSE
theses          (run_id, action, asset, direction, suggested_leverage, confidence,
                 invalidation, used_tools, prompt_snapshot, model_id, temperature)
decisions       (run_id, approved, leverage, size_usdt, stop_loss, take_profit[],
                 guardrails_applied, reason)
orders          (id, bot_id, run_id, kind[entry|stop|tp], reduce_only, status, synced_at)
positions       (id, bot_id, asset, side, qty NUMERIC, entry, liq, synced_at)   -- Mirror
balances        (bot_id, asset, free NUMERIC, used NUMERIC, synced_at)          -- Mirror
ledger          (id, bot_id, kind[transfer|fill|fee|funding|realized], amount NUMERIC, ref, ts)
equity_snapshots(bot_id, equity NUMERIC, ts)
manager_actions (id, position_id, kind[hold|move_sl|take_partial|close], by[rule|llm], ts)

Alle Preise/Sizes NUMERIC/Decimal — nie Float. Equity ist die Summe aus dem Ledger, nicht ein losgelöster Snapshot; der Snapshot ist die Zeitreihe fürs PnL-Chart.

08 · Entschieden & offen

Entschieden

Kostenmodell ab Paper v1 ✓
Echtgeld = Hauptziel → Härtung front-loaded ✓
Frequenz offen → Bots horizont-agnostisch, eigenes Profil ✓
Kapital flexibel ab ~100 $ → Mindest-Notional-Guard ✓
Risk deterministisch · Manager als Regel-Engine · Tool-Layer builtin·http·mcp ✓

Noch zu klären

MEXC privater WS pro Subaccount stabil, oder REST-Poll als Primär-Fallback?
Broker-API-Scopes real: reichen Transfer + Subacc-Create + scoped Trading-Key?
Sizing-Default: Vol-Targeting vs. fixed-fractional als v1-Standard?
Testnet-Venue für Adapter-Validierung: Bybit oder Binance?
Secret-Storage: Railway-Vars reichen v1, oder direkt echtes KMS/Vault?

Auf go lege ich die Railway-Services (web · worker · provisioner · Postgres) an und starte mit Phase 0 + 1.