Polymarket Bot Tutorial · Kapitel 29 von 32
Baue eine Polymarket Paper-Trading-Engine, bevor du live gehst: simuliere Orders gegen reale Preise, tracke P&L, setze das 30-Trade-Gate (>=55% Win Rate, +PnL) durch, bevor echtes Kapital eingesetzt wird, und Code-Skeleton.
Was dieses Kapitel abdeckt
Paper Trading ist der unverzichtbare Schritt zwischen Strategieidee und Live-Deployment. Dieses Kapitel ist die einfache Paper-Engine, die jeden Live-Bot, den wir ausgeliefert haben, abgesichert hat - unter 200 Zeilen Python, trackt jeden Trade in einem JSONL-Logbuch und verwendet dieselben Fees/Slippage wie der Live-Pfad.
- Warum erst paper, dann live (immer)
- Das 30-Trade-Gate (verifiziert +55% WR + positive PnL)
- Eine einfache Paper-Engine bauen
- Paper-Logbuch neben Live-Logbuch tracken
- Wann Paper von Live abweicht (und warum)
- Der Übergang zu Live: kleine erste Einzahlung
- Code: minimale Paper-Engine
Warum erst paper, dann live (immer)
Das 30-Trade-Paper-Gate ist die eine Disziplin, die die 7,6% der profitablen Polymarket Trader von den 84,1% trennt, die Geld verlieren. Die meisten Builder überspringen es und zahlen Lehrgeld. Der ehrliche Grund, warum es funktioniert: Paper Trading zeigt die echte Win Rate einer Strategie über genügend Samples, um Signal von Glück zu unterscheiden.
Paper Trading zu überspringen kostet mehr, als es spart. Eine Strategie, die im Backtest profitabel aussieht, in Wirklichkeit aber nur ein Coin Flip ist, verbrennt $200-500 Live-Kapital, bevor überhaupt ein Live-Datensatz mit 30 Samples entstanden ist. Dieselben 30 Trades im Paper zu traden kostet $0.
Die Paper-Engine muss nicht hochkomplex sein. Sie muss ehrlich sein - dieselben Fees, dieselbe Slippage, dieselbe Fill-Latenz wie der Live-Pfad. Je einfacher, desto besser, denn alles Optionale wird sonst gestrichen und der Bot geht früher live, als er sollte.
Das 30-Trade-Gate (verifiziert +55% WR + positive PnL)
Das Gate ist binär: 30 geschlossene Paper-Trades, im Voraus festgelegte Erfolgskriterien (typischerweise WR ≥ 55% bei einer positiven EV-Strategie) oder kein Live-Deployment.
30 ist die minimale Stichprobengröße, bei der das 95%-Konfidenzintervall für die tatsächliche Win Rate eng genug ist, um Signal von Rauschen zu unterscheiden. Unter 30 könnten 60% beobachtete Trefferquote einer echten Rate von 45-75% entsprechen. Ab 30+ verengt sich das Intervall auf etwa 50-70% - immer noch breit, aber genug, um „die Strategie ist ein Coin Flip“ auszuschließen.
Die Erfolgskriterien müssen festgelegt werden, BEVOR der Paper-Lauf startet. Wenn man sie erst danach setzt, entsteht eine nachträgliche Rationalisierung (du wirst einen Weg finden, jeden Satz von 30 Trades als „gut genug“ zu interpretieren).
Eine einfache Paper-Engine bauen
Die Paper-Engine ist im Grunde der Live-Trading-Code, bei dem die Order-Platzierung durch einen simulierten Fill ersetzt wird. Die Simulation:
- Live Order Book lesen: derselbe Call wie beim Live-Bot.
- Fill simulieren: wenn man per FOK bei einem Preis ≥ Best Ask kauft, wird die Order zum volumengewichteten Durchschnitt der konsumierten Asks gefüllt; der Fill wird im Paper-Logbuch erfasst.
- Fees anwenden: dieselben Fees abziehen, die auch der Live-Pfad zahlen würde.
- Inventory tracken: ein paralleles Paper-Balance- und Paper-Positions-Dictionary führen.
Die ganze Engine passt in 100-200 Zeilen Python. Die wichtigste Disziplin: Jede Annahme, die der Live-Pfad macht (Fill-Rate, Latenz, Fee), muss im Paper reproduziert werden, selbst wenn sie etwas schlechter als die Realität ist - Paper sollte der Floor sein, nicht die Obergrenze.
Paper-Logbuch neben Live-Logbuch tracken
Der Paper-Trading-Lauf erzeugt ein JSONL-Logbuch, das in seiner Struktur nicht vom Live-Logbuch zu unterscheiden ist, das der Bot später schreiben wird. Dieselben Felder: timestamp, action, market_slug, side, size, price, expected_fill_price, simulated_pnl_at_exit.
Zwei Gründe, dasselbe Format zu verwenden. Erstens funktionieren die Analyse-Tools, die Live-Trades lesen (PnL-Reports, Win-Rate-Calculator), ohne Änderungen auch mit Paper. Zweitens erkennt ein späterer Vergleich von Paper und Live Abweichungen, die auf Bugs hindeuten.
Production-Tipp: Lass die Paper-Engine in per_trade_paper.jsonl im selben Verzeichnis schreiben wie das Live-per_trade.jsonl. Ein einzelner Befehl vergleicht beide: diff -y <(jq -r .market_slug per_trade.jsonl) <(jq -r .market_slug per_trade_paper.jsonl).
Wann Paper von Live abweicht (und warum)
Unvermeidliche Abweichungen zwischen Paper und Live. Drei häufige.
- Slippage: Paper füllt zum Ask-Snapshot; Live läuft durch das Order Book und kann auf dünnen Märkten 1-2c schlechter gefüllt werden. Lösung: Slippage im Paper simulieren, indem pro Trade eine Strafe in Höhe der Hälfte des Spreads addiert wird.
- Fill-Latenz: Paper füllt sofort; Live braucht 200-500 ms, in denen sich der Preis bewegen kann. Lösung: durch Warten simulieren und das Book vor dem „Fill“ im Paper erneut lesen.
- Adverse Selection: Paper geht davon aus, dass du den besten Ask bekommst; Live konkurriert mit anderen Bots, die diesen Ask womöglich bereits weggekauft haben. Lösung: schwerer zu simulieren; sei dir ehrlich darüber bewusst, dass Paper überschätzt.
Wenn Paper +5%/Monat sagt und Live bei -2%/Monat läuft, liegt die Lücke meist an einem dieser Punkte. Prüfe sie einzeln, statt anzunehmen, dass die Strategie selbst falsch war.
Der Übergang zu Live: kleine erste Einzahlung
Paper besteht 30 Trades. Live-Deployment-Plan:
- Depositiere $25-50 als Smoke-Test-Kapital. Betrachte es als Lehrgeld; wenn du es verlierst, war die Lektion den Preis wert.
- Lass den Bot im Live-Modus 5-10 Trades mit Positionen in Minimalgröße (5 Shares) laufen.
- Verifiziere, dass jeder Fill innerhalb von 2c den Paper-Erwartungen entspricht. Untersuche jede größere Abweichung, bevor du weitermachst.
- Wenn 5-10 Live-Trades mit dem Paper übereinstimmen, depositiere $200-500 und nutze normale Positionsgrößen.
- Wenn sie nicht übereinstimmen, stoppen, debuggen, fixen, von Schritt 1 neu starten.
Die häufigste Live-Paper-Differenz beim ersten Deployment ist eine fehlende Fee oder eine falsch geschätzte Slippage. Das zu beheben ist unkompliziert; die Disziplin besteht darin, die Lücke zu erkennen, bevor du Kapital skalierst.
Code: minimale Paper-Engine
Referenz: einfache Paper-Engine, die das Live-Book liest + FOK-Fill simuliert.
import json, time
PAPER_BAL = 10_000.0 # USD starting
positions = {} # token_id -> shares
def paper_fok_buy(token_id, max_price, size):
book = fetch_book(token_id)
# Walk asks, fill what we can within max_price
filled = 0; cost = 0
for level in book.asks:
px = float(level["price"])
if px > max_price: break
avail = float(level["size"])
take = min(avail, size - filled)
filled += take
cost += take * px
if filled >= size: break
if filled < size:
return {"status":"rejected","filled":0} # FOK semantics
global PAPER_BAL
PAPER_BAL -= cost
positions[token_id] = positions.get(token_id, 0) + filled
log_paper({"ts": int(time.time()), "action":"buy",
"token": token_id, "size": filled, "price": cost/filled})
return {"status":"matched","filled":filled,"cost":cost}Ergänzungen für Production: Paper-Sell-Funktion (Gegenstück zum Buy), Paper-GTC-Simulation (Order bei Preis ins Book stellen, Fill simulieren, wenn Mid den Preis erreicht), Reconciliation zwischen Paper-Logbuch und „wäre-live-gewesen“-Live-Logbuch.
