RichardandClaude Opus 4.8
c5f0b1d188
Root aufgeraeumt: alle Konzept-/Plan-/Fach-Dokumente nach docs/ verschoben, organisiert nach Typ (wie fuer ein separates Docs-Repo vorgeschlagen, aber bewusst in diesem Repo, damit Plan->umsetzende-Commits nachvollziehbar bleiben): - docs/konzepte/ (KONZEPT-*) - docs/umsetzungsplaene/ (UMSETZUNGSPLAN-*) - docs/ideen/ (fruehe Ideen, Platzhalter) - docs/pruefplaene/ (PRUEFPLAN-*) - docs/steuer/ (Steuer-/Buchhaltungs-Doks, z.B. US-CPA-Fragebogen) - docs/README.md (Index/Konventionen) Getrackte Plaene als Rename verschoben (History erhalten); zuvor untracked Konzept-/ Plan-Dateien jetzt versioniert. Co-Authored-By: Claude Opus 4.8 <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/
|