Wie man Prediction-Market-Strategien auf Polymarket & Kalshi backtestet

Was Prediction Markets beim Backtesting anders macht

Ein Prediction-Market-Kontrakt ist keine Aktie und kein Perpetual. Jedes Ergebnis wird von 0 bis 1 quotiert – seine implizierte Wahrscheinlichkeit –, und bei der Abrechnung ist eine Seite genau $1 wert und die andere $0. Krypto-Up/Down-Märkte rechnen in 5 bis 60 Minuten gegen einen Referenzkurs ab, Spreads weiten sich aus und die Tiefe dünnt sich nahe dem Schluss aus, und die gesamte Lebensdauer eines Marktes kann kürzer sein als eine einzige Kerze auf einem normalen Chart.

Diese Form ändert, was ein Backtest braucht. Einen letzten Kurs einmal pro Minute zu samplen übersieht das meiste eines Fünf-Minuten-Marktes; das Orderbuch zu ignorieren verbirgt den Spread, der das P&L auf einem Kontrakt entscheidet, der höchstens einen Dollar zahlt; und die Abrechnung falsch zu labeln dreht Gewinner in Verlierer. Der Rest dieses Leitfadens handelt davon, jedes dieser Probleme richtig anzugehen.

Schritt 1 – Vom echten Orderbuch ausgehen

Ein Backtest kann nur so ehrlich sein wie seine Daten. Man braucht das vollständige Orderbuch – jedes ruhende Bid und Ask mit seiner Größe, auf beiden Seiten –, bei jeder Änderung erfasst und nicht auf einem festen Takt, da nur ereignisgesteuerte Erfassung den gesamten Bogen eines kurzlaufenden Marktes zeigen kann. Weder Polymarket noch Kalshi stellt die eigene historische Orderbuchtiefe bereit, sodass die Replizierung des Orderbuchs wie es war einen Anbieter erfordert, der es kontinuierlich erfasst hat.

DepthFeed liefert genau das für beide Venues in einem Schema: Polymarket ereignisgesteuert aus dem CLOB-Websocket erfasst, Kalshi kontinuierlich bei voller Tiefe (bis zu 100 Levels pro Seite) abgefragt, jeder Snapshot mit Epoch-Millis-Zeitstempeln und einem zugehörigen Krypto-Referenzkurs. Ein Loader liest beide Venues.

Schritt 2 – Ausführungen gegen Tiefe modellieren, nicht gegen den Mid

Das ist der Schritt, der einen handelbaren Backtest von einem lügenden trennt. Eine marktgängige Order läuft durch das Buch – sie füllt das beste Level zuerst, dann das nächste, sodass ihr Durchschnittskurs schlechter als der Touch ist, wenn sie mehr als das oberste Level konsumiert. Eine ruhende Order tritt der Warteschlange bei und füllt nur, wenn der Markt durch ihren Kurs mit genügend Größe dahinter handelt. Alles zum Mid mit null Slippage auszuführen – der Standard der meisten oberflächlichen Backtests – überschätzt den Edge systematisch.

Auf welchem Weg auch immer, man sollte auf einer tiefenbasierten Ausführung bestehen. Bei einem Vier-Cent-Round-Trip-Spread, auf einem Kontrakt, der höchstens einen Dollar zahlt, ist der Unterschied zwischen einer Mid-Ausführung und einer echten enorm – und er kumuliert über jeden Trade.

Schritt 3 – Zum echten Ergebnis abrechnen

Da der Auszahlungsbetrag binär ist, ist die Abrechnung kein Rundungsdetail – sie ist der Großteil des P&L. Polymarket-Up/Down-Märkte rechnen gegen einen 'zu schlagenden Kurs' ab, der bei der Eröffnung gegen den finalen Referenzkurs bei Schluss festgelegt wurde; Kalshi-Kontrakte rechnen ja/nein gegen einen veröffentlichten Referenzkurs beim Ablauf ab. Gegen die echte Auflösung backtesten, nicht gegen eine Annahme, und die Verteilung sanity-checken: Über die abgerechneten Krypto-Up/Down-Märkte, die wir erfasst haben, landen Ergebnisse nahe einem Münzwurf – jeder Backtest, dessen Abrechnung weit davon abweicht, labelt wahrscheinlich Gewinner falsch.

Schritt 4 – Den Workflow wählen: No-Code oder API

Es gibt zwei Möglichkeiten, all das auf DepthFeed durchzuführen. Der No-Code-Weg ist das Backtest Lab: Coin und Zeitfenster auswählen, ein Preset oder eine kurze Regel wählen, ein Fill-Modell auswählen, und es repliziert aufgelöste Märkte und rechnet sie im Browser ab – inklusive tiefenbasierter VWAP-Ausführungen, keine Pipeline aufzubauen.

Der API-Weg ist für benutzerdefinierte Forschung in großem Maßstab: Volltiefe-Snapshots über die REST-API abrufen, das Orderbuch im eigenen Stack rekonstruieren und welches Modell auch immer laufen lassen. Da die historische REST-API und der Live-WebSocket identisches JSON ausgeben, liest der Loader, den man zum Replizieren der Geschichte schreibt, den Live-Feed unverändert – man handelt den exakten Code, den man backtestet hat.

Schritt 5 – Forward-testen, bevor echtes Geld riskiert wird

Ein Backtest ist an die Vergangenheit angepasst, wenn auch nur leicht, also ist der letzte Schritt, den Überlebenden auf Märkten forward laufen zu lassen, deren Ergebnis noch niemand kennt. Die Regel zum Paper Trading deployen – oder über einen Webhook vom eigenen Bot steuern – und sie handelt Live-Bücher mit virtuellem Kapital, führt zum echten Bid/Ask aus und rechnet automatisch bei Auflösung ab. Die Equity-Kurve, die dabei aufgebaut wird, ist die vorwärtsgewandte Evidenz, die ein Backtest nicht liefern kann.

Das schließt den Loop: Daten → ehrlicher Backtest → Forward-Test. Schlechte Ideen günstig auf historischen Daten aussieben, die Überlebenden auf Live-Paper-Bücher befördern und erst dann echtes Kapital in Betracht ziehen.

Häufige Fallstricke

• Letztpreis- oder Stundendaten: verbirgt den Spread und übersieht die Lebensdauer eines 5–60-minütigen Marktes.
• Mid-Ausführungen: null Slippage anzunehmen überschätzt den Edge erheblich bei einem Kontrakt, der höchstens $1 zahlt.
• Angenommene Abrechnung: Gewinner vom echten Referenzkurs labeln, nicht von einer Schätzung – das ist der Großteil des P&L.
• Look-ahead-Bias: nur auf Daten mit einem Empfangszeitstempel zum oder vor dem Entscheidungszeitpunkt reagieren.
• Forward-Test überspringen: ein Edge, der nur auf bereits abgerechneten Märkten existiert, überlebt möglicherweise keine Live-Märkte.