Polymarket Bot Tutorial · Kapitel 30 von 32
Production-grade Risk-Management-Code für Polymarket-Bots: Position Caps, tägliche Verlustlimits, Halt Sentinels, Fill-Rate Watchdogs, Reconcile-on-Restart, idempotent Retries. Code Patterns von einem echten Production Trader.
Was dieses Kapitel abdeckt
Risk-Code macht den Großteil eines Production Trading Bots aus. Die Strategy Logic ist der einfache Teil; die umliegenden Caps, Halts, Watchdogs und Reconciler entscheiden darüber, ob der Bot seine erste schlechte Woche überlebt. Dieses Kapitel ist das Production-grade Risk Pattern.
- Warum Risk-Code der größte Teil eines echten Trading Bots ist
- Position Caps (pro Markt, pro Strategy, gesamt)
- Täglicher Loss Kill Switch
- Halt Sentinels (dateibasierter Emergency Stop)
- Fill-Rate Watchdog
- Diary vs. On-chain beim Neustart abgleichen
- Code: Production-grade, halt-aware Loop
Warum Risk-Code der größte Teil eines echten Trading Bots ist
Eine Messung, die wir an unserem eigenen Bot-Codebase gemacht haben: 60% der LOC sind Risk-Code (Caps, Halts, Watchdogs, Reconciliation). 30% sind Strategy. 10% ist Glue.
Dieses Verhältnis stimmt. Strategy ist der einfache Teil - zu beschreiben, wann man ein- und aussteigt, passt in ein paar Dutzend Zeilen. Risk-Code ist alles andere: was zu tun ist, wenn sich der Preis schneller als erwartet gegen dich bewegt, was zu tun ist, wenn Fills ausbleiben, was zu tun ist, wenn die WebSocket-Verbindung abbricht, was zu tun ist, wenn sich die Strategy als unprofitabel erweist.
Die meisten Failure Stories von Builders haben dieselbe Struktur: Die Strategy hat funktioniert, aber der Bot hat nach einem Regimewechsel weiter gehandelt, weil kein Halt ausgelöst wurde. Schreibe die Halts, bevor du die Strategy schreibst.
Position Caps (pro Markt, pro Strategy, gesamt)
Drei Caps, im Code durchgesetzt.
- Per-market Cap: maximal $X pro Markt, unabhängig von der Edge Confidence. Typisch: $25-100 für kleine Bots, $200-500 für Production. Begrenzt den Schaden eines Fehlers bei einem einzelnen Markt.
- Per-strategy Cap: Wenn du mehrere Strategies betreibst, bekommt jede einen Anteil des Gesamtkapitals. Typisch: 30-50% pro Strategy. Verhindert, dass ein schlechter Tag einer Strategy das Kapital der anderen verbraucht.
- Total Cap: maximal % des Wallet-Bestands gleichzeitig deployt. Typisch: 50-70%. Lässt Kapital für unerwartete Chancen oder zum Auffangen eigener Buchhaltungsfehler des Bots übrig.
Alle drei Caps sollten in der Order-Placement-Funktion durchgesetzt werden, nicht nur in der Strategy Logic. Die Strategy kann einen Bug haben; das Order-Placement-Gate ist die letzte Verteidigungslinie.
Täglicher Loss Kill Switch
Die wichtigste einzelne Risk-Kontrolle: ein täglicher Loss Kill Switch.
Regel: Wenn das realisierte + unrealized PnL seit Mitternacht UTC unter -X% des täglichen Startbestands fällt, stoppt der Bot das Öffnen neuer Positionen und glättet optional bestehende Positionen. Typisches X: 5-10%.
Die Rechnung: Ein Bot mit 60% erwarteter Win Rate hat vielleicht eine 5% Chance auf eine 10-Trades-Losing-Streak. Ohne Kill Switch kumuliert sich diese Serie: $200 Verlust → Bot handelt weiter → weitere $200 Verlust → Wallet minus 40%. Wenn der Switch bei -10% auslöst, ist der schlechte Tag bei $200 gedeckelt, und morgen startet der Bot neu.
Der Switch wird serverseitig durchgesetzt: Schreibe eine Halt-Datei oder setze ein Datenbank-Flag, das der Trading Loop in jeder Iteration prüft. Neustart nur nach manueller Prüfung.
Halt Sentinels (dateibasierter Emergency Stop)
Der einfachste denkbare Halt-Mechanismus: Der Bot prüft in jeder Loop-Iteration auf eine Datei (z. B. /opt/pmt/HALT) und stoppt das Trading, wenn die Datei existiert.
def trading_loop():
while True:
if os.path.exists("/opt/pmt/HALT"):
log("HALT file detected, sleeping")
time.sleep(30)
continue
run_one_iteration()
time.sleep(5)Um von überall aus sofort zu stoppen (SSH, Telegram bot, Monitoring-System): touch /opt/pmt/HALT. Um fortzufahren: rm /opt/pmt/HALT.
Der dateibasierte Ansatz ist absichtlich Low-tech, weil er unter Bedingungen funktioniert, in denen ausgefeiltere Halt-Mechanismen versagen: wenn der Bot teilweise abgestürzt ist, wenn die Datenbank nicht erreichbar ist, wenn der API Key rate-limited ist. Dateisystemzugriff ist immer verfügbar.
Fill-Rate Watchdog
Die Strategy geht davon aus, dass FOK Orders mit einer bestimmten Rate gefüllt werden (oft 60-80%). Wenn die Rate deutlich sinkt, hat sich etwas geändert: Market Maker haben sich zurückgezogen, deine Strategy wurde erkannt, ein API-Problem läuft. Unabhängig vom Grund ist die Annahme, auf der die PnL-Rechnung der Strategy beruhte, kaputt.
Watchdog-Logik: rollende 24-Stunden-Fill-Rate. Wenn < 30% (oder 50% des Erwartungswerts), Alarm + Auto-Halt. Wiederaufnahme nur nach manueller Prüfung.
Der Watchdog ist auch als Diagnose nützlich. Ein plötzlicher Rückgang der Fill-Rate korreliert meist mit einem externen Ereignis (Polymarket Deploy, Polygon Congestion, dein IP bekommt ein Rate Limit), über das du unabhängig vom Trading-Impact Bescheid wissen willst.
Diary vs. On-chain beim Neustart abgleichen
Der Bot führt ein Diary der Positionen, die er zu halten glaubt. Die Chain hält die Wahrheit fest. Beide sollten immer übereinstimmen; wenn das nicht der Fall ist, arbeitet der Bot auf einer falschen Annahme und handelt falsch.
Reconciliation-Logik: Bei jedem Neustart und einmal pro Stunde während des normalen Betriebs On-chain-Bestände für jedes Token abrufen, das der Bot berührt hat. Mit dem Diary vergleichen; Alarm + Halt, wenn der Bestand eines Tokens um mehr als die Rundungstoleranz abweicht.
Die häufigste Ursache für Abweichungen ist eine erfolgreiche Order, die der API-Call des Bots verpasst hat (Timeout, Retry nie protokolliert). Die Chain hat die Position; der Bot glaubt, er hat sie nicht. Ohne Reconciliation postet der Bot den Take-profit-Exit nicht und die Position läuft bis zur Resolution durch.
Code: Production-grade, halt-aware Loop
Referenz: der Production Trading Loop mit allen eingebauten Risk Controls.
def production_loop():
while True:
# Halt checks
if os.path.exists("/opt/pmt/HALT"):
sleep_with_log(30); continue
if daily_pnl_below_threshold():
create_halt("daily PnL kill"); continue
# Reconcile every hour
if now() - last_reconcile > 3600:
ok = reconcile_diary_vs_chain()
last_reconcile = now()
if not ok: create_halt("reconciliation failed"); continue
# Fill-rate watchdog
if recent_fill_rate() < 0.30:
create_halt("fill rate collapse"); continue
# Strategy
try:
run_strategy_once()
except Exception as e:
log_exception(e)
if consecutive_exceptions >= 5:
create_halt(f"exceptions: {e}"); continue
time.sleep(5)Das Pattern: Jede Iteration läuft durch das Gate. Strategy-Bugs können die Controls konstruktionsbedingt nicht umgehen.
