Docs: Konzepte/Plaene in docs/ mit Typ-Unterordnern buendeln
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
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
1c3a364df2
commit
c5f0b1d188
@@ -0,0 +1,29 @@
|
|||||||
|
# Doku (Predictalytics / PolyTraderSharp)
|
||||||
|
|
||||||
|
Zentrale Ablage für Konzepte, Umsetzungspläne, Ideen und Fach-/Business-Dokumente — nach Typ in
|
||||||
|
Unterordnern organisiert. Code-gekoppelte Umsetzungspläne bleiben bewusst in **diesem** Repo (statt in
|
||||||
|
einem separaten Docs-Repo), damit „Plan → umsetzende Commits" nachvollziehbar bleibt.
|
||||||
|
|
||||||
|
## Struktur
|
||||||
|
|
||||||
|
- **`konzepte/`** — Konzepte für neue Module/Features (das „Warum" und „Was", vor der Umsetzung).
|
||||||
|
- `KONZEPT-Modul-Accounting.md` — Buchhaltungs-/Steuer-Reporting-Modul (unabhängiger Polymarket-Abruf, BWA, CSV/PDF, US-Steuer Florida LLC).
|
||||||
|
- `KONZEPT-Modul-DataDriven.md`
|
||||||
|
- **`umsetzungsplaene/`** — konkrete, slice-weise Implementationspläne (das „Wie"), oft mit `file:line`-Bezügen und Fortschritt.
|
||||||
|
- `UMSETZUNGSPLAN-Modularisierung.md` — Umbau Copytrader → Core + Module.
|
||||||
|
- `UMSETZUNGSPLAN-CopyTrading-Verbesserungen.md` — Rentabilitäts-/Fable-Plan Copytrading.
|
||||||
|
- `UMSETZUNGSPLAN-Fable-Review-Fixes.md` — Fable-Code-Review-Fixes (Slices 0–6 + Tests).
|
||||||
|
- `UMSETZUNGSPLAN-Modul-ResolutionFarming.md` — Strategiemodul ResolutionFarming.
|
||||||
|
- `UMSETZUNGSPLAN-Modul-MarketMaking.md` — Strategiemodul MarketMaking (Phase-1-blockiert).
|
||||||
|
- `UMSETZUNGSPLAN-Modul-BundleArbitrage.md` — Strategiemodul BundleArbitrage (Phase-1-blockiert).
|
||||||
|
- `UMSETZUNGSPLAN-AutoRedeem.md`, `UMSETZUNGSPLAN-AI-Aufloesequalitaet.md`, `UMSETZUNGSPLAN-StrategieDrift.md`
|
||||||
|
- **`ideen/`** — frühe Ideen/Explorationen, bevor sie zu einem Konzept oder Umsetzungsplan reifen.
|
||||||
|
- **`pruefplaene/`** — Prüf-/Validierungspläne.
|
||||||
|
- `PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md` — Master-Trader-Auswahl (separates Predictalytics-Projekt).
|
||||||
|
- **`steuer/`** — Steuer-/Buchhaltungs-Fachdokumente & Vorlagen (auch zum Weitergeben an Berater).
|
||||||
|
- `Accounting-US-Tax-Questionnaire.md` — Fragebogen (EN) für die US-Steuerberaterin (Florida LLC).
|
||||||
|
|
||||||
|
## Konventionen
|
||||||
|
- Neue Konzepte: `KONZEPT-*.md` → `konzepte/`. Neue Umsetzungspläne: `UMSETZUNGSPLAN-*.md` → `umsetzungsplaene/`.
|
||||||
|
- Übergreifende/an Externe weitergebbare Dokumente können später in ein eigenes `Predictalytics-Docs`-Repo
|
||||||
|
ausgelagert werden (Ordner rausziehen genügt) — für jetzt bewusst hier gebündelt.
|
||||||
@@ -0,0 +1 @@
|
|||||||
|
Platzhalter – hier kommen frühe Ideen/Explorationen rein, bevor sie zu einem Konzept oder Umsetzungsplan werden.
|
||||||
@@ -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?
|
||||||
@@ -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/
|
||||||
@@ -0,0 +1,127 @@
|
|||||||
|
# Predictalytics: Prüf- und Ergänzungsplan für die Master-Trader-Auswahl
|
||||||
|
|
||||||
|
> Stand: 2026-07-11
|
||||||
|
> Zweck: Dieses Dokument geht an den Predictalytics-Agenten. Es beschreibt, welche
|
||||||
|
> Auswahl-Kriterien und Validierungsschritte die Master-Trader-Selektion für das
|
||||||
|
> PolyTrader-Copytrading erfüllen soll — zum Abgleich mit den bereits vorhandenen
|
||||||
|
> Berechnungen und als Ergänzungsliste. Predictalytics ist ein eigenständiges Projekt;
|
||||||
|
> dieses Dokument setzt KEINE Kenntnis des PolyTrader-Codes voraus.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Kontext: Wofür die Auswahl gebraucht wird
|
||||||
|
|
||||||
|
PolyTrader kopiert Trades ausgewählter Polymarket-Wallets („Master") auf eigene
|
||||||
|
Accounts. Zielprofil laut Strategie-Entscheidung: **Buy-and-Hold-Master** — Trader,
|
||||||
|
die Positionen kaufen und in der Regel bis zur Marktauflösung halten, mit
|
||||||
|
überdurchschnittlichem Erfolg. Bei diesem Typ ist die Kopier-Latenz fast irrelevant;
|
||||||
|
die Auswahlqualität entscheidet über ~90 % des Ergebnisses.
|
||||||
|
|
||||||
|
Wichtig für alle Metriken: Der Kopierende zahlt gegenüber dem Master einen
|
||||||
|
**Kopier-Aufschlag** (Spread + bis zu 2 % Limit-Aufschlag + 0,75–1,8 % Taker-Fee je
|
||||||
|
nach Kategorie; bei Maker-Einstieg weniger, dafür Fill-Risiko). Ein Master ist erst
|
||||||
|
dann kopierenswert, wenn sein Edge diesen Aufschlag DEUTLICH übersteigt.
|
||||||
|
|
||||||
|
## 2. Kern-Metriken je Wallet (prüfen ob vorhanden, sonst ergänzen)
|
||||||
|
|
||||||
|
Alle Metriken über ein definiertes Fenster (Vorschlag: 90 Tage) und nur über
|
||||||
|
**aufgelöste/geschlossene** Trades:
|
||||||
|
|
||||||
|
| # | Metrik | Definition | Warum |
|
||||||
|
|---|---|---|---|
|
||||||
|
| M1 | Edge pro Trade | Ø realisierter PnL in % des Einsatzes je Trade | Muss > Kopier-Aufschlag (~3–4 Pp) liegen; „profitabel" allein reicht nicht |
|
||||||
|
| M2 | Profit-Faktor | Bruttogewinn / Bruttoverlust | Robuster als Winrate (Favoriten-Käufer haben 95 % Winrate und können negativ sein) |
|
||||||
|
| M3 | Holder-Quote | Anteil Positionen, die per Resolution enden (nie aktiv verkauft) | Zielprofil-Filter: Zielwert nahe 100 % |
|
||||||
|
| M4 | Stop-Loss-Verhalten | Anteil SELLs, die NACH einem Preisrückgang ≥ X % erfolgen | Trennt „Stur-Halter" von „Stop-Loss-Nutzern" — Letztere sind fürs Kopieren ungeeignet (Exit-Latenz-Nachteil) |
|
||||||
|
| M5 | Trade-Frequenz & Stichprobe | Trades/Woche; Gesamtzahl im Fenster | Mindeststichprobe für alles Weitere (siehe 3.1) |
|
||||||
|
| M6 | Ø-Haltedauer | Median Stunden Kauf→Auflösung | Kapitalbindung des Kopierenden; plus Konsistenz-Indikator |
|
||||||
|
| M7 | Preisband-Profil | Verteilung der Einstiegspreise (z. B. je 10-¢-Band) | Charakterisiert die Strategie (Favoriten-Halter vs. Longshot-Spieler) |
|
||||||
|
| M8 | Kategorien-Mix | Einsatz-Anteil je Marktkategorie | Für Korrelations-/Portfolio-Betrachtung (siehe 5) und Fee-Rechnung |
|
||||||
|
| M9 | Einsatz-Disziplin | Verteilung der Positionsgrößen relativ zur Wallet | Erkennt Martingale-/Tilt-Muster (stark wachsende Einsätze nach Verlusten = rotes Tuch) |
|
||||||
|
|
||||||
|
## 3. Validierungs-Methodik (die drei klassischen Fallen)
|
||||||
|
|
||||||
|
### 3.1 Survivorship-/Glücks-Bias
|
||||||
|
|
||||||
|
Unter zehntausenden Wallets sehen einige rein zufällig brillant aus. Gegenmaßnahmen:
|
||||||
|
|
||||||
|
1. **Mindeststichprobe:** keine Bewertung unter ~100 aufgelösten Trades im Fenster.
|
||||||
|
2. **Out-of-Sample-Pflicht:** Auswahl auf Zeitfenster A (z. B. Tag −180 bis −60),
|
||||||
|
Bestätigung auf Fenster B (Tag −60 bis heute). Nur Master, die in BEIDEN Fenstern
|
||||||
|
die Schwellen erfüllen, kommen auf die Kopier-Liste. Master, die nur in A glänzen,
|
||||||
|
werden verworfen — egal wie gut A aussieht.
|
||||||
|
3. **Plausibilitäts-Check des Edges:** Bei Favoriten-Haltern lässt sich der Edge als
|
||||||
|
„realisierte Winrate je Einstiegs-Preisband vs. Preisband" ausdrücken (kauft er
|
||||||
|
95-¢-Shares, die zu 98 % gewinnen → +3 Pp Edge). Diese Darstellung bitte je Master
|
||||||
|
ausgeben — sie macht Glück von System unterscheidbar und ist direkt mit der
|
||||||
|
ResolutionFarming-Kalibrierung in PolyTrader vergleichbar.
|
||||||
|
|
||||||
|
### 3.2 Kopierbarkeit
|
||||||
|
|
||||||
|
Ein profitabler Master kann unkopierbar sein. Je Master prüfen:
|
||||||
|
|
||||||
|
1. **Markt-Liquidität:** Median-Liquidität/Volumen der gehandelten Märkte. Handelt er
|
||||||
|
in Kleinstmärkten, bewegt schon der Kopier-Kauf den Preis. Vorschlag: Median-Buch-
|
||||||
|
Tiefe oder 24h-Volumen der gehandelten Märkte als Kriterium, Schwelle empirisch.
|
||||||
|
2. **Edge-Verbleib nach Kopier-Aufschlag:** M1 minus 3–4 Pp muss > 0 bleiben
|
||||||
|
(Kategorie-Fee einrechnen: Sports 0,75 %, Politik 1,0 %, Krypto 1,8 %).
|
||||||
|
3. **Einstiegs-Fenster:** Wie schnell bewegt sich der Preis nach dem Master-Kauf?
|
||||||
|
(Median-Preisänderung 1 min / 10 min / 1 h nach seinen Fills, aus der Preis-
|
||||||
|
Historie). Läuft der Preis sofort weg, ist der Edge zeitkritisch → schlecht
|
||||||
|
kopierbar; bleibt er stabil, passt auch ein ruhender Maker-Einstieg.
|
||||||
|
|
||||||
|
### 3.3 Korrelation / Portfolio-Ebene
|
||||||
|
|
||||||
|
Nicht nur Einzel-Scores ranken — die Kopier-Liste ist ein Portfolio:
|
||||||
|
|
||||||
|
1. **Master-Korrelation:** Überlappung der gehandelten Märkte/Kategorien zwischen
|
||||||
|
Kandidaten (z. B. Jaccard auf ConditionIds, Kategorie-Mix-Ähnlichkeit). Drei gute
|
||||||
|
Wetter-Bots sind EIN Klumpenrisiko, nicht drei Ertragsquellen.
|
||||||
|
2. **Empfehlung als Portfolio:** Ausgabe nicht nur als Rangliste, sondern als
|
||||||
|
diversifizierter Vorschlag (z. B. max. 2 Master je Kategorie-Schwerpunkt).
|
||||||
|
|
||||||
|
## 4. Verhaltens-Fingerprint als Basisdaten (Übergabe an PolyTrader)
|
||||||
|
|
||||||
|
PolyTrader soll Strategie-Drift der Master zur Laufzeit erkennen (separater Plan
|
||||||
|
dort). Dafür braucht es je ausgewähltem Master eine **Baseline**, die Predictalytics
|
||||||
|
ohnehin berechnet — bitte mit exportieren: Trade-Frequenz/Woche, Kategorien-Mix,
|
||||||
|
Einstiegs-Preisband-Verteilung, Median-Haltedauer, Positionsgrößen-Verteilung
|
||||||
|
(jeweils Fenster B). Format: JSON je Wallet.
|
||||||
|
|
||||||
|
## 5. Übergabe-Format an PolyTrader (Vorschlag)
|
||||||
|
|
||||||
|
Je empfohlenem Master ein Datensatz:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"wallet": "0x…",
|
||||||
|
"displayName": "…",
|
||||||
|
"classification": "HOLDER", // HOLDER | STOPLOSS | MIXED — nur HOLDER wird kopiert
|
||||||
|
"windowA": { "trades": 214, "edgePerTradePct": 6.1, "profitFactor": 2.4, "holderRatio": 0.98 },
|
||||||
|
"windowB": { "trades": 180, "edgePerTradePct": 5.4, "profitFactor": 2.1, "holderRatio": 0.99 },
|
||||||
|
"copyability": { "medianMarketVolumeUsd": 120000, "postFillDrift10minPct": 0.4, "netEdgeAfterCopyCostsPct": 2.1 },
|
||||||
|
"categoryMix": { "Sports": 0.7, "Politics": 0.3 },
|
||||||
|
"fingerprintBaseline": { "tradesPerWeek": 38, "medianHoldHours": 22, "priceBands": { "0.90-0.95": 0.6, "0.95-0.99": 0.3 }, "sizeP90Usd": 450 },
|
||||||
|
"riskFlags": ["…"] // z. B. Martingale-Verdacht, Kategorie-Klumpen
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## 6. Akzeptanzkriterien des Prüflaufs
|
||||||
|
|
||||||
|
1. Jede Kern-Metrik (M1–M9) ist je Kandidat berechnet oder als „nicht berechenbar"
|
||||||
|
mit Grund markiert.
|
||||||
|
2. Kein Master auf der Empfehlungsliste ohne bestandene Out-of-Sample-Bestätigung
|
||||||
|
und Mindeststichprobe.
|
||||||
|
3. Klassifikation HOLDER/STOPLOSS/MIXED je Kandidat mit den zugrunde liegenden
|
||||||
|
Zahlen (M3/M4) nachvollziehbar.
|
||||||
|
4. Die Empfehlungsliste enthält die Korrelations-/Portfolio-Betrachtung (5.).
|
||||||
|
5. Export im Übergabe-Format (5.) für den PolyTrader-Import.
|
||||||
|
|
||||||
|
## 7. Offene Fragen an Predictalytics (bitte im Ergebnis beantworten)
|
||||||
|
|
||||||
|
1. Welche der Metriken/Validierungen existieren bereits, welche wurden ergänzt?
|
||||||
|
2. Wie viele Wallets überleben die volle Filterkette (Funnel-Zahlen je Stufe)?
|
||||||
|
Wenn < 3: Welche Schwelle ist der Engpass, und wie sähe eine begründete
|
||||||
|
Lockerung aus (statt stillschweigend zu lockern)?
|
||||||
|
3. Wie aktuell sind die Daten (Lag der Datenquelle), und wie oft kann die
|
||||||
|
Auswahl neu gerechnet werden (Ziel: mindestens wöchentlich)?
|
||||||
@@ -0,0 +1,122 @@
|
|||||||
|
# US Tax Treatment Questionnaire — Polymarket Trading Operations (Florida LLC)
|
||||||
|
|
||||||
|
*Prepared for our US CPA / tax advisor. Purpose: determine the correct federal tax treatment and the
|
||||||
|
exact report formats so our in-house accounting tool computes and exports precisely what you need.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Context
|
||||||
|
|
||||||
|
We operate automated trading strategies on **Polymarket** — a blockchain-based prediction-market /
|
||||||
|
event-contract platform — through a **Florida LLC**. Positions settle in **USDC** (a USD-pegged
|
||||||
|
stablecoin) on the Polygon network via Polymarket's smart contracts and **Gnosis-Safe proxy wallets**.
|
||||||
|
|
||||||
|
We are building an in-house accounting tool that:
|
||||||
|
|
||||||
|
- Independently pulls **every transaction of every trading account directly from Polymarket** (not from
|
||||||
|
our own trading database) and stores an **immutable, audit-traceable ledger** — each entry backed by a
|
||||||
|
blockchain transaction hash / platform activity ID and a stored raw-data snapshot.
|
||||||
|
- Reconciles each account against its **on-chain USDC balance** as a completeness check.
|
||||||
|
- Produces **per-account and consolidated period statements** (monthly and custom date ranges) and will
|
||||||
|
produce **US federal tax computations** (Form 8949 / Schedule D-style) under assumptions **you specify**.
|
||||||
|
|
||||||
|
**Transaction/event types we capture per account:** buys, sells, redemptions (winning-position payouts at
|
||||||
|
market resolution), losing positions expiring worthless, trading fees, maker rewards / rebates, on-chain
|
||||||
|
USDC deposits and withdrawals.
|
||||||
|
|
||||||
|
Where a treatment is uncertain, we will implement **your chosen approach as a documented, configurable
|
||||||
|
assumption** that is disclosed on every export. Please answer as many items as are relevant.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## A. Entity, filing & registration
|
||||||
|
1. Federal classification of the LLC: **single-member (disregarded entity)** or **multi-member
|
||||||
|
(partnership, Form 1065 + Schedules K-1)**? Any election to be taxed as **S-corp / C-corp**
|
||||||
|
(Form 2553 / 8832)?
|
||||||
|
2. Which federal forms/schedules will this activity flow into (e.g., Schedule C, Schedule D + Form 8949,
|
||||||
|
Form 1065/K-1, Form 4797)?
|
||||||
|
3. Florida has no personal state income tax — is there anything at the entity level we must reflect, or
|
||||||
|
is this **federal only**? Any Florida annual-report items affecting our accounting?
|
||||||
|
4. EIN and tax year (we assume calendar year)?
|
||||||
|
|
||||||
|
## B. Character & classification of Polymarket P&L
|
||||||
|
5. How should gains/losses from Polymarket **event contracts** be characterized: **capital gains/losses**
|
||||||
|
(Form 8949 / Schedule D), **ordinary income**, **gambling winnings/losses**, **§1256 contracts**
|
||||||
|
(60/40, mark-to-market), or **other**?
|
||||||
|
6. Do you regard these instruments as **securities, commodities, swaps, wagering transactions, or
|
||||||
|
property**? Does the characterization differ by market type (e.g., sports vs. politics vs. crypto-price)?
|
||||||
|
7. If capital: our holding periods are effectively always **under one year** — do you want everything
|
||||||
|
reported as **short-term**, or should we still compute per-lot holding periods (acquisition → disposition)?
|
||||||
|
8. If gambling treatment applies: how should we present winnings vs. losses (losses limited to winnings;
|
||||||
|
per-wager vs. session netting)?
|
||||||
|
|
||||||
|
## C. Trader Tax Status & §475(f) mark-to-market
|
||||||
|
9. Given the volume and automation, could the LLC qualify for **Trader Tax Status (TTS)**? Do you
|
||||||
|
recommend a **§475(f) mark-to-market election** (ordinary gain/loss, no wash-sale, no capital-loss
|
||||||
|
limitation, year-end MTM)?
|
||||||
|
10. If §475(f) MTM applies, what **price source and timing** would you accept to mark **open positions**
|
||||||
|
at period/year end (last trade, mid-price, resolution probability)?
|
||||||
|
11. **Self-employment tax:** does this activity create SE-tax exposure, or is it exempt (trading gains
|
||||||
|
generally not SE income)?
|
||||||
|
|
||||||
|
## D. Cost basis & lot accounting
|
||||||
|
12. Cost-basis method: **FIFO** (our default), **specific identification**, or other? Any documentation
|
||||||
|
requirements for specific-ID?
|
||||||
|
13. Should trading **fees** be **capitalized into basis / netted against proceeds**, or deducted
|
||||||
|
**separately** as expenses?
|
||||||
|
14. **Redemption** (winning shares pay out at resolution): treat as a disposition at **$1.00/share**
|
||||||
|
proceeds against lot basis? **Losing shares** expiring worthless: treat as a disposition at **$0**
|
||||||
|
(realized loss) on the resolution date?
|
||||||
|
15. Partial fills within one transaction: acceptable to **aggregate same-tx fills into one lot**?
|
||||||
|
|
||||||
|
## E. USDC / stablecoin treatment
|
||||||
|
16. May we treat **USDC as a USD cash-equivalent (1:1)**, so acquiring/spending USDC is **not** itself a
|
||||||
|
separate taxable crypto disposition? Or must USDC be tracked as **property** with its own basis?
|
||||||
|
17. If USDC must be tracked as property, what **USD valuation source/timing** per transaction do you require?
|
||||||
|
|
||||||
|
## F. Wash-sale & related rules
|
||||||
|
18. Do **wash-sale rules (§1091)** apply to these instruments (they are not traditional "stock or
|
||||||
|
securities," and crypto is currently generally exempt)? If potentially applicable, should the tool
|
||||||
|
**flag/adjust** wash sales?
|
||||||
|
19. Are **straddle (§1092)** or **constructive-sale** rules relevant to any hedged/paired positions?
|
||||||
|
|
||||||
|
## G. Income items & deductions
|
||||||
|
20. **Maker rewards / liquidity rebates** received in USDC: **ordinary income at fair value on receipt**?
|
||||||
|
Where reported? Does receipt create a **new USDC lot** at that value?
|
||||||
|
21. Deductible business **expenses** (platform/trading fees, Polygon gas/POL, infrastructure, software,
|
||||||
|
this tooling): where and how (Schedule C vs. netted)?
|
||||||
|
22. Will Polymarket issue any **1099** (likely not, as a non-US operator)? If so, how should we reconcile to it?
|
||||||
|
|
||||||
|
## H. Foreign account / information reporting
|
||||||
|
23. Is a Polymarket account (funds in a Polygon **Gnosis-Safe proxy** on a non-US platform) a **"foreign
|
||||||
|
financial account"** triggering **FBAR (FinCEN Form 114)** above the $10,000 aggregate threshold?
|
||||||
|
24. Does **FATCA / Form 8938** reporting apply (specified foreign financial assets)?
|
||||||
|
25. Is **Form 8886** (reportable transactions) or any other information return relevant?
|
||||||
|
26. Any concerns arising from Polymarket's **US regulatory status** that affect characterization or reporting?
|
||||||
|
|
||||||
|
## I. Currency & valuation
|
||||||
|
27. Reporting/functional currency: **USD** confirmed? We also generate **EUR** figures — needed for the US
|
||||||
|
filing, or purely internal/EU personal use?
|
||||||
|
28. FX source/timing: for non-USD figures, is the **ECB daily reference rate at transaction date**
|
||||||
|
acceptable? For **USDC→USD**, is **1:1** acceptable or do you require actual spot?
|
||||||
|
|
||||||
|
## J. Report format & delivery (so we tailor exports to you)
|
||||||
|
29. Preferred deliverables: **Form 8949 CSV in the exact IRS column layout**, a **general-ledger** export,
|
||||||
|
a **Schedule D summary**, and/or a **PDF statement**? Which formats do you want?
|
||||||
|
30. Level: **per-account** statements, a **consolidated LLC** view, or both?
|
||||||
|
31. Cadence: **monthly** bookkeeping packages plus an **annual** tax package? Do you need **quarterly
|
||||||
|
estimated-tax** figures?
|
||||||
|
32. Exact **columns/fields** on the disposition report (e.g., Description of property, Date acquired, Date
|
||||||
|
sold, Proceeds, Cost basis, Wash-sale adjustment, Gain/loss, Short/Long)?
|
||||||
|
33. **Audit-defensibility** documentation you want attached (methodology page, source transaction hashes,
|
||||||
|
raw-data retention, reconciliation to on-chain balances)?
|
||||||
|
34. Rounding/precision conventions (whole USD vs. cents)?
|
||||||
|
|
||||||
|
## K. Anything else
|
||||||
|
35. Any other **elections, forms, thresholds, or record-keeping standards** we should build into the tool
|
||||||
|
now to make your work smooth and the LLC's filings defensible?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*We will encode your answers as the tool's default assumptions, each disclosed on every statement and
|
||||||
|
adjustable in settings. Thank you.*
|
||||||
@@ -0,0 +1,126 @@
|
|||||||
|
# Umsetzungsplan: AI-Bewertung der Auflösequalität (C-S4)
|
||||||
|
|
||||||
|
> Stand: 2026-07-11
|
||||||
|
> Ziel: Ein LLM (via OpenRouter) bewertet je Markt das RESOLUTION-Risiko (subjektive
|
||||||
|
> Auflösequellen, Regeltext-Fallen, UMA-Dispute-Muster). Die Bewertung wird beim
|
||||||
|
> Markt-Import in der DB gespeichert und dient als Entry-Gate — zuerst im
|
||||||
|
> ResolutionFarming, perspektivisch auch im Copytrading.
|
||||||
|
> Einordnung: Core-Baustein (beide Module profitieren), kein eigenes Strategiemodul.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Abgrenzung (wichtig für die Umsetzung)
|
||||||
|
|
||||||
|
Das LLM prognostiziert NICHT den Markt-Ausgang. Es beantwortet ausschließlich:
|
||||||
|
**„Wie sauber/objektiv wird dieser Markt aufgelöst werden?"** — Input ist der
|
||||||
|
Regeltext, nicht das Weltgeschehen. Das hält die Aufgabe eng, billig und testbar.
|
||||||
|
|
||||||
|
## 2. Architektur
|
||||||
|
|
||||||
|
### 2.1 Core-Service `IMarketRiskRater` (PolyTrader.Core)
|
||||||
|
|
||||||
|
```csharp
|
||||||
|
public interface IMarketRiskRater
|
||||||
|
{
|
||||||
|
/// Liefert die (ggf. gecachte) Bewertung; null wenn (noch) keine vorliegt.
|
||||||
|
Task<MarketRiskRating?> GetOrRateAsync(MarketData market, CancellationToken ct);
|
||||||
|
}
|
||||||
|
|
||||||
|
public class MarketRiskRating // Tabelle core_market_risk_ratings
|
||||||
|
{
|
||||||
|
public string ConditionId { get; set; } // PK — Regeltexte ändern sich nicht → dauerhaft cachebar
|
||||||
|
public int Score { get; set; } // 0–100 (100 = völlig objektiv auflösbar)
|
||||||
|
public string Flags { get; set; } // CSV: SUBJECTIVE_SOURCE, DEADLINE_AMBIGUITY,
|
||||||
|
// MENTIONS_TYPE, DISPUTE_PATTERN, MISSING_RULES
|
||||||
|
public string Reason { get; set; } // Einzeiler-Begründung des Modells
|
||||||
|
public string Model { get; set; } // verwendetes Modell (Nachvollziehbarkeit)
|
||||||
|
public DateTime RatedAt { get; set; }
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.2 `OpenRouterClient` (Core, dünn)
|
||||||
|
|
||||||
|
- HTTP-Client gegen https://openrouter.ai/api/v1/chat/completions, API-Key aus
|
||||||
|
appsettings (`OpenRouter:ApiKey`, gitignoriert wie andere Secrets).
|
||||||
|
- **Modellwahl:** günstiges Modell reicht (Haiku-Klasse, z. B.
|
||||||
|
`anthropic/claude-haiku-4.5` via OpenRouter; Modell-ID als Setting, nicht
|
||||||
|
hartkodieren). Kosten je Markt: Bruchteile eines Cents; mit Cache je ConditionId
|
||||||
|
einmalig pro Markt.
|
||||||
|
- **Structured Output:** Antwort als JSON erzwingen (Schema im Prompt + JSON-Mode);
|
||||||
|
bei Parse-Fehler 1 Retry, danach „kein Rating" (fail-closed, siehe 3.3).
|
||||||
|
- Timeout kurz (~15 s), Fehler loggen, NIE den aufrufenden Scanner blockieren.
|
||||||
|
|
||||||
|
### 2.3 Prompt (Kern, bei Umsetzung feinjustieren)
|
||||||
|
|
||||||
|
Input je Markt: `Question`, `Description`/Resolution-Kriterien (Gamma-API liefert
|
||||||
|
den Regeltext am Markt-Objekt — Feld bei Umsetzung verifizieren), Kategorie, EndDate.
|
||||||
|
|
||||||
|
Bewertungsauftrag an das Modell (sinngemäß):
|
||||||
|
1. Gibt es eine EINDEUTIGE, öffentlich prüfbare Auflösequelle (offizielles
|
||||||
|
Endergebnis, behördliche Zahl, On-Chain-Fakt)?
|
||||||
|
2. Sind Randfälle geregelt (Verschiebung, Abbruch, Unentschieden, Definitionsfragen
|
||||||
|
wie „offiziell angekündigt")?
|
||||||
|
3. Ähnelt der Markt bekannten Streit-Mustern (Mentions-/„sagt X"-Märkte, vage
|
||||||
|
Deadlines, Definitions-Ambiguität, mehrdeutige Quellen)?
|
||||||
|
Output: `{ "score": 0-100, "flags": [...], "reason": "…" }`.
|
||||||
|
|
||||||
|
## 3. Integration
|
||||||
|
|
||||||
|
### 3.1 Wann wird bewertet?
|
||||||
|
|
||||||
|
Beim Markt-Import bzw. beim ersten Kontakt: Der **RF-Scanner** ruft
|
||||||
|
`GetOrRateAsync` für jeden Kandidaten auf, der alle billigen Filter passiert hat
|
||||||
|
(NACH Preisband/Kategorie/Fenster, VOR dem Accept — kein LLM-Call für offensichtliche
|
||||||
|
Rejects). Cache macht Wiederholungs-Scans kostenlos.
|
||||||
|
|
||||||
|
### 3.2 Entry-Gate im ResolutionFarming
|
||||||
|
|
||||||
|
Neue `RfSettings`:
|
||||||
|
- `MinResolutionScore` (Default 70): Kandidaten mit Score darunter → Reject mit
|
||||||
|
Grund `"AI-Resolution-Score {score} < {min}: {reason}"` (landet wie alle Rejects
|
||||||
|
in rf_candidates → die Kalibrierung kann später prüfen, ob das Gate Geld spart!).
|
||||||
|
- `RequireRating` (Default true): fail-closed-Schalter (siehe 3.3).
|
||||||
|
|
||||||
|
### 3.3 Fail-Closed-Regeln (Sicherheitskern)
|
||||||
|
|
||||||
|
1. Kein Rating verfügbar (API down, Parse-Fehler, kein Regeltext) → Kandidat gilt
|
||||||
|
als riskant und wird abgelehnt — AUSSER die Kategorie steht auf einer
|
||||||
|
Objektiv-Whitelist (Default: Sports-Endergebnisse), dann Durchlass mit Log.
|
||||||
|
2. Das Rating **ersetzt die harte Blacklist nicht**: bekannte Giftmuster
|
||||||
|
(Mentions-Märkte etc.) bleiben in `BlacklistCsv` hart geblockt. Das LLM ist die
|
||||||
|
zweite Verteidigungslinie für den Long Tail, nicht die erste.
|
||||||
|
3. **Post-Mortem-Pflicht:** Jeder real erlebte Dispute → Muster in Blacklist/Prompt
|
||||||
|
aufnehmen. Dafür Flag-Feld in rf_closed_trades (`ResolutionDisputed`) vorsehen.
|
||||||
|
|
||||||
|
### 3.4 Copytrading (zweiter Schritt, optional)
|
||||||
|
|
||||||
|
Gleicher Service: Vor einem BUY den Score prüfen; unter Schwelle → Trade
|
||||||
|
verwerfen mit TradeReasoning-Log. Als Per-Account-Setting (`MinResolutionScore`,
|
||||||
|
0 = aus), Default zunächst AUS, um das Copy-Verhalten nicht zu verändern, bis der
|
||||||
|
Rater validiert ist.
|
||||||
|
|
||||||
|
## 4. Validierung VOR dem Scharfschalten (Pflicht-Phase)
|
||||||
|
|
||||||
|
1. **Retrospektiv-Test:** ~15–20 öffentlich bekannte, umstrittene UMA-Resolutions
|
||||||
|
(Recherche-Aufgabe: bekannte Dispute-Fälle) + ~30 unstrittig aufgelöste
|
||||||
|
Vergleichsmärkte durch den Rater schicken. Messen: erwischt er die Streitfälle
|
||||||
|
(niedriger Score), ohne die sauberen zu blockieren?
|
||||||
|
2. **Akzeptanz:** ≥ 80 % der Streitfälle unter der Schwelle, ≤ 10 % der sauberen
|
||||||
|
fälschlich blockiert. Sonst Prompt/Schwelle iterieren.
|
||||||
|
3. Ergebnisse als Testdaten einfrieren (Golden-File-Test, läuft ohne API gegen
|
||||||
|
gespeicherte Antworten — kein LLM-Call in der CI).
|
||||||
|
|
||||||
|
## 5. Phasen
|
||||||
|
|
||||||
|
| Phase | Inhalt | Akzeptanz |
|
||||||
|
|---|---|---|
|
||||||
|
| AR-1 | OpenRouterClient + IMarketRiskRater + Tabelle/Migration + Unit-Tests (Parsing, Fail-Closed) | Build grün; Rater liefert für einen Beispiel-Regeltext strukturiertes Rating |
|
||||||
|
| AR-2 | Retrospektiv-Validierung (4.) | Akzeptanzquoten erreicht, dokumentiert |
|
||||||
|
| AR-3 | RF-Integration (3.1/3.2/3.3) + UI-Spalte (Score in Kandidaten-Tab) | Rejects mit AI-Grund sichtbar; Kalibrierung kann Gate-Wirkung auswerten |
|
||||||
|
| AR-4 | Copytrading-Integration (3.4), Default aus | Setting vorhanden, dokumentiert |
|
||||||
|
|
||||||
|
## 6. Leitplanken
|
||||||
|
|
||||||
|
- API-Key nie committen; Kosten-Deckel (max. Ratings/Tag als Setting, Default 500).
|
||||||
|
- Der Rater beeinflusst NIE Exits, nur Entries (keine Panik-Verkäufe durch LLM).
|
||||||
|
- Score/Reason immer mitloggen — Entscheidungen müssen im Log nachvollziehbar sein.
|
||||||
@@ -0,0 +1,117 @@
|
|||||||
|
# Umsetzungsplan: On-Chain-Auto-Redeem (modulweise schaltbar)
|
||||||
|
|
||||||
|
> Stand: 2026-07-11
|
||||||
|
> Ziel: Gewonnene Positionen automatisch on-chain einlösen (Shares → USDC), als
|
||||||
|
> **Core-Baustein** mit **Aktivierung je Modul**. Richards Anforderung: In Testphasen
|
||||||
|
> neuer Module soll Auto-Redeem gezielt AUS bleiben können, um die Performance der
|
||||||
|
> Entwicklung manuell nachvollziehen zu können — ohne dass andere, etablierte Module
|
||||||
|
> ihren Automatismus verlieren.
|
||||||
|
> ⚠️ Höchste clob.md-Kritikalität: On-Chain-Signing mit echten Private Keys.
|
||||||
|
> Jede Phase: Backup/Commit vorher, Testmarkt/Kleinstbetrag zuerst.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Architektur: Queue statt Direktaufruf
|
||||||
|
|
||||||
|
Module redeemen nie selbst. Sie melden einlösbare Positionen in eine zentrale
|
||||||
|
Queue; ein Core-Worker arbeitet sie ab — nur für Module, deren Auto-Redeem aktiv ist.
|
||||||
|
|
||||||
|
```
|
||||||
|
Modul (RF-Monitor, CT-Sync, später DD) PolyTrader.Core
|
||||||
|
│ erkennt „Position gewonnen & aufgelöst" │
|
||||||
|
├── IRedeemQueue.Enqueue(RedeemRequest) ─────────────▶│ Tabelle core_redeem_queue
|
||||||
|
│ (immer! unabhängig vom Schalter) │
|
||||||
|
│ ▼
|
||||||
|
│ OnChainRedeemWorker (BackgroundService)
|
||||||
|
│ • nur Requests von Modulen mit AutoRedeemEnabled
|
||||||
|
│ • Rest bleibt als "Manual" sichtbar (UI-Liste)
|
||||||
|
▼ • CTF redeemPositions / NegRiskAdapter
|
||||||
|
UI je Modul: Pending-Redeems-Ansicht • Verifikation über USDC-Balance-Delta
|
||||||
|
```
|
||||||
|
|
||||||
|
**Warum immer enqueuen:** Auch bei deaktiviertem Auto-Redeem entsteht so eine
|
||||||
|
vollständige, je Modul gefilterte „zum Redeem bereit"-Liste (Dashboard/UI) — genau
|
||||||
|
die Übersicht, die Richard in Testphasen für die manuelle Betreuung will. Der
|
||||||
|
Schalter entscheidet nur, ob der Worker sie abarbeitet.
|
||||||
|
|
||||||
|
### 1.1 Datenmodell (`core_redeem_queue`)
|
||||||
|
|
||||||
|
| Feld | Inhalt |
|
||||||
|
|---|---|
|
||||||
|
| Id (auto) | PK |
|
||||||
|
| ModuleName | "ResolutionFarming" / "CopyTrading" / … |
|
||||||
|
| AccountId, TokenId, ConditionId | Ziel der Einlösung (ConditionId zwingend — für den Contract-Call) |
|
||||||
|
| IsNegRisk | Adapter-Wahl |
|
||||||
|
| SizeShares, ExpectedUsd | erwartete Auszahlung (Shares × 1.00) |
|
||||||
|
| Status | Pending / Processing / Done / Failed / Manual |
|
||||||
|
| Attempts, LastError, EnqueuedAt, CompletedAt, TxHash | Betrieb/Nachvollziehbarkeit |
|
||||||
|
|
||||||
|
### 1.2 Schalter
|
||||||
|
|
||||||
|
- **Je Modul:** `core_module_settings` (oder appsettings-Sektion) —
|
||||||
|
`AutoRedeem:ResolutionFarming = false`, `AutoRedeem:CopyTrading = false`
|
||||||
|
(Default IMMER aus; bewusstes Einschalten je Modul).
|
||||||
|
- **Global-Not-Aus:** `AutoRedeemGlobalEnabled` (analog GlobalTradingPaused,
|
||||||
|
Quickbar-Toggle) — schlägt alle Modul-Schalter.
|
||||||
|
- UI: Schalter je Modul in dessen Settings-Tab + Anzeige im Core-Dashboard,
|
||||||
|
welche Module aktiv sind.
|
||||||
|
|
||||||
|
## 2. Der On-Chain-Teil (`OnChainCtfService`, Core)
|
||||||
|
|
||||||
|
1. **Bibliothek:** Nethereum (bereits als Abhängigkeit im Projekt für EIP-712-Signing
|
||||||
|
vorhanden) — Contract-Calls über die bestehende Alchemy-RPC-Anbindung (Polygon).
|
||||||
|
2. **Aufrufe:** Standard-Markt: ConditionalTokens `redeemPositions(collateral,
|
||||||
|
parentCollectionId=0x0, conditionId, indexSets)`; NegRisk-Markt: über den
|
||||||
|
NegRisk-Adapter. **Contract-Adressen + ABI + indexSets-Ermittlung bei Umsetzung
|
||||||
|
zwingend aus https://docs.polymarket.com (Developer/CTF) verifizieren — nicht aus
|
||||||
|
dem Gedächtnis kodieren.** Die USDC-/CTF-Adressen als Konstanten mit Quellenangabe.
|
||||||
|
3. **Gas:** Wallet braucht POL. Vor jedem Call Balance-Check; unter Schwelle
|
||||||
|
(Setting, z. B. 0.5 POL) → Request auf `Manual` + Threema-Warnung „POL nachfüllen".
|
||||||
|
Gas-Preis: Standard-Estimation, Cap als Setting.
|
||||||
|
4. **Verifikation = Wahrheit:** Ein Redeem gilt erst als `Done`, wenn (a) die Tx
|
||||||
|
bestätigt ist UND (b) das USDC-Balance-Delta ≈ ExpectedUsd (Toleranz) gemessen
|
||||||
|
wurde. Sonst `Failed` mit Fehlertext.
|
||||||
|
5. **Retry:** max. 3 Versuche mit Backoff (1/10/60 min), danach `Manual` + Threema.
|
||||||
|
Idempotenz beachten: vor jedem Versuch prüfen, ob die Position on-chain überhaupt
|
||||||
|
noch einlösbar ist (bereits redeemte Shares → als Done werten, nicht als Fehler).
|
||||||
|
|
||||||
|
## 3. Modul-Integration
|
||||||
|
|
||||||
|
### 3.1 ResolutionFarming (erster Nutzer)
|
||||||
|
`FarmingResolutionMonitorService` setzt heute `RedeemStatus = "Pending"` am
|
||||||
|
RfClosedTrade. Ergänzung: beim Schließen eines Gewinners → `IRedeemQueue.Enqueue`.
|
||||||
|
Worker-Callback (oder Status-Poll) aktualisiert `RedeemStatus` (Pending → Redeemed/
|
||||||
|
Manual/Failed) → sichtbar im Historie-Tab. **Wichtig für Richards Testphasen-
|
||||||
|
Anforderung:** Der realisierte PnL ist bereits bei Resolution gebucht; der Redeem
|
||||||
|
ändert nur die Kapitalverfügbarkeit. Die Performance-Auswertung bleibt also mit und
|
||||||
|
ohne Auto-Redeem identisch — nur die Bankroll-Rotation unterscheidet sich.
|
||||||
|
|
||||||
|
### 3.2 CopyTrading (zweiter Nutzer)
|
||||||
|
Im `TraderMonitorService` existiert die Stelle bereits: der auskommentierte
|
||||||
|
Python-Redeem-Block im Resolution-Fallback („bereit für manuellen Redeem")
|
||||||
|
— dort `Enqueue` statt Kommentar. Gleicher PnL-Hinweis wie oben.
|
||||||
|
|
||||||
|
### 3.3 Künftige Module
|
||||||
|
Contract: Ein Modul, das Positionen bis Resolution hält, ruft bei „gewonnen &
|
||||||
|
aufgelöst" genau einmal `Enqueue` und liest optional den Status zurück. Mehr nicht.
|
||||||
|
|
||||||
|
## 4. Phasen & Akzeptanzkriterien
|
||||||
|
|
||||||
|
| Phase | Inhalt | Akzeptanz |
|
||||||
|
|---|---|---|
|
||||||
|
| RD-1 | Queue-Tabelle + IRedeemQueue + Modul-Schalter + UI-Pending-Liste (noch KEIN On-Chain-Code) | Module enqueuen; Liste zeigt je Modul „bereit zum Redeem"; Schalter sichtbar; 100 % ohne Live-API testbar |
|
||||||
|
| RD-2 | `OnChainCtfService` gegen Polygon: zuerst READ-only (Balance, Einlösbarkeits-Check) | Balance-/Zustandsabfragen stimmen gegen Polygonscan |
|
||||||
|
| RD-3 | Erster echter Redeem: EIN Testmarkt, Kleinstbetrag, manuell getriggert (Button an der Pending-Liste) | Tx bestätigt, USDC-Delta verifiziert, Status Done |
|
||||||
|
| RD-4 | Worker-Automatik scharf für RF (Schalter an), CT folgt nach Beobachtung | 1 Woche fehlerfreier Betrieb, Failed-Quote < 5 %, POL-Warnung getestet |
|
||||||
|
|
||||||
|
## 5. Leitplanken
|
||||||
|
|
||||||
|
1. `.agents/rules/clob.md` gilt verschärft: Private-Key-Nutzung außerhalb des
|
||||||
|
erprobten Order-Signing-Pfads. Jede Phase einzeln committen; RD-3 nie
|
||||||
|
überspringen.
|
||||||
|
2. Der Worker fasst NUR Queue-Einträge an — er scannt nie selbst Positionen
|
||||||
|
(klare Verantwortung: Module erkennen, Core löst ein).
|
||||||
|
3. Alle Beträge/TxHashes loggen; Threema-Tageszusammenfassung „X Redeems, Y USDC
|
||||||
|
freigesetzt, Z manuell offen".
|
||||||
|
4. Manuelle Redeems (über die Website) müssen erkannt werden: Einlösbarkeits-Check
|
||||||
|
in 2.5 markiert extern eingelöste Einträge als Done statt Failed.
|
||||||
@@ -0,0 +1,98 @@
|
|||||||
|
# Umsetzungsplan: Strategie-Drift-Erkennung für Master-Trader (B-S2)
|
||||||
|
|
||||||
|
> Stand: 2026-07-11
|
||||||
|
> Ziel: Verhaltens-Änderungen eines Masters erkennen, BEVOR sie sich im Copy-PnL
|
||||||
|
> niederschlagen. Die bestehende Auto-Pause (Copy-PnL-basiert) ist ein nachlaufender
|
||||||
|
> Indikator — bei 95-¢-Tradern sieht man den Schaden erst nach mehreren Verlusten.
|
||||||
|
> Verhalten läuft dem PnL voraus: Ein Wetter-Bot, der plötzlich Politik-Longshots
|
||||||
|
> kauft, hat die Strategie gewechselt, lange bevor die Verluste messbar sind.
|
||||||
|
> Modul: PolyTrader.Modules.CopyTrading (baut auf vorhandenem MasterTraderAnalyticsJob auf).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Der Verhaltens-Fingerprint
|
||||||
|
|
||||||
|
Je Master werden zwei Fenster verglichen: **Referenz** (30 Tage bzw. die von
|
||||||
|
Predictalytics gelieferte Baseline) vs. **aktuell** (7 Tage). Datenquelle: die
|
||||||
|
Activity-/History-Daten, die der `MasterTraderAnalyticsJob` bereits lädt
|
||||||
|
(`mod_copytrading_mt_history` + Data-API-Activity; für Preisband/Größe die
|
||||||
|
Activity-Items — Felder existieren in den bereits geparsten JSONs).
|
||||||
|
|
||||||
|
Fingerprint-Metriken (pure Klasse `Logic/TraderFingerprint.cs`, voll unit-getestet):
|
||||||
|
|
||||||
|
| Metrik | Definition | Drift-Beispiel |
|
||||||
|
|---|---|---|
|
||||||
|
| `TradesPerWeek` | Trade-Frequenz | Bot-Betreiber wechselt von 40 auf 400/Woche |
|
||||||
|
| `CategoryMix` | Einsatz-Anteil je Kategorie (Vektor) | Wetter-Bot kauft plötzlich Politik |
|
||||||
|
| `PriceBandMix` | Einsatz-Anteil je Einstiegs-Preisband (10-¢-Bänder) | Favoriten-Halter kauft Longshots |
|
||||||
|
| `MedianHoldHours` | Median Haltedauer (Kauf→Close/Resolution) | Halter wird Day-Trader |
|
||||||
|
| `SellRatio` | Anteil aktiv verkaufter Positionen | „Stur-Halter" beginnt zu verkaufen |
|
||||||
|
| `SizeP90Rel` | 90. Perzentil Positionsgröße relativ zur Referenz | Martingale-/Tilt-Muster |
|
||||||
|
|
||||||
|
### Drift-Score
|
||||||
|
|
||||||
|
Pro Metrik eine normierte Abweichung (für Anteils-Vektoren: L1-Distanz / 2 → 0..1;
|
||||||
|
für Skalare: `|akt − ref| / max(ref, ε)` gekappt auf 1). Gesamt:
|
||||||
|
|
||||||
|
```
|
||||||
|
DriftScore = gewichtete Summe (Default-Gewichte: CategoryMix 0.3, PriceBandMix 0.25,
|
||||||
|
SellRatio 0.2, TradesPerWeek 0.1, MedianHoldHours 0.1, SizeP90Rel 0.05)
|
||||||
|
```
|
||||||
|
|
||||||
|
Schwellen (global in `CopyTradingState`, per PropertyGrid änderbar, mit
|
||||||
|
[Description]): `DriftWarnScore` (Default 0.25) und `DriftPauseScore` (Default 0.5).
|
||||||
|
**Mindeststichprobe:** unter 10 Trades im 7-Tage-Fenster keine Bewertung (Rauschen).
|
||||||
|
|
||||||
|
## 2. Aktionen bei Drift
|
||||||
|
|
||||||
|
| Stufe | Bedingung | Aktion |
|
||||||
|
|---|---|---|
|
||||||
|
| Beobachten | Score < Warn | nichts; Score in UI-Spalte sichtbar |
|
||||||
|
| **Warnen** | Warn ≤ Score < Pause | Threema-Meldung mit den 2 größten Abweichungen („Kategorie-Mix: Wetter 90→40 %, Politik 0→45 %"); Master in UI gelb |
|
||||||
|
| **Neu-Trades pausieren** | Score ≥ Pause UND `AutoPauseEnabled` | NEUE BUYs dieses Masters aussetzen (`DriftPaused`-Flag auf TrackedTrader, Engine-Check im BUY-Pfad analog ExitPending); offene Positionen + SELL-Handling laufen normal weiter; Threema; Reaktivierung manuell |
|
||||||
|
|
||||||
|
Bewusst: Drift pausiert nur **Neu-Käufe** — es verkauft nichts. Bestehende
|
||||||
|
Positionen sind Sache der normalen Exit-Mechanik (Halter: Resolution).
|
||||||
|
|
||||||
|
## 3. Umsetzung
|
||||||
|
|
||||||
|
### Slice D-1: Pure Logik + Persistenz
|
||||||
|
- `Logic/TraderFingerprint.cs`: `Compute(IEnumerable<TradeObservation>)` →
|
||||||
|
Fingerprint; `Drift(reference, current)` → Score + Top-Abweichungen. Unit-Tests
|
||||||
|
(Vektor-Distanzen, Mindeststichprobe, Rand: leere Referenz).
|
||||||
|
- `TrackedTrader`: Felder `FingerprintBaselineJson` (Referenz, von Predictalytics
|
||||||
|
importierbar ODER selbst aus 30 Tagen berechnet), `DriftScore`, `DriftPaused`,
|
||||||
|
`DriftDetail` (Kurztext) + Migration.
|
||||||
|
- `MasterTraderHistoryRecord` erweitern um die dafür nötigen Felder (EntryPrice-Band,
|
||||||
|
Kategorie, Size, Haltedauer), sofern noch nicht vorhanden — beim History-Download
|
||||||
|
mit befüllen (Daten sind in den API-Antworten enthalten).
|
||||||
|
|
||||||
|
### Slice D-2: Job-Integration
|
||||||
|
- Im `MasterTraderAnalyticsJob` nach dem History-Download: Fingerprint aktuell (7 T)
|
||||||
|
vs. Referenz (30 T bzw. BaselineJson) → Score, Aktionen gemäß Tabelle.
|
||||||
|
- **Frequenz:** Der Job läuft 12-stündlich — für Drift zu träge. Leichten
|
||||||
|
Stunden-Tick ergänzen (nur Fingerprint-Neuberechnung aus bereits geladenen
|
||||||
|
History-Daten, KEINE zusätzlichen API-Calls; die 12-h-Läufe aktualisieren die
|
||||||
|
Rohdaten).
|
||||||
|
- Referenz-Handhabung: Baseline wird NICHT automatisch nachgezogen, solange eine
|
||||||
|
Warnung/Pause aktiv ist (sonst „lernt" die Referenz die Drift). Nach manueller
|
||||||
|
Entwarnung: Baseline auf aktuelles 30-T-Fenster zurücksetzen (Button in UI).
|
||||||
|
|
||||||
|
### Slice D-3: Engine + UI
|
||||||
|
- Engine-BUY-Pfad: `DriftPaused`-Check (analog `IsActive`), TradeReasoning-Log.
|
||||||
|
- `MastersTradersView`: Spalten DriftScore (mit Ampelfarbe) + DriftDetail;
|
||||||
|
Kontextmenü „Drift entwarnen + Baseline zurücksetzen".
|
||||||
|
|
||||||
|
## 4. Akzeptanzkriterien
|
||||||
|
1. Unit-Tests: konstruierte Drift-Szenarien (Kategorie-Wechsel, Frequenz-Explosion,
|
||||||
|
Longshot-Umstieg) erzeugen erwartete Scores; stabile Master bleiben < Warn.
|
||||||
|
2. Simulierter Kategorie-Wechsel in Testdaten führt zu `DriftPaused` + Engine
|
||||||
|
verweigert Neu-BUY mit nachvollziehbarem Log.
|
||||||
|
3. Kein zusätzlicher Data-API-Traffic durch den Stunden-Tick (nur DB/RAM).
|
||||||
|
4. Threema-Meldungen enthalten die konkreten Top-Abweichungen, nicht nur den Score.
|
||||||
|
|
||||||
|
## 5. Abgrenzung
|
||||||
|
- Ersetzt NICHT die PnL-Auto-Pause (Phase 3.3, bleibt) — Drift ist das Frühwarnsystem,
|
||||||
|
PnL-Pause das Sicherheitsnetz.
|
||||||
|
- Sniper-Metriken (Plan Phase 3.2, Median-Haltezeit via Activity-Pagination) sind ein
|
||||||
|
Spezialfall dieses Fingerprints — bei Umsetzung zusammenlegen statt doppelt bauen.
|
||||||
Reference in New Issue
Block a user