RichardandClaude Opus 5
6218a04fe4
Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle. docs/ROADMAP.md (neu): - Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf. Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die Voraussetzung fuer die naechste. - Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern. - Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen, Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten. - Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag: CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen bauen statt doppelt. Archiv (docs/archiv/): - 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung). Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und Begruendungen - eingefroren ist nur ihr Status. - archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu. Verweise nachgezogen - der eigentliche Aufwand: - 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/. - 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene (csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen. - Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/, Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen. - Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen. PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap. Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
130 lines
8.5 KiB
Markdown
130 lines
8.5 KiB
Markdown
# Konzept: Eigenes datengetriebenes Trading-Modul („DataDriven")
|
||
|
||
> Stand: 2026-07-11
|
||
> Status: KONZEPT (noch kein Umsetzungsplan). Ziel: ein Strategiemodul, das eigene
|
||
> Handelsentscheidungen aus externen Datenquellen ableitet — je Marktkategorie eine
|
||
> eigene Datenquelle + ein eigenes Fair-Value-Modell. Die Datenanbindung wird so
|
||
> gebaut, dass das ResolutionFarming sie mitnutzen kann (State-aware-Filter, C-S2).
|
||
|
||
---
|
||
|
||
## 1. Grundidee
|
||
|
||
Alle bisherigen Module leiten Signale von ANDEREN ab (Master-Trades, Marktpreise).
|
||
DataDriven dreht das um: **Wir berechnen aus Rohdaten eine eigene faire
|
||
Wahrscheinlichkeit** und handeln nur, wenn der Marktpreis deutlich davon abweicht:
|
||
|
||
```
|
||
FairValue(Markt) aus Datenquelle → Vergleich mit Marktpreis (Bid/Ask)
|
||
→ |FairValue − Preis| > MinEdge (nach Fees) → Order (Maker bevorzugt) → Halten bis Resolution/Ziel
|
||
```
|
||
|
||
Der Edge kommt nicht aus Geschwindigkeit, sondern daraus, die **Daten besser/
|
||
konsequenter auszuwerten als der Durchschnitts-Teilnehmer** der jeweiligen Kategorie.
|
||
Deshalb ist die Kategorien-Wahl die wichtigste Entscheidung dieses Moduls.
|
||
|
||
## 2. Architektur (fügt sich in die bestehende Modul-Landschaft)
|
||
|
||
```
|
||
PolyTrader.Modules.DataDriven (IPolyTraderModule, DbPrefix dd_)
|
||
│
|
||
├── Core-Beitrag (geteilt, auch für ResolutionFarming nutzbar):
|
||
│ IMarketStateProvider // je Kategorie: liefert konservative
|
||
│ { // Wahrscheinlichkeits-Schätzung + Zustand
|
||
│ bool Supports(MarketData m);
|
||
│ Task<MarketStateEstimate?> EstimateAsync(MarketData m, CancellationToken ct);
|
||
│ }
|
||
│ record MarketStateEstimate(decimal ProbLowerBound, decimal ProbUpperBound,
|
||
│ string StateSummary, DateTime AsOf, string Source);
|
||
│
|
||
├── Provider (je Kategorie ein Adapter, einzeln aktivierbar):
|
||
│ WeatherStateProvider // Open-Meteo/NOAA-Modelläufe
|
||
│ SportsScoreStateProvider // Live-Scores (z. B. API-Football)
|
||
│ CryptoStrikeStateProvider // Binance-Spot + realisierte Volatilität
|
||
│ MacroStateProvider // Nowcasts/Konsensdaten (CPI, Zinsen)
|
||
│
|
||
├── Services:
|
||
│ DdScannerService // Märkte je aktiver Kategorie laden, FairValue
|
||
│ // berechnen, Kandidaten mit Edge persistieren
|
||
│ DdExecutionService // Sizing/Limits (Muster: FarmingRiskEngine/
|
||
│ // Planner wiederverwenden!), Maker-first
|
||
│ DdPositionMonitorService // Re-Evaluation offener Positionen: dreht der
|
||
│ // FairValue, wird der Exit geprüft (Leiter-Muster)
|
||
│
|
||
└── Persistenz: dd_settings / dd_candidates / dd_positions / dd_closed_trades
|
||
(Kopie des bewährten rf_-Schemas; Autoincrement-IDs, Kalibrierungs-Historie)
|
||
```
|
||
|
||
**Wichtige Wiederverwendung:** Risk-Engine, Execution-Planner, Fill-Modell,
|
||
Resolution-Monitor und UI-Aufbau des ResolutionFarming sind fast 1:1 übertragbar —
|
||
DataDriven ist strukturell „ResolutionFarming mit eigener Signalquelle statt
|
||
Preisband-Scan". Der Unterschied: DataDriven darf auch UNTER 0.90 kaufen (überall,
|
||
wo FairValue ≫ Preis) und optional vor der Resolution verkaufen, wenn der Edge
|
||
realisiert ist (Preis hat FairValue erreicht → Kapitalumschlag).
|
||
|
||
**ResolutionFarming-Synergie (C-S2):** Sobald ein `IMarketStateProvider` für eine
|
||
Kategorie existiert, nutzt ihn auch der RF-Scanner: Ein Preis-Dip wird nicht mehr
|
||
pauschal gemieden (Momentum-Filter), sondern gegen `ProbLowerBound` geprüft —
|
||
Richards 5:1-in-Minute-80-Beispiel wird damit zur Kaufgelegenheit statt zum Reject.
|
||
|
||
## 3. Kategorien-Bewertung: Wo lohnt sich ein eigenes Modell?
|
||
|
||
Bewertung nach: Datenlage (frei/billig verfügbar?), Modell-Komplexität,
|
||
Bot-Konkurrenz (Stand 2026), Fee-Satz, Kapitalbindung.
|
||
|
||
| Kategorie | Datenquelle (Kosten) | Modell | Bot-Konkurrenz | Fee | Bindung | Urteil |
|
||
|---|---|---|---|---|---|---|
|
||
| **Wetter (Tages-Märkte: Temperatur/Niederschlag je Stadt)** | Open-Meteo/NOAA/ECMWF-Läufe (kostenlos) | Modell-Konsens vs. Marktpreis; Update-Lag nutzen | **moderat, wachsend** — Edges von ~10 Pp (2023) auf ~3 Pp (2026) komprimiert, aber vorhanden; dünne Bücher, wenig Retail | 1,25 % | Stunden–Tage | ✅ **Bester Einstieg** |
|
||
| **Wetter (Saison: Hurrikane, Rekorde)** | wie oben + NHC | aufwendiger | gering (Kapital-Lockup schreckt ab) | 1,25 % | Wochen–Monate | ⚠️ später (Bindung) |
|
||
| **Sport pre-game (kleinere Ligen)** | API-Football o. ä. (~20–30 $/Mon.) | Elo-/Quotenvergleich vs. Buchmacher-Konsens | groß in Top-Ligen, **moderat in Nebenligen** | 0,75 % | Stunden–Tage | ✅ zweiter Kandidat |
|
||
| **Sport live (State-Provider)** | wie oben, Live-Scores | Score+Restzeit → P(Sieg), konservative Untergrenze | hoch (Latenz-Bots) — aber wir brauchen nur EINEN Fill unter FairValue, nicht den schnellsten | 0,75 % | Minuten–Stunden | ✅ als RF-Filter; als eigene Strategie nur eng begrenzt |
|
||
| **Krypto-Strikes (Wochen/Monat: „BTC über X am Y")** | Binance-WSS (kostenlos) | Distanz zum Strike + realisierte Vol → P | hoch bei 15-min/Stunde, **moderat bei Wochen-Strikes** | 1,8 % ⚠️ | Tage–Wochen | ⚠️ Fee frisst viel; nur bei großem Modell-Edge |
|
||
| **Makro (CPI, Zinsentscheide)** | Cleveland-Fed-Nowcast, Konsens-Schätzungen (frei) | Nowcast vs. Marktpreis | moderat, aber informierte Gegenseite | 1,5 % | Tage–Wochen | ⚠️ Nische, wenige Märkte |
|
||
| **Politik-Longtail (Nicht-Headline)** | Polls/Aggregatoren | Poll-Modell | gering im Long Tail | 1,0 % | Wochen+ | ⚠️ Bindung + Resolution-Risiko |
|
||
| **Kultur/Awards/Mentions** | Box-Office-Daten teils frei; sonst dünn | schwach | **gering** | 1,25–1,56 % | variabel | ❌ Resolution-Risiko (AI-Rater Pflicht), Datenlage schlecht |
|
||
| Krypto 15-min/1h Up-Down | Binance | Latenz | **extrem** (Sub-100-ms-Bots) | 1,8 % | Minuten | ❌ nicht unser Spiel |
|
||
|
||
**Antwort auf „nicht geflutete Kategorien":** Am wenigsten Bot-dominiert sind 2026
|
||
(a) **Wetter** — dünne Bücher, Nischenwissen (Stations-Regeln, Modell-Läufe), Retail
|
||
meidet die Kategorie; (b) **Long-Tail-/Nebenliga-Sport pre-game**; (c) **Makro-
|
||
Nischen** und (d) Long-Tail-Politik. Geflutet sind: Krypto-Kurzfrist, Top-Sport
|
||
in-play, Headline-Elections, Arbitrage/NegRisk-Rebalancing. Faustregel: Bots meiden
|
||
Kapitalbindung und Nischenwissen — genau dort liegt unser Fenster.
|
||
|
||
## 4. Empfohlener Aufbau-Pfad
|
||
|
||
1. **Phase DD-0:** `IMarketStateProvider`-Contract in Core + Modul-Skelett
|
||
(rf_-Schema kopieren). Kein Provider aktiv.
|
||
2. **Phase DD-1 (Wetter, read-only):** WeatherStateProvider (Open-Meteo, tägliche
|
||
Temperatur-Märkte 2–3 US-Städte). Scanner läuft wochenlang read-only:
|
||
FairValue vs. Marktpreis loggen → **misst den real verbliebenen Edge, bevor
|
||
irgendetwas gehandelt wird** (dasselbe Kalibrierungs-Gate-Prinzip wie RF).
|
||
3. **Phase DD-2:** Demo-Execution (Planner/Fill-Modell aus RF), 4 Wochen.
|
||
4. **Phase DD-3:** SportsScoreStateProvider — zuerst NUR als RF-Filter (C-S2:
|
||
Dip-Freigabe bei klarer Führung), erst danach als eigene DD-Strategie.
|
||
5. **Phase DD-4:** Live klein (eigener Account, wie bei RF), dann weitere Provider
|
||
nach gemessenem Edge.
|
||
|
||
## 5. Risiken dieses Moduls (ehrlich)
|
||
|
||
1. **Modell-Risiko ersetzt Master-Risiko:** Ein Bug/Bias im Fair-Value-Modell
|
||
produziert systematisch falsche Trades. Gegenmittel: read-only-Messphase je
|
||
Provider (DD-1-Prinzip), konservative Untergrenzen statt Punktschätzern.
|
||
2. **Edge-Kompression:** Der Wetter-Edge ist dokumentiert am Schrumpfen (10→3 Pp).
|
||
Read-only-Messung VOR jedem Livegang, und die Bereitschaft, eine Kategorie
|
||
wieder abzuschalten, wenn die Messung < MinEdge zeigt.
|
||
3. **Regel-Fallen:** Wetter-Märkte lösen nach exakten Stations-Regeln auf — der
|
||
AI-Auflösequalitäts-Rater (separater Plan) und das genaue Lesen der Regeln
|
||
je Markt-Serie sind Pflicht (welche Station, welche Rundung, welcher Zeitraum).
|
||
4. **Aufwand:** Jede Kategorie ist ein eigenes kleines Forschungsprojekt. Deshalb:
|
||
strikt eine Kategorie nach der anderen, jede mit eigenem Go/No-Go-Gate.
|
||
|
||
## 6. Quellen (Kategorien-/Konkurrenz-Einschätzung)
|
||
|
||
- Polymarket Weather/Climate-Kategorieübersichten (Volumen/Marktzahl):
|
||
https://polymarket.com/predictions/weather, https://polymarket.com/predictions/climate
|
||
- Weather-Bot-Funktionsweise & Edge-Kompression 2023→2026:
|
||
https://laikalabs.ai/prediction-markets/polymarket-weather-trading-bot
|
||
- Markt-Mikrostruktur/Tiefe Wetter-Märkte: https://polymart.app/blog/polymarket-weather-markets,
|
||
https://polymarkets.co.il/en/guide/weather-guide/
|