# Umsetzungsplan: Copytrading-Modul — Rentabilitäts-Verbesserungen

> Stand: 2026-07-06
> Ziel: Bekannte Verlustquellen im Copytrading-Modul beseitigen und die
> Rentabilität durch datengetriebene Trader-Auswahl, echte Fill-Daten und
> besseres SELL-Handling steigern.
> Reihenfolge: **Dieser Plan zuerst.** Phase 1 (Marktdaten-Fundament) ist
> Voraussetzung für die Strategiemodule MarketMaking und BundleArbitrage.

---

## 0. Kontext & Hintergrund (für die Umsetzung ohne Vorwissen)

Das Copytrading-Modul (`src/PolyTrader.Modules.CopyTrading/`) kopiert Trades von
Master-Tradern auf Polymarket. Signalkette:

1. `AlchemyWebsocketService` erkennt On-Chain-Events der Master-Wallets (WSS).
2. `TraderMonitorService.TriggerFastBlockchainPoll()` parst die Transaktion direkt
   (Fast Track, ~3–4 s hinter dem Master) oder fällt auf Data-API-Polling zurück.
3. Signale (`CopySignal`) laufen über einen Channel in die `CopyTradingEngine`.
4. Die Engine prüft Risiko-Limits (`CopyTradingAccountSettings`: PerMarketLimit,
   PerMasterLimit, Zeitfenster-Limits, MaxBuyPrice) und platziert CLOB-Orders
   über `PolymarketClobClient` (Core).

**Historischer Kontext (wichtig!):** Eine Verlustanalyse im April 2026
(`agentspace/prompts/AnalyzingOvernightTradingLosses.md`) hat als Hauptursache
für Overnight-Verluste identifiziert, dass der Bot SELLs der Master mit
Market-Orders ins leergeräumte Orderbuch kopiert und so zur „Exit-Liquidity"
wird (Beispiel: Entry 0.51, Master-Exit 0.99, unser Exit 0.49). Der damalige
Fix (GTD-Limit-Sells) ist **im aktuellen Modul-Code nicht mehr vorhanden** —
vermutlich bei der Modularisierung verloren gegangen.

**Seit März 2026 erhebt Polymarket Taker-Fees** (Sports ~0,75 %, Politik/Finanzen
~1,0 %, Krypto ~1,8 %, am 50-¢-Preis am höchsten, Richtung 1 ¢/99 ¢ abnehmend;
Maker zahlen nichts und erhalten Rebates). Der Bot ist heute fast immer Taker.
Quelle: https://docs.polymarket.com/trading/fees — **bei Umsetzung aktuellen
Stand verifizieren.**

### Leitplanken (gelten für alle Phasen)

1. `.agents/rules/clob.md` beachten: Änderungen an der CLOB-Integration sind
   hochkritisch. Vor jeder Änderung Backup/Commit der alten Version, jede
   Änderung mehrfach prüfen.
2. Jede Phase lässt die App baubar und lauffähig zurück (Debug-Build grün).
3. Entscheidungslogik als testbare, pure Funktionen extrahieren und in
   `PolyTrader.Tests` (xUnit, existiert bereits) abdecken.
4. Kein Livegang einer Phase ohne mehrtägige Beobachtung auf dem Server.

---

## Phase 0 — Sofortmaßnahmen: Blutung stoppen

### 0.1 🔴 SELL-Exit-Liquidity-Regression beheben (höchste Priorität)

**Befund:** In `CopyTradingEngine.cs` (Live-SELL-Pfad, aktuell ~Zeile 694–735)
werden SELLs als `"MARKET"` mit Fallback-Limit `0.01m` gesendet:

```csharp
decimal sellLimit = 0.01m; // Market Order Fallback Limit
...
var result = await _clob.PlaceOrderAsync(account, signal.TokenId, signal.Side,
    expectedUsdc, sellLimit, "MARKET", _state.DebugOrderPayloadLog, isNegRisk);
```

Das ist exakt das Verhalten, das die April-Verluste verursacht hat.

