Event-Driven Fleet · Signal → Execution Engine

When-Then Engine mit einsteckbarem LLM-Evaluator

Kein Entweder-oder. Das Rückgrat ist eine deterministische Regel-Engine (wenn Wallet X das tut → short; wenn User Z postet → long). Das LLM ist kein separates System, sondern ein einsteckbarer Baustein an der Stelle „Bedingung" oder „Aktion" — und genau dort benutzt es Tools. Schnell wo nötig, klug wo sinnvoll, deterministisch als Default.

Trigger → Bedingung → Aktion condition/action = deterministisch | llm Latenz-Tiers pro Regel Shadow-Mode Event-Study-Validierung on-chain + social

Baut auf dem Fundament von trader4.opent.dev (Mirror · Ledger · Guardrails · native Stops · Provisioner · Fleet) auf — dies ist nur der neue Kopf davor. trader4 bleibt unverändert.

01 · Warum dieser Kopf

Der Edge liegt in der Information, nicht im „gut traden"

Beim TA-basierten Futures-Trading gibt es keinen strukturellen Grund zu gewinnen — negativ-summe, du zahlst Fees/Funding/Spread gegen den Anbieter. Event-driven ist eine andere Kategorie: die Erwartung ist positiv, weil du schneller oder besser informiert bist als die Gegenseite. Der Kostendrag bleibt — aber jetzt gibt es etwas, das ihn überkompensieren kann.

Wo der Edge real ist

