Polymarket Bot-Tutorial · Kapitel 8 von 32
Polymarket CLOB API für Bots: REST-Endpunkte für Order-Book-Snapshots, WebSocket-Subscriptions für Echtzeit-Updates, Parsing von Bids/Asks, Berechnung von Mid-Price und Depth, Code-Beispiele.
Was dieses Kapitel abdeckt
Die CLOB API ist der Ort, an dem Orders signiert, gesendet, gematcht werden und wo das Order Book lebt. Polymarket hat zwei SDK-Generationen - das veraltete v1 und das aktuelle v2. Dieses Kapitel behandelt nur v2; v1 sollte in keinem Bot auftauchen, den du 2026 auslieferst. Wir gehen den REST-Snapshot-Pfad, den WebSocket-Update-Kanal, die Parsing-Details, über die neue Builder stolpern, und die Reconnect-Logik durch, ohne die ein langlebiger Bot innerhalb weniger Stunden aus dem Takt gerät.
Dies ist Kapitel 8 unserer 32-teiligen Serie zum Aufbau eines Polymarket-Trading-Bots. Wir behandeln das Thema in den untenstehenden Abschnitten ausführlich. Die Inhalte für jeden Abschnitt werden Kapitel für Kapitel geschrieben und veröffentlicht; FAQ-Antworten und Referenzen sind bereits vollständig und spiegeln Produktionserfahrung aus dem Betrieb unseres eigenen Traders wider.
- CLOB v1 vs v2 (verwende v2)
- Order-Book-REST-Snapshot
- WebSocket-Subscriptions: Market- und User-Channels
- Parsing von Bids/Asks/Depth
- Berechnung von Mid-Price und Best Bid/Ask
- Maker Fees, Taker Fees, Rebates
- Code: WS verbinden und Price-Change-Events verarbeiten
- Reconnect und Gap-Handling
CLOB v1 vs v2 (verwende v2)
Polymarket pflegt zwei SDK-Generationen. v1 (@polymarket/clob-client auf npm, py-clob-client <0.30) ist veraltet und es fehlen mehrere Order-Typen, die 2024 hinzugefügt wurden. v2 (@polymarket/clob-client-v2 v1.0.2 in Node, py-clob-client 0.34.6+ in Python) ist der aktuelle Standard.
Drei konkrete Unterschiede. v2 unterstützt das negRisk-Flag für Multi-Outcome-Markets - erforderlich seit dem Start der NegRisk-Exchange Ende 2024. v2 liefert TypeScript-Typen für die Formen der WebSocket-Messages; v1 gibt any zurück. v2 verarbeitet den Gnosis Safe Signature-Flow vom August 2025 nativ; v1 benötigt benutzerdefiniertes Signing-Glue.
Der Rest dieses Kapitels ist durchgehend auf v2 ausgelegt. Wenn du in einem älteren Tutorial v1-Code siehst, behandle ihn zunächst als fehlerhaft, bis das Gegenteil bewiesen ist - insbesondere Order-Platzierungen gegen NegRisk-Markets werden unter v1 stillschweigend an den falschen Exchange-Contract weitergeleitet.
Order-Book-REST-Snapshot
Der REST-Snapshot-Endpunkt liefert das vollständige Buch für ein einzelnes Token zu einem bestimmten Zeitpunkt.
GET https://clob.polymarket.com/book?token_id=<ERC1155_TOKEN_ID>
Response-Shape:
{
"market": "0x...",
"asset_id": "5413...",
"timestamp": "1715600000000",
"hash": "0x...",
"bids": [{"price":"0.45","size":"120"}, {"price":"0.44","size":"380"}, ...],
"asks": [{"price":"0.47","size":"85"}, {"price":"0.48","size":"210"}, ...]
}
Preise sind Strings mit 2-3 Dezimalstellen; Sizes sind Strings, die Share-Anzahlen darstellen (nicht Dollar). Bids sind von hoch nach niedrig sortiert, Asks von niedrig nach hoch. hash ist ein Deduplizierungsmarker - wiederholte Polls eines unveränderten Books liefern denselben Hash und dein Bot kann die Verarbeitung überspringen.
Der REST-Snapshot ist die richtige Wahl für einmalige Abfragen (Price-Check bei einer Entry-Entscheidung). Für kontinuierliches Monitoring nutze den untenstehenden WebSocket-Channel.
WebSocket-Subscriptions: Market- und User-Channels
Zwei WebSocket-Channels sind wichtig.
Market-Channel: wss://ws-subscriptions-clob.polymarket.com/ws/market. Für ein oder mehrere Tokens abonnieren; Order-Book-Updates in Echtzeit erhalten.
{"type":"Market","markets":["0xCondId1","0xCondId2"]}
Messages kommen bei jeder Änderung an. Typen sind unter anderem book (vollständiger Snapshot), price_change (Delta), tick_size_change (selten) und last_trade_price (letzter Fill).
User-Channel: wss://ws-subscriptions-clob.polymarket.com/ws/user. Authentifiziert; du erhältst deine eigenen Order-Events - Fills, Partial Fills, Cancellations.
{"type":"User","auth":{"apiKey":"...","secret":"...","passphrase":"..."}}
Der User-Channel ist der sauberste Weg, einen Fill zu erkennen. Polling des Orders-REST-Endpunkts kostet mehr und kann Zustandsänderungen zwischen den Polls verpassen; das WebSocket pusht das Event in dem Moment, in dem der Matcher es bestätigt.
Parsing von Bids/Asks/Depth
Das Order Book ist eine Liste von Preisniveaus mit aggregierter Größe. Zwei Parsing-Konventionen sind entscheidend.
Order-Richtung: bids sind Kauforders (jemand möchte zu diesem Preis KAUFEN). Wenn DEIN Bot verkauft, triffst du einen Bid. Wenn dein Bot kauft, hebst du einen Ask an. Die Polymarket-UI zeigt dieselbe Richtung; manche andere Exchanges drehen sie um.
Sortierung: bids kommen absteigend sortiert an (bester Bid zuerst). asks kommen aufsteigend sortiert an (bester Ask zuerst). Best Bid ist bids[0]; Best Ask ist asks[0]. Vorsicht: Das öffentliche WebSocket sendet manchmal partielle Book-Updates, die nicht vorab sortiert sind - sortiere nach jedem Merge immer defensiv neu.
Depth auf einem Level ist der handelbare Dollar-Wert: price * size. Top-5-Level-Depth ist ein gängiger Liquiditätsindikator: sum(b.price * b.size for b in bids[:5]). Wenn die Top-5-Depth unter 100 $ liegt, ist das Book illiquide und die meisten Strategieannahmen brechen weg.
Mid-Price und Best Bid/Ask berechnen
Drei abgeleitete Preispunkte braucht dein Bot.
- Best Bid / Best Ask:
bids[0].priceundasks[0].price. Die Preise, zu denen du tatsächlich handeln kannst, pro Share. - Mid-Price:
(best_bid + best_ask) / 2. Das mathematische Zentrum des Spreads. Nützlich für Bewertung; du handelst nie zum Mid. - VWAP-Preis für Größe N: Laufe das Buch ab, bis die kumulierte Größe N erreicht, und gib den größengewichteten Durchschnittspreis zurück. Die tatsächlichen Kosten, um N Shares jetzt sofort ZU KAUFEN, inklusive Sweep in tiefere Levels.
Edge Case: Eine leere Bid- oder Ask-Seite (niemand verkauft oder niemand kauft) bedeutet, dass das Book einseitig ist. In der Marktstruktur von Polymarket passiert das bei aufgelösten oder fast aufgelösten Märkten, in denen eine Seite bei 0.999 liegt und niemand Liquidität auf der Verliererseite anbietet. Behandle best-bid = 0 oder best-ask = 1 als Signale für "nicht handeln".
Maker Fees, Taker Fees, Rebates
Polymarket verwendet ein Maker-Taker-Fee-Modell. Zahlenstand Mai 2026:
- Taker Fee: 0 (null) - Orders, die bestehende Book-Liquidität abnehmen, zahlen keine Gebühr. Beachte, dass Gas- / Network-Kosten für Proxy-Operationen anfallen.
- Maker Rebate: klein, positiv, programmatisch, pro ausgeführter ruhender Order in teilnahmeberechtigten Reward-Program-Markets ausgezahlt. Nicht alle Markets haben Rewards.
- NegRisk-Markets: gleiche Gebührenstruktur, aber auf einem separaten Exchange-Contract; Rewards laufen separat auf.
Die Null-Taker-Fee macht Polymarket deutlich anders als traditionelle CFD-Venues - der Großteil der Trading-"Kosten" ist der Bid-Ask-Spread selbst, nicht eine explizite Fee. Für eine Strategie, die bei jedem Trade den Spread kreuzt, ist die Spread-Steuer die echte Kostenposition; rechne bei typischen Books mit 1-3 Cents Round-Trip, bei illiquiden entsprechend mehr.
Maker Rebates lohnen sich nur dann wirklich, wenn liqudity-rewards-eligible Markets mit den Strategieideen zusammenfallen. Kapitel 19 behandelt Liquidity-Rewards-Farming als eigenen Ansatz.
Code: WS verbinden und Price-Change-Events verarbeiten
Minimales Node-Beispiel: verbinden, abonnieren, jedes Price-Change-Event für ein Token loggen.
import WebSocket from "ws";
const ws = new WebSocket("wss://ws-subscriptions-clob.polymarket.com/ws/market");
ws.on("open", () => {
ws.send(JSON.stringify({ type: "Market", markets: ["<CONDITION_ID>"] }));
});
ws.on("message", (data) => {
const msg = JSON.parse(data.toString());
if (msg.event_type === "price_change") {
console.log("price_change", msg.asset_id, msg.changes);
} else if (msg.event_type === "book") {
console.log("book snapshot", msg.bids?.[0], msg.asks?.[0]);
}
});
ws.on("close", () => console.log("closed"));
ws.on("error", (e) => console.error("err", e.message));
Abonniere bequem bis zu etwa 30 Tokens pro WebSocket-Verbindung. Darüber hinaus solltest du auf mehrere Verbindungen aufteilen - der Server wirft gelegentlich große Subscriptions kommentarlos weg, was zu stillen, veralteten Book-Reads führt.
Reconnect und Gap-Handling
Eine langlebige WebSocket-Verbindung wird ausfallen. Cloudflare zyklisiert Verbindungen alle paar Stunden; Netzwerke blinken; Polymarket deployt gelegentlich. Plane dafür.
Reconnect-Strategie: Bei close oder error warte mit Jitter min(2^attempt, 30) Sekunden und abonniere dann erneut. Setze den Attempt-Count nach der ersten erfolgreichen Message nach dem Reconnect zurück.
Gap-Handling ist wichtiger als Reconnect-Geschwindigkeit. Während das WebSocket getrennt war, hat sich das Book bewegt. Nach jedem Reconnect rufe den REST-Snapshot jedes abonnierten Tokens erneut ab und gleiche ab: Jede offene Position, deren Book sich spürbar bewegt hat, braucht eine erneute State-Prüfung, Exits müssen möglicherweise ausgelöst werden, Alarme könnten veraltet sein. Der Fall "Ich habe 30 Sekunden Book-Updates verpasst" ist der stille Killer langlaufender Bots - sie laufen auf veraltetem Zustand weiter und platzieren Orders zu Preisen, die nicht mehr existieren.
Defensives Muster: Snapshot von jedem abonnierten Book einmal pro Minute, unabhängig vom WebSocket-Status, und das WS als Fast-Path-Optimierung über dem Snapshot-Poll behandeln.