**Ziel-Design: Eskalationsleiter statt Market-Order**

1. Referenzpreis = `signal.Price` (Exit-Preis des Masters).
2. Erste Order: GTD-Limit.
   - HF-Trader (`trader.Category == "HF"`): `signal.Price - 0.005m`.
   - Sonst: `signal.Price * (1 - settings.MaxPriceDifference / 100m)`.
3. Neuer Setting-Wert `SellFloorPct` in `CopyTradingAccountSettings`
   (Default z. B. 15 %): absolute Untergrenze = `signal.Price * (1 - SellFloorPct/100)`.
4. Hintergrund-Loop (Erweiterung von `CleanupStaleOpenOrdersAsync` in
   `TraderMonitorService` oder eigener Loop): Order nach T Sekunden ohne Fill
   (HF: ~20 s, sonst: ~120 s) canceln und eine Stufe tiefer neu platzieren
   (Schrittweite z. B. 2 ¢ oder 3 % relativ), bis zum Floor.
5. Floor erreicht und kein Fill → Position halten, **Threema-Benachrichtigung**
   senden (`ThreemaService` im Core existiert) und Position als „ExitPending"
   markieren.
6. Position darf **nicht mehr optimistisch** aus `account.OpenPositions`
   entfernt werden. Stattdessen Flag `ExitPending` (neues Property auf
   `Position` oder Tracking-Dictionary im `CopyTradingState`), damit Limits
   weiterhin korrekt rechnen und kein Doppel-SELL entsteht. Entfernen erst,
   wenn der Fill über Sync/User-Channel (Phase 1) bestätigt ist.

**Preis-/Stufenlogik als pure statische Funktion** implementieren (z. B.
`SellLadder.NextPrice(referencePrice, step, floor, attempt)`) und mit
Unit-Tests abdecken.

**Akzeptanzkriterien:**
- Kein Code-Pfad sendet mehr `"MARKET"`-SELLs mit 0.01-Limit.
- Unit-Tests für Ladder-Preise (HF/normal, Floor-Clamping, 0.01/0.99-Grenzen).
- Log zeigt pro SELL: Referenzpreis, gewähltes Limit, Stufe.

### 0.2 Fee-Modell einführen