Long-Tail: nischige, aber einflussreiche Accounts / kleine Tokens, die kaum jemand mit Bots überwacht.
MEXC ist dafür ideal — listet fast jeden Small-Cap als Perp (auf Binance gäbe's die gar nicht).
On-Chain schlägt Twitter bei Rugs: LP-Removal, Ownership-Change, Mint, Deployer→CEX sind vor jedem Tweet sichtbar, objektiv und via Webhook schnell.

Wo er nicht real ist

Große, liquide Namen & bekannte Accounts: Race gegen colocated HFT — verlierst du immer.
Datenzugang ist die eigentliche Arbeit: X-Firehose kostet; Telegram ist oft schneller. ~80 % des Aufwands.
Seltene Events → Statistik-Problem: breites Netz nötig, nicht ein Bot pro Signal.

02 · Das Modell

Eine Regel = Trigger → Bedingung → Aktion

Der Clou: Bedingung und Aktion sind je einzeln deterministisch oder LLM. Damit lebt „LLM mit Tools" innerhalb der when-then Engine — als ein Regel-Typ, nicht als Parallelwelt.

Trigger (schnell) Bedingung (det|llm) Aktion (det|llm) Guardrails (immer det, final)

03 · Drei Regel-Typen, ein Framework

Von Millisekunden-Rug bis LLM-Agent

A · rein deterministisch On-Chain Rug → sofort short hot path · ~ms

trigger:   onchain.liquidity_removed { pool, token }
bedingung: [deterministisch]  removed_pct > 50%  UND  token ∈ perp_universe
aktion:    [deterministisch]  short · size 1% equity · native stop +8%
                              · tp [-20%, -40%] · time-stop 2h

B · LLM-gated CEO postet → LLM prüft Materialität → short warm path · ~1s

trigger:   twitter.post { author = @ceo_of_token }
bedingung: [llm · haiku]  "materiell bearish für $TOKEN?"
                          -> { qualifiziert, confidence ≥ 0.7, richtung }
aktion:    [deterministisch]  short · size 0.5% equity · native stop · time-stop 4h

C · voller LLM-Agent + Tools Mehrdeutiges Signal → Agent recherchiert → entscheidet cold path · paar s

trigger:   twitter.post { author ∈ watchlist_tier2 }
bedingung: [llm-agent · opus + tools]
             tools = [tweet_lesen, onchain_liquidity, price_window, related_news]
             -> { trade?, richtung, confidence, horizont, begründung }
aktion:    [aus llm-output]  — Richtung/Size/Horizont vom Agent,
                              danach von den Guardrails geclampt

Alle drei laufen durch dieselbe Guardrail-, Execution- und Event-Stream-Schicht (siehe Diagramm). Der Universal-Tool-Layer (builtin·http·mcp) ist die Werkzeugkiste, aus der die LLM-Bedingungen/Aktionen schöpfen — hier wird er zum Kern, nicht zum Beiwerk.

04 · Warum diese Struktur gewinnt

Eigenschaften, die herausfallen

Latenz-Tiers automatisch: pure det = ms, llm-gated = ~1s, llm-agent = paar s. Du wählst pro Regel.
Regel = Einheit für Backtest & A/B: jede Regel einzeln per Event-Study testen und vergleichen.
Shadow-Mode pro Regel: neue Regel läuft erst „beobachtend" (bewertet + loggt, tradet nicht). Live erst wenn Trefferquote überzeugt.
Reproduzierbar: LLM-Urteil (Prompt/Modell/Verdict) wird als Teil des Events geloggt.

Event-Study = ehrliche Validierung

Anders als LLM-TA ist das hier backtestbar: Signal @ T + Kursreaktion um T sind beide objektiv.

Historische Events sammeln (Account X postete @ T / On-Chain-Rug @ T)
Abnormale Rendite im Fenster messen (+15m / +1h / +4h / +24h)
Über die Stichprobe: Mittelwert signifikant? nach Fees/Slippage? Verteilung?
→ Edge schwarz auf weiß, bevor ein Euro fließt.

Ehrliche Warnung: deterministisch als Default, LLM als bewusste Opt-in-Ausnahme. Der LLM-mit-Tools-Modus ist verlockend, aber langsam, teuer und non-deterministisch. Die Zuverlässigkeit lebt in den deterministischen Regeln. LLM nur dort, wo Menschenurteil nötig ist (ist dieser Tweet wirklich bearish?) — nicht als Standard-Hammer. Sonst hast du wieder den generischen LLM-Trader, nur mit mehr Schritten.

Latenz-Realität: Approve-Modus (Mensch im Loop) killt den Speed-Edge — 30+ s = Edge weg. Für event-driven genehmigst du Accounts/Regeln vorab, nicht einzelne Trades. Deine „granulare" Idee stimmt exakt: eine Watchlist, wo jeder Account/Token seinen Playbook trägt.

05 · Datenmodell (Erweiterung zu trader4)

Rule, Source, Trigger, Verdict

sources        (id, kind[onchain|twitter|telegram|price|news], config, secret_ref, latency_ms)
watchlist      (id, kind[author|token|wallet], handle_or_addr, tier, perp_symbol?)   -- mapping
rules          (id, bot_id, name, enabled, mode[shadow|live],
                trigger_type, trigger_filter_jsonb,
                condition_kind[det|llm|llm_agent], condition_spec_jsonb,
                action_kind[det|llm], action_spec_jsonb,
                cooldown, max_concurrent)
rule_events    (id, rule_id, raw_event_jsonb, ts_source, ts_detected)   -- latenz messbar
verdicts       (id, rule_event_id, qualified, direction, confidence,
                llm_prompt?, llm_model?, llm_output?, latency_ms)        -- reproduzierbar
                                                       -- danach: runs / decisions / orders
                                                       -- (aus trader4-Datenmodell)

Nahtlos an trader4: ein Verdict, das feuert, erzeugt einen run und läuft durch dieselbe Guardrail/Execution/Mirror-Kette. rules ist die Einheit für Shadow, Backtest und A/B.

06 · Reihenfolge

Erst beweisen, dann feuern

Event-Study-Rig zuerst

Edge beweisen

5–10 konkrete Watchlist-Accounts / Tokens historisch durchmessen (abnormale Rendite nach Event)
On-Chain-Rug-Events historisch (LP-Removal etc.) gegen Kursreaktion
Ergebnis entscheidet, ob & wo Live-Infrastruktur lohnt kein Kapital-Risiko

Signal-Ingestion + Rule-Engine (Shadow)

live beobachten

Sources anschließen: on-chain webhook zuerst (objektiv, ownable), dann Telegram, dann X
Trigger→Bedingung→Aktion-Engine, alle Regeln im Shadow-Mode (bewerten + loggen, kein Trade)
Trefferquote / Latenz pro Regel messen, gegen die Event-Study spiegeln

Scharf: Paper → Real klein

auf trader4-Basis

Beste deterministische Regeln zuerst live (hot path), Guardrails + native Stops aus trader4
LLM-gated (haiku) als zweite Stufe, LLM-Agent (C) nur für ausgewählte mehrdeutige Fälle
Autonom mit vorab genehmigten Regeln · Kill/Flatten · Mini-Size ab ~100 $

Breites Netz + Fleet

Coverage

Watchlist auf hunderte Accounts/Tokens/Wallets skalieren (seltene Events → Volumen über Breite)
Verschiedene Bots = verschiedene Regel-Sets (A/B), fleet_correlation-Guard
Tool-Layer ausbauen (script/sub-agent) nur wenn die Zahlen es tragen

07 · Offen

Nächster Schritt: nenn mir 5–10 konkrete Accounts / Tokens / Wallets, dann baue ich zuerst das Event-Study-Rig und wir sehen schwarz auf weiß, ob der Edge da ist — bevor eine Zeile Live-Infrastruktur entsteht. Danach: on-chain oder social zuerst scharf?