Richard/PolyTraderSharp
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Docs: Konzepte/Plaene in docs/ mit Typ-Unterordnern buendeln

Browse Source 
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>
This commit is contained in:
Richard
2026-07-14 10:15:08 +02:00
co-authored by Claude Opus 4.8
parent 1c3a364df2
commit c5f0b1d188
15 changed files with 1004 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/konzepte/KONZEPT-Modul-Accounting.md
+255
View File
@@ -0,0 +1,255 @@
# Konzept: Modul „Accounting" (Steuer-/Buchhaltungs-Reporting aller Live-Accounts)
> Stand: 2026-07-14
> Ziel: Vollständige, **unabhängig von unserer Trading-DB** erhobene, buchhalterisch korrekte
> Erfassung ALLER Transaktionen aller Live-Polymarket-Accounts. Periodische (meist monatliche),
> vor einer Steuerbehörde nachvollziehbare Abrechnungen — je einzelnem Account ODER über alle
> Accounts, für frei wählbare Zeiträume. BWA-artige Kennzahlen-Übersicht in der UI. Export als
> CSV und PDF.
> Reihenfolge: unabhängig, jederzeit baubar (kein Live-Trading nötig — rein lesende API-Abrufe).
> **Kein Handel; reines Ingest-/Reporting-Modul.**
>
> **Entscheidungen Richard (2026-07-14):**
> - Währung: **USDC nativ + USD + EUR** (jede Transaktion in allen drei ausgewiesen).
> - Abrechnung: neutrale prüfbare Aufstellung **UND** konkrete **US-Steuerberechnung** — Zielland
> **USA, Florida LLC** (Florida ohne State Income Tax → nur Federal). Als dokumentierte, vom CPA
> prüfbare Rechenschicht, **nicht als Steuerberatung** (Disclaimer, §4a).
> - Umfang v1: **inkl. On-Chain-Ein-/Auszahlungen** von Anfang an (vollständige Kapitalsicht).
---
## 0. Leitprinzipien
1. **Unabhängige Quelle = Polymarket, NICHT unsere DB.** Das Modul erhebt die Buchungsgrundlage
ausschließlich über eigene, regelmäßige Abrufe direkt bei Polymarket und speichert sie roh +
normalisiert in eigenen Tabellen. Unsere eigenen Trade-Logs (Copytrading/ResolutionFarming/Core)
werden **nur** für den optionalen Abgleich (§7) herangezogen, **nie** als Buchungsgrundlage.
2. **Nachvollziehbarkeit / Audit.** Jeder Buchungssatz führt auf einen konkreten, prüfbaren Nachweis
zurück (Transaktions-Hash, Activity-/Trade-ID, Abruf-Zeitpunkt, Rohdaten-Snapshot). Der Roh-Ingest
ist **unveränderlich (append-only)**; Abrechnungen sind daraus **reproduzierbar** ableitbar.
3. **Zwei Ebenen: neutraler Ledger + prüfbare US-Steuerschicht.** Unten liegt eine vollständige,
länderneutrale Transaktions-/Ledger-Aufstellung + Kennzahlen (belastbare Basis). Darauf setzt eine
**konfigurierbare, dokumentierte US-Steuer-Rechenschicht** (Florida LLC, §4a) — mit klaren, im
Export ausgewiesenen Annahmen, **die der US-CPA prüft/bestätigt**. Das Tool rechnet; es berät nicht
(Disclaimer, §4a). Der neutrale Ledger bleibt auch bei anderer steuerlicher Einordnung gültig.
4. **Lesend / idempotent.** Keine Orders, keine On-Chain-Writes. Überlappende Wiederholungs-Abrufe
dürfen **nichts doppelt buchen** (stabile Idempotenz-Schlüssel, Upsert statt Insert).
---
## 1. Architektur-Einbettung
Neues Projekt `src/PolyTrader.Modules.Accounting/` als `IPolyTraderModule`
(`Name = "Accounting"`, `DbPrefix = "acc_"`), Registrierung in `Program.cs`. Referenziert nur den
Core. Eigener `AccountingDbContext` (acc_-Tabellen), eigene UI (ein Fenster mit Tabs), eigene
Settings-Sektion.
- Nutzt den bestehenden `PolymarketApiService` (Data-API `/activity`, `/positions`,
`GetUsdcBalanceAsync(wallet)`) und für On-Chain-Ein-/Auszahlungen die vorhandene Alchemy-Anbindung.
- Betrifft ALLE Live-Accounts (aus `TradingState.Accounts` bzw. `IAccountRepository`; `!IsDemo`,
mit gesetzter `WalletAddress`).
- **Hinweis Ist-Stand:** `PolymarketApiService.GetTraderActivityAsync` filtert heute hart auf
`type=TRADE`. Fürs Accounting brauchen wir ALLE Activity-Typen → entweder den Filter parametrisieren
oder eine eigene, accounting-spezifische Abruf-Methode (schlanker, ohne Copytrading-Annahmen).
---
## 2. Datenbeschaffung (der Kern: der unabhängige Abruf)
### 2.1 Ledger-Quellen bei Polymarket
- **Data-API `/activity?user=<wallet>`** = primäres Kontobuch. Enthält (Feldnamen/Typen bei Umsetzung
zwingend aus https://docs.polymarket.com verifizieren) u. a.:
- `TRADE` (BUY/SELL-Fills): Preis, Size, USDC, Fee, Token/Market, txHash, Timestamp, Side.
- `REDEEM` (Resolution-Auszahlung: Gewinner-Shares → USDC).
- `SPLIT` / `MERGE` / `CONVERSION` (CTF-/NegRisk-Operationen; meist geldneutral, aber bestandsrelevant).
- `REWARD` (Liquidity Rewards) / Maker-Rebates — Einnahmen.
- **On-Chain USDC-Ein-/Auszahlungen** (Deposits/Withdrawals ins/aus dem Wallet): sind **nicht** Teil
der Trading-Activity. Quelle: Polygon/Alchemy (ERC-20-Transfer-Logs USDC ↔ Wallet).
- **Adresse ist vorhanden:** Polymarket nutzt **Gnosis-Safe-Proxy-Wallets** — genau die Adresse, die
wir bereits als `AccountState.WalletAddress` für Balance- und Activity-Abrufe verwenden. Sie ist
also die Watch-Adresse für USDC-Transfers (keine zusätzliche Beschaffung nötig).
- **Die eigentliche Arbeit ist die Klassifikation:** Die USDC-Transfers des Safes enthalten SOWOHL
trading-interne Bewegungen (Safe ↔ Polymarket-Contracts: CTF/Exchange/NegRisk — bereits in `/activity`
als Trades/Redeems erfasst) ALS AUCH echte Ein-/Auszahlungen (Safe ↔ EXTERNE Adressen). Nur letztere
sind Deposits/Withdrawals. Klassifikation über eine **Whitelist der Polymarket-System-Contracts**
(die CTF-Adresse `0x4D97…6045` liegt bereits im Code — Exchange/NegRisk-Adapter/USDC ergänzen, aus
docs verifizieren). Alternativ als Kreuzprobe: ΔSafe-Balance − Σ(interne Activity) = externe Netto-Ein-/Auszahlung.
- ⚠️ Gnosis-Safe-Nuance: Transfers laufen ggf. als Safe-`execTransaction`; die ERC-20-Transfer-Logs
(from/to = Safe) bleiben aber die maßgebliche, prüfbare Quelle.
- **Balance-Anker**: `GetUsdcBalanceAsync(wallet)` je Abruf als Kontrollpunkt (End-Saldo Soll-Ist).
### 2.2 Vollständigkeit & Idempotenz
- **Backfill + Inkrementell**: Erstlauf lädt die volle Historie je Account (paginiert, `offset`/`limit`;
Rate-Limits beachten — Activity 1000/10 s, Positions 150/10 s, bereits im ApiService limitiert).
Danach nur neue Ereignisse ab dem letzten bekannten Zeitpunkt, mit Sicherheits-**Lookback-Überlappung**
gegen API-Lag.
- **Idempotenz-Schlüssel** je Buchungssatz: stabile Kombination `txHash + logIndex/assetId + type`
→ überlappende Abrufe buchen nicht doppelt (Unique-Constraint + Upsert).
- **Lückenerkennung**: Timestamp-Kontinuität + Seiten-Vollständigkeit prüfen; fehlende Bereiche gezielt
nachladen und markieren.
- **Rohdaten-Snapshot**: die JSON-Rohantwort je Abruf-Batch speichern (Nachweis + Reproduzierbarkeit),
zusätzlich zu den normalisierten Sätzen.
### 2.3 Abruf-Steuerung
- `AccountingIngestJob : BackgroundService` (JobManager-registriert, manuell triggerbar), Intervall
konfigurierbar (z. B. stündlich inkrementell, täglich Voll-Reconcile). Nutzt die bestehenden
Rate-Limiter des `PolymarketApiService`.
---
## 3. Persistenz (acc_-Tabellen, append-only Ledger)
| Tabelle | Inhalt |
|---|---|
| `acc_ledger` | Normalisierte, **unveränderliche** Buchungssätze: AccountId, EventType (TRADE_BUY/TRADE_SELL/REDEEM/REWARD/FEE/SPLIT/MERGE/DEPOSIT/WITHDRAWAL), Timestamp, TokenId/Market, Outcome, Size, PriceUsdc, GrossUsdc, FeeUsdc, NetUsdc, TxHash, LogIndex, Source, IngestBatchId, **IdempotencyKey (unique)** |
| `acc_ingest_runs` | Abruf-Protokoll: AccountId, Von/Bis, Start/Ende, #Sätze, Ok/Fehler, Balance-Anker (Soll-Ist) |
| `acc_raw` | Rohdaten-Snapshots (JSON) je Batch (Nachweis) |
| `acc_fx_rates` | (falls Fiat, §10.1) amtliche Tages-FX-Kurse (z. B. USD→EUR) je Datum |
| `acc_statements` (optional) | Erzeugte Periodenabrechnungen (Metadaten + Daten-Hash) für Versionierung/Reproduzierbarkeit |
Autoincrement-PKs (Lehre aus dem CopyTrading-`TradeId`-Problem), Unique-Index auf `IdempotencyKey`,
Indizes auf `(AccountId, Timestamp)`.
---
## 4. Buchhaltungs-Logik (pure, testbar) — `AccountingEngine`
Wie bei den anderen Modulen liegt die geldkritische Logik pur und unit-getestet in `Logic/`:
- **Klassifikation** roher Activity → Buchungssatz-Typ + Vorzeichen (Einnahme/Ausgabe). Rein/testbar.
- **Periodenabrechnung** (Zeitraum × Account bzw. alle): aggregiert die Ledger-Sätze zu:
Anfangssaldo, Einlagen, Entnahmen, Handelsvolumen, realisierte Gewinne/Verluste, Fees, Rewards,
Netto-Ergebnis, Endsaldo — mit **Soll-Ist gegen den Balance-Anker** (Abweichung = Vollständigkeits-Signal).
- **Realisierung / Kostenbasis**: Gewinn/Verlust wird bei SELL/REDEEM realisiert; Kostenbasis je
Position per **FIFO** (US-Norm für Krypto/Property; Specific-ID als Option, §10.5) — Lot-Matching der
BUYs zu jeder Veräußerung, inkl. Haltefristen (short/long term). Pure/testbar. Offene Positionen zum
Periodenende optional als **Mark-to-Market** ausweisen, aber getrennt vom realisierten Ergebnis.
- **Währung/FX**: jede Transaktion in **USDC (nativ), USD und EUR**. Umrechnung je Transaktionsdatum:
USDC→USD (Stablecoin, Annahme 1:1 als USD-Äquivalent — im Export dokumentiert; realer USDC/USD-Kurs
optional) und USD→EUR über amtliche Tageskurse (EZB), versioniert in `acc_fx_rates`.
---
## 4a. US-Steuer-Rechenschicht (Florida LLC) — konfigurierbar, CPA-prüfbar
> ⚠️ **Kein Steuerrat.** Diese Schicht rechnet Zahlen nach **dokumentierten, konfigurierbaren
> Annahmen** aus und weist diese im Export offen aus. Die steuerliche Einordnung von
> Prediction-Market-/Event-Contract-Erträgen in den USA ist **nicht eindeutig geklärt**. Der Output
> ist zur **Prüfung/Bestätigung durch einen US-CPA/Steuerberater** gedacht, nicht als endgültige
> Steuererklärung. Jede Annahme ist im PDF/CSV dokumentiert und in den Settings umstellbar.
**Rahmen (Defaults, alle in Settings umstellbar):**
- **Entität:** Florida LLC. Florida erhebt **keine State Income Tax** → nur **Federal**. LLC-Typ
(single-member = disregarded → Schedule C/D im 1040; vs. multi-member = Partnership 1065 + K-1)
bestimmt nur die Ziel-Formulare, **nicht** die Gewinnermittlung (§10.7).
- **Einordnung (Default-Annahme):** jede Position = **Property-Disposition** → realisierter Gewinn/
Verlust je Veräußerung (SELL/REDEEM) im **Form-8949/Schedule-D-Stil**: Proceeds (USD), Cost Basis
(USD), Holding Period (short/long), Gain/Loss. Alternative Einordnungen (ordinary income, gambling,
§1256) als umstellbare Annahme vorgesehen — Auswahl trifft der CPA (§10.4).
- **USDC:** als **USD-Äquivalent (1:1)** behandelt; USDC-Käufe/-Verkäufe gelten nicht separat als
steuerbares Krypto-Event (dokumentierte Vereinfachung; abschaltbar).
- **Kostenbasis:** **FIFO** (Default) oder Specific-ID; Lot-genau, mit Haltefristen.
- **Wash-Sale:** Default-Annahme „nicht anwendbar" auf Event-Contracts/Krypto (Stand 2026) — als
Schalter, da Rechtslage im Fluss.
**Output der Steuerschicht:**
- **Form-8949-artige Veräußerungsliste** je Account/Zeitraum (Description, Acquired, Sold, Proceeds,
Cost Basis, Gain/Loss, Short/Long) — CSV + PDF.
- **Schedule-D-artige Zusammenfassung** (kurz-/langfristig, Summen) je Account und aggregiert über die LLC.
- Vollständige **Methodik-/Annahmen-Seite** im Export (Reproduzierbarkeit + Prüfbarkeit).
Die Rechenlogik (FIFO-Lot-Matching, Haltefrist, Gain/Loss, FX-Umrechnung je Datum) liegt **pur und
unit-getestet** in `Logic/` (z. B. `UsTaxEngine`), getrennt vom neutralen Ledger.
---
## 5. UI (WinForms, ein Fenster mit Tabs — Muster wie ResolutionFarming)
- **Übersicht / BWA**: Kennzahlen-Kacheln für den gewählten Zeitraum + Account(s): Netto-Ergebnis,
Handelsvolumen, Fees, Rewards, Einlagen/Entnahmen, Endsaldo, realisiert vs. offen; Monats-/Perioden-Vergleich.
- **Ledger**: filterbare Transaktionsliste inkl. Nachweisspalten (txHash etc.).
- **Steuer (US)**: Form-8949-artige Veräußerungsliste + Schedule-D-Zusammenfassung je Account/alle,
mit ausgewiesenen Annahmen (FIFO, Einordnung, USDC=USD). Werte in USD (und EUR).
- **Abrechnungen / Export**: Zeitraum-Picker (Monats-Presets + frei), Account-Auswahl (einzeln / alle),
Währungswahl (USDC/USD/EUR), Buttons „CSV" und „PDF".
- **Abruf / Status**: Ingest-Läufe, Vollständigkeits-/Lücken-Status, Balance-Soll-Ist, manueller Trigger.
---
## 6. Export (CSV + PDF)
- **CSV**: vollständiger Ledger + Aggregat je Abrechnung (maschinen-/prüfbar).
- **PDF**: formatierte Abrechnung — Kopf (Account, Wallet, Zeitraum, Erstellungsdatum), Aggregat-Tabelle,
Transaktionsliste, Methodik-/Nachweis-Hinweis. Library **PDFsharp/MigraDoc (MIT)** — echte,
bedingungslose MIT-Lizenz ohne Umsatzschwelle; MigraDoc eignet sich für tabellarische
Abrechnungen/Berichte. (QuestPDF bewusst NICHT: dessen „Community"-Lizenz ist kostenlos nur unter
1 Mio USD Jahresumsatz — für eine handelnde LLC ein Lizenzrisiko. Siehe §10.1.)
- **Reproduzierbarkeit**: jeder Export trägt Zeitraum, Datenstand (letzter Ingest), Zeilenzahl und einen
Daten-Hash → gleiche Eingabe ⇒ identische Abrechnung (wichtig für die Prüfbarkeit).
---
## 7. Abgleich mit eigener Trade-DB (niedrige Priorität)
Gegenüberstellung Polymarket-Ledger ↔ unsere Modul-/Core-Trade-Logs je Account/Zeitraum: fehlende/
zusätzliche Trades, Preis-/Size-/Fee-Abweichungen, PnL-Differenzen. Rein analytisch — findet
Sync-/Buchungsfehler unserer Trading-Seite. Bericht in der UI + Export.
---
## 8. Phasen & Akzeptanzkriterien
- **A-1 Ingest (read-only), inkl. Ein-/Auszahlungen:** Modul + acc_-Persistenz + Activity-Ingest
(ALLE Typen) + On-Chain-USDC-Deposits/Withdrawals + Backfill/Inkrement + Idempotenz + Ingest-Status-UI.
**Akzeptanz:** volle Historie eines Live-Accounts vollständig & doppelfrei; Balance-Anker Soll-Ist ≈ 0
(inkl. Ein-/Auszahlungen).
- **A-2 Abrechnung + Übersicht + FX:** `AccountingEngine` + BWA-UI + Periodenabrechnung je Account/alle,
Werte in USDC/USD/EUR (Tageskurse in `acc_fx_rates`). **Akzeptanz:** Monatsabrechnung stimmt gegen
Balance-Anker; Kennzahlen plausibel; FX nachvollziehbar.
- **A-3 US-Steuerschicht:** `UsTaxEngine` (FIFO-Lot-Matching, Haltefristen, Gain/Loss) + Form-8949-/
Schedule-D-Ansicht + Annahmen-Dokumentation. **Akzeptanz:** Summe realisierter Gain/Loss stimmt gegen
die neutrale Abrechnung; Annahmen ausgewiesen.
- **A-4 Export:** CSV + PDF (Abrechnung, Ledger, Form-8949/Schedule-D) mit Zeitraum-/Account-/Währungswahl.
**Akzeptanz:** vollständig, reproduzierbar, prüfbar.
- **A-5 Reconciliation (niedrig):** Abgleich mit eigener DB.
Die geldkritische Logik (Klassifikation, Aggregation, Realisierung, FX) ist von Anfang an pur +
unit-getestet; Ingest/Export werden über Interfaces (Activity-Quelle, PDF-Writer) testbar gehalten —
wie bei ResolutionFarming die Live-Anbindung hinter Interfaces liegt.
---
## 9. Risiken & Gegenmaßnahmen
| Risiko | Gegenmaßnahme |
|---|---|
| Unvollständige API-Historie / Pagination-Lücken | Balance-Anker-Soll-Ist als Vollständigkeits-Wächter; Lückenerkennung + Nachlad; Rohdaten-Snapshots |
| API-Feld-/Endpoint-Änderungen | Rohdaten speichern; Normalisierung entkoppelt; Feldnamen bei Umsetzung aus docs verifizieren |
| Doppelbuchung bei überlappenden Abrufen | strikte Idempotenz-Schlüssel + Upsert |
| Steuerliche Fehlinterpretation | bewusst neutrale, vollständige Aufstellung statt Steuerberechnung; Methodik im Export dokumentiert |
| FX-Korrektheit | amtliche Tageskurse (z. B. EZB) versioniert in `acc_fx_rates` |
| Falsche Wallet-Adresse (Proxy vs. Signer) für Deposits | Adress-/Transfer-Semantik je Account verifizieren |
---
## 10. Entscheidungen & offene Punkte
**Entschieden (2026-07-14):**
- ✅ **Währung:** USDC nativ + USD + EUR (Tageskurse EZB, USDC≈USD dokumentiert).
- ✅ **Abrechnung:** neutraler Ledger **+** US-Steuerschicht (Florida LLC), als CPA-prüfbare Rechenschicht.
- ✅ **Umfang v1:** inkl. On-Chain-Ein-/Auszahlungen.
- ✅ **Kostenbasis:** FIFO (US-Norm), Specific-ID als Option.
**Noch offen / vom CPA zu bestätigen:**
1. ✅ **PDF-Library: PDFsharp/MigraDoc (MIT)** — nach Rückfrage bewusst statt QuestPDF: QuestPDFs
„Community MIT"-Lizenz ist nur unter 1 Mio USD Jahresumsatz kostenlos (darüber Professional/
Enterprise kostenpflichtig) → für eine handelnde LLC ein Lizenzrisiko. PDFsharp/MigraDoc ist echte
MIT ohne Schwelle.
2. **Steuerliche Einordnung (Default-Annahme):** Property-Disposition (Form 8949/Schedule D, Default) vs.
ordinary income vs. gambling vs. §1256 — vom US-CPA bestätigen lassen; im Tool umstellbar.
3. **LLC-Typ:** single-member (disregarded) vs. multi-member (Partnership 1065/K-1) — bestimmt nur die
Ziel-Formulare/Darstellung, nicht die Gewinnermittlung.
4. **USDC=USD-Annahme & Wash-Sale-Schalter:** Defaults gesetzt (1:1; Wash-Sale n/a) — vom CPA bestätigen.
5. ✅ **Proxy-Wallets: geklärt.** Der Gnosis-Safe (= vorhandene `WalletAddress`) ist die Watch-Adresse;
zu bauen ist die **Transfer-Klassifikation** intern (Polymarket-Contracts) vs. extern (Deposit/Withdrawal)
über eine System-Contract-Whitelist (CTF-Adresse bereits im Code; Exchange/NegRisk/USDC ergänzen).
6. **FX-Quelle & USDC/USD:** EZB-Tageskurse für USD→EUR; USDC→USD als 1:1 (Default) oder realer Kurs?
docs/konzepte/KONZEPT-Modul-DataDriven.md
+129
View File
@@ -0,0 +1,129 @@
# 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/