1. Fee-Rate je Markt beschaffen: Die CLOB-/Gamma-API liefert Fee-Informationen
   am Markt-Objekt (Feldname bei Umsetzung anhand
   https://docs.polymarket.com/trading/fees verifizieren, z. B. `fee_rate_bps`).
   Fallback: statische Kategorie-Tabelle (Sports 0.75 %, Politics/Finance 1.0 %,
   Crypto 1.8 %, Geopolitics 0 %).
2. `MarketData` (Core) um `TakerFeeBps` erweitern (EF-Migration Core),
   Befüllung über `MarketSyncService` bzw. beim Markt-Fetch.
3. Risk-Check in `CopyTradingEngine`: erwartete Fee vom verfügbaren Edge
   abziehen; Mikro-Trades, deren Fee den erwartbaren Gewinn frisst, verwerfen
   (Logging mit Begründung wie bei den bestehenden Checks).
4. PnL-Berechnung (Demo **und** Live-Anzeige) um Fees korrigieren.

**Akzeptanz:** Fee erscheint im TradeReasoning-Log jedes BUY; Demo-PnL weist
Fees aus.

### 0.3 `ProfitTarget` implementieren oder entfernen

`CopyTradingAccountSettings.ProfitTarget` (Default 50.0) existiert in Settings,
DB und UI, wird aber **nirgends ausgewertet** (toter Knopf).

**Empfehlung: implementieren** als optionaler Take-Profit:
- Semantik: `0` = deaktiviert; sonst Prozent-Gewinnschwelle.
- Prüfung im 30-s-Live-Sync (`PollLiveAccountsAsync`): wenn
  `CurrentPrice >= EntryPrice * (1 + ProfitTarget/100)` → Verkauf über die
  Eskalationsleiter aus 0.1 (Startlimit = CurrentPrice), ExitReason
  `"Profit Target"`.
- Zusammenspiel mit `PreRedeemLimit` beachten (beide können feuern —
  PreRedeem hat Vorrang, da näher an 1.00).

### 0.4 Kleinere Konsistenz-Fixes

1. **20-Sekunden-Spam-Blockade** (`PendingOrderTimestamps`-Check am Anfang des
   SELL-Pfads): blockiert aktuell auch legitime SELLs, wenn der Master < 20 s
   nach dem Kauf aussteigt. Fix: Blockade nur für gleichgerichtete Orders
   (BUY nach BUY), SELL nach BUY zulassen.
2. **`_state.GlobalPnl`**: wird in `PollLiveAccountsAsync`-Close-Pfaden addiert,
   in `PollClosedAccountsAsync` nicht → Anzeige driftet. Vereinheitlichen.
3. **Demo-`ClosedTrade` ohne `TokenId`**: Im Demo-SELL-Pfad wird `TokenId` nicht
   gesetzt (Preload von `_processedClosures` filtert auf `TokenId`). Setzen.

---

## Phase 1 — Marktdaten-Fundament (Core-Infrastruktur)

> Diese Phase gehört in **PolyTrader.Core** (`src/PolyTrader.Core/Streaming/`),
> nicht ins Modul — MarketMaking- und BundleArbitrage-Modul (separate Pläne)
> setzen sie voraus.

### 1.1 CLOB User-Channel (echte Fills in Echtzeit)

Polymarket bietet einen authentifizierten WSS-User-Channel, der Order-Events
(Platzierung, Teil-/Voll-Fill, Cancel) der eigenen Accounts pusht.
Endpoint/Protokoll bei Umsetzung verifizieren:
https://docs.polymarket.com (CLOB WSS, `user` channel; Auth via API-Key/
Secret/Passphrase — liegen je Account in `AccountState`).

Neuer Core-Service `ClobUserChannelService : BackgroundService`:
- Verbindet pro Live-Account, Auto-Reconnect mit Backoff (Muster von
  `AlchemyWssClient` übernehmen).
- Publiziert Fill-Events intern (Event oder Channel), z. B.
  `record OrderFillEvent(int AccountId, string TokenId, string OrderId, string Side, decimal Price, decimal Size, DateTime Ts)`.

Konsumenten im Copytrading-Modul:
- `Position.EntryPrice`/`Size` mit **echten Fill-Daten** aktualisieren
  (heute: Limit-Preis als EntryPrice, Korrektur erst im 30-s-REST-Sync).
- SELL-Eskalationsleiter (Phase 0.1): Fill-Bestätigung beendet die Leiter.
- Neue Tabelle `ct_fill_log` (EF-Migration im Modul): SignalPrice, OrderPrice,
  FillPrice, Latenz (Signal→Fill in ms), TraderId, AccountId, TokenId, Side.
  → Grundlage für Slippage-Statistik in Phase 3.

### 1.2 CLOB Market-Channel (Orderbücher live)

Neuer Core-Service `ClobMarketDataService`:
- Abonniert den öffentlichen `market`-Channel für eine dynamische Token-Liste
  (Subscribe/Unsubscribe zur Laufzeit).
- Hält `OrderBookCache` (Best-Bid/Ask, Tiefe der obersten N Level, Timestamp).
- Interface für Konsumenten: `IOrderBookProvider.TryGetBook(tokenId, maxAgeMs)`.
- REST-Fallback `GET /book` über `PolymarketClobClient`, wenn kein Stream aktiv.

**Hinweis:** Im Modul existiert bereits ein `PolymarketWssClient` (Auto-Redeem).
Nicht verschieben/umbauen (Regression-Risiko), sondern den neuen Core-Service
parallel aufbauen; spätere Konsolidierung als separater Schritt.

### 1.3 Pre-Trade-Orderbuch-Check in der Engine

Vor jedem Live-BUY in `CopyTradingEngine.ProcessAccountOrderAsync`:
1. Buch holen (`IOrderBookProvider`, Fallback REST, Timeout ~150 ms —
   bei Timeout Verhalten wie heute, nicht blockieren).
2. Checks (neue Settings in `CopyTradingAccountSettings`):
   - `MaxSpreadPct` (Default z. B. 5 %): Spread größer → Skip mit Log.
   - Tiefen-Check: liegt an unserem Limit-Preis genug Ask-Size für
     `exactShares`? Wenn nein → Skip („Sniping-Verdacht: Liquidität bereits
     konsumiert") statt teuer ins dünne Buch zu laufen.

**Akzeptanz Phase 1:** Fill-Log füllt sich mit echten Fills; TradeReasoning
zeigt Spread/Tiefe-Entscheidungen; kein messbarer Latenz-Nachteil im Hot-Path
(> 200 ms Zusatz wäre Regression).

---

## Phase 2 — SELL-Verfeinerung: Proportionalität

Heute (Proportionalitätsfilter in `CopyTradingEngine`, SELL-Pre-Flight):
verkauft der Master < 30 % seines Bestands → ignorieren; ≥ 30 % → **wir
verkaufen alles**. Information über gestaffelte Exits geht verloren.

**Ziel:** Verkaufsquote spiegeln.
1. Beim Öffnen einer Position den Master-Bestand zum Einstiegszeitpunkt
   festhalten (`MasterSharesAtEntry`, im `CopyTradingState.MasterTraderPositions`
   bzw. auf der Position persistieren).
2. Bei SELL-Signal: `sellRatio = signal.Size / masterSharesVorVerkauf` (wie
   heute berechnet). Statt Voll-Exit: `sharesToSell = ourShares * sellRatio`.
3. Untergrenzen beachten: bleibt danach < Polymarket-Minimum (5–6 Shares) übrig
   → Voll-Exit statt Rest-Dust.
4. Kleiner Teilverkauf (< 10 %) weiterhin ignorieren (Rauschen von Day-Tradern),
   Schwelle konfigurierbar (`MinSellRatioPct`).
5. Verkauf läuft immer über die Eskalationsleiter aus Phase 0.1.

Akzeptanz: Unit-Tests für die Ratio-Logik inkl. Dust-Grenzen; Logs zeigen
„Teilverkauf x % gespiegelt".

---

## Phase 3 — Trader-Intelligence (Auswahl automatisieren)

> Beim Copytrading entscheidet die Master-Auswahl über den Großteil des
> Ergebnisses. Diese Phase macht sie messbar und selbstkorrigierend.

### 3.1 Copy-PnL-Score („Kopierbarkeit")

Der `MasterTraderAnalyticsJob` misst heute den PnL des **Masters**. Relevanter
ist, was **wir** mit ihm verdient haben — inkl. unserer Slippage und Fees.

1. Neue Kennzahlen je Master aus `ct_`-Closed-Trades (`ICopyTradeLogRepository`,
   Filter `SourceTraderId`, letzte 30 Tage):
   - `CopyPnl30d`, `CopyProfitFactor` (Bruttogewinn/Bruttoverlust),
     `CopyAvgPnlPerTrade`, `CopyTradeCount30d`.
   - `AvgSlippagePct` aus `ct_fill_log` (Phase 1.1): Ø(FillPrice−SignalPrice)/SignalPrice.
2. Felder auf `TrackedTrader` ergänzen (+ EF-Migration `mod_copytrading_trackers`),
   Berechnung im `MasterTraderAnalyticsJob`, Anzeige in `MastersTradersView`.
3. **Achtung Metrik-Falle:** Winrate allein ist irreführend (Favoriten-Käufer
   haben 95 % Winrate und können trotzdem negativ sein). Profit-Faktor und
   Ø-PnL/Trade als primäre Sortierung in der UI.

### 3.2 Sniper-/Verhaltens-Metriken in den Analytics-Job

Portierung der Logik aus `analyze_snipers.py` (liegt im Projektroot) nach C#
in den `MasterTraderAnalyticsJob`:
1. Data-API-Activity je Master über volle 3 Tage paginieren (das Skript zeigt
   das Pagination-Muster; API-Limit je Request beachten).
2. Kennzahlen: `MedianHoldMinutes`, `SellWithin5MinPct` (Anteil SELLs < 5 min
   nach zugehörigem BUY), `SellCount3d`.
3. Schwellen (konfigurierbar): `SellWithin5MinPct > 50 %` → Master als Sniper
   flaggen: Warn-Status in UI + Threema-Hinweis. Optional Auto-Pause (siehe 3.3).

### 3.3 Automatischer Kill-Switch je Master

Neue Modul-Settings (global, z. B. in `CopyTradingState` + Persistenz):
`AutoPauseEnabled`, `AutoPauseMinTrades` (z. B. 10), `AutoPauseDrawdownUsd`
oder `-Pct`.

Regel im Analytics-Job (läuft 2×/Tag — zusätzlich stündlicher Light-Check
sinnvoll): Copy-PnL der letzten N Trades unter Schwelle → `IsActive = false`,
`Reasoning` mit Begründung + Zeitstempel befüllen, Threema-Notification.
Reaktivierung bewusst nur manuell.

**Akzeptanz Phase 3:** UI zeigt Copy-Score-Spalten; ein simulierter
Verlust-Master wird automatisch pausiert (Test mit Demo-Daten).

---

## Phase 4 — Maker-Mode & Demo-Realismus

### 4.1 Maker-Einstieg für langsame Master

Für Master mit Haltedauern von Stunden/Tagen (SwissTony/RN1-Typ) ist der
3-Sekunden-Taker-Fill unnötig teuer (Fees + Spread). Neues Verhalten
(Flag je Trader, z. B. `Category == "HOLDER"` oder eigenes Bool `MakerEntry`):
1. BUY als GTC-Limit **auf** Best-Bid (oder Mid − 1 Tick) statt über dem Ask.
2. Kein Fill nach T Minuten (konfigurierbar, z. B. 10) und Signal-Markt noch
   im Preisband → auf Taker-Verhalten eskalieren oder verwerfen (Setting).
3. Fees: Maker zahlt 0 und sammelt ggf. Rebates — im Fee-Modell (0.2) abbilden.

### 4.2 Demo-Modus realistisch machen

Demo füllt heute zum Signalpreis ohne Slippage/Fees → Demo-Ergebnisse sind
systematisch geschönt und als Validierung neuer Master unbrauchbar.

Fill-Modell im Demo-Pfad der Engine:
`FillPreis = Signalpreis + halber Spread (aus IOrderBookProvider, Fallback
+1 ¢) `, Fee der Marktkategorie abziehen, beides im `ClosedTrade` ausweisen.

**Akzeptanz:** Demo- und Live-PnL desselben Masters weichen über 2 Wochen um
< 20 % relativ ab (grobe Plausibilität statt heutiger Systematik-Lücke).

---

## Offene Entscheidungen (vor Umsetzung mit Richard klären)

1. `SellFloorPct`-Default und Stufen-Timing der Eskalationsleiter (0.1).
2. `ProfitTarget`: implementieren (Empfehlung) oder Feld entfernen?
3. Auto-Pause: nur benachrichtigen oder hart deaktivieren? (Empfehlung: hart,
   nachts passiert sonst genau das Falsche.)
4. Maker-Mode: als Trader-Flag oder automatisch aus `MedianHoldMinutes`
   ableiten? (Empfehlung: automatisch ab z. B. Median > 60 min, manuell
   überschreibbar.)

## Reihenfolge & Abhängigkeiten

```
Phase 0 (sofort, unabhängig)
   └── Phase 1 (Core-Infra; parallel zu 0 möglich, Livegang nach 0)
         ├── Phase 2 (braucht 0.1-Leiter)
         ├── Phase 3 (braucht 1.1-Fill-Log für Slippage; Rest unabhängig)
         └── Phase 4 (braucht 1.2-Orderbuch)
```