Polymarket Bot Tutorial · Kapitel 5 von 32
Polygon RPC-Provider-Vergleich für Polymarket Bots in 2026: Alchemy, QuickNode, Ankr, öffentliche Endpoints, self-hosted. Latenz, Rate Limits, kostenlose Tiers nutzbar für Paper Trading.
Was dieses Kapitel abdeckt
Der Polygon RPC Endpoint ist die einzige direkte Sicht deines Bots auf den On-Chain-Status - Balances, Allowances, Settlement-Bestätigungen, UMA-Events. Die eigene API von Polymarket verbirgt den Großteil davon, aber ein Production-Bot muss die On-Chain-Truth lesen, um seine eigene Buchhaltung zu verifizieren. Dieses Kapitel vergleicht die großen RPC-Provider unter Live-Load, nennt die Free-Tier-Schwellen, ab denen jeder von ihnen nicht mehr ausreicht, und endet mit dem Two-Provider-Failover-Pattern, das die meisten Bots irgendwann übernehmen.
- Was ein RPC für deinen Bot tut
- Alchemy: Free Tier und Pricing
- QuickNode: Dedicated Nodes
- Ankr: günstigstes Paid Tier
- Public Polygon RPCs (kostenlos, rate-limited)
- Self-hosted Polygon Node (wann es Sinn macht)
- Latency Benchmarks (US-East vs EU)
- Failover-Patterns
Was ein RPC für deinen Bot tut
Ein RPC Endpoint ist die HTTPS- oder WebSocket-URL, über die dein Bot den Polygon-Chain-Status liest und schreibt. Für einen Polymarket Bot übernimmt der RPC vier Aufgaben.
- Balances lesen: wie viel pUSD oder USDC im Proxy liegt, wie viele Outcome Tokens du tatsächlich hältst. Nötig, um zu prüfen, ob die Sicht der CLOB API mit der Chain-Truth übereinstimmt.
- Allowances lesen: ob die Polymarket Contracts deine Tokens ausgeben dürfen. Eine falsch konfigurierte Allowance führt zu stillen Order-Rejections.
- Events abonnieren: UMA Optimistic Oracle Proposals und Disputes, Deposit-Bestätigungen, große On-Chain-Transfers von anderen Wallets.
- Settlement verifizieren: wenn die CLOB sagt „matched“, hat die Chain den ERC-1155-Transfer noch nicht bestätigt. Das Lesen der Chain bestätigt, dass er tatsächlich stattgefunden hat.
Der Bot signiert Orders nicht über den RPC - das Order Signing passiert lokal, und das signierte Payload wird an die CLOB HTTP API gesendet. Der RPC ist für die meisten Strategien rein ein Read- und Event-Kanal.
Alchemy: Free Tier und Pricing
Alchemy ist der am häufigsten genutzte Polygon RPC Provider unter den Polymarket-Buildern, die wir kennen. Das Free Tier deckt die meisten Paper-Trading- und kleinen Bot-Use-Cases ab: 300 Compute Units pro Sekunde, 300 Millionen pro Monat, und dasselbe Dashboard zur Bereitstellung von Polygon Mainnet- und Polygon Testnet-Endpoints.
Ein typischer Bot mit 20 Märkten, der alle 30 Sekunden Balances + UMA-Events liest, verbraucht etwa 50-80 Millionen CU/Monat und bleibt damit komfortabel unter dem Free Cap. Paid-Pläne beginnen bei etwa 50 $/Monat und kaufen in erster Linie mehr Durchsatz pro Sekunde, nicht mehr Gesamtaufrufe. Das Free-Tier-Rate-Limit ist die Grenze, an die Paper-Trading-Bots meist stoßen, nicht das monatliche Volumen.
Alchemy bietet ein nützliches Dashboard zum Prüfen fehlgeschlagener Requests und eine Latency-Aufschlüsselung pro Methode, was beim Debugging langsamer Reads hilfreich ist. Allein das Dashboard macht sie für einen ersten Bot gegenüber einem Anbieter ohne Dashboard attraktiv.
QuickNode: Dedicated Nodes
QuickNode positioniert sich für höhere Throughput-Anforderungen. Das Pricing skaliert mit dem monatlichen Request-Volumen statt mit Tiers - besonders relevant für Bots, die viele WebSocket-Event-Filter abonnieren oder umfangreiche historische Log-Queries ausführen. Die Einstiegsstufe liegt bei etwa 10-20 $/Monat und enthält WebSocket-Support, den einige kostenlose Alchemy-Tiers drosseln.
Die per-request Latenz von QuickNode aus US-East liegt typischerweise bei 5-15 ms und ist unter Last etwas besser als das Free Tier von Alchemy. Für einen Single-Strategy-Bot ist der Unterschied unsichtbar; für einen Market Maker mit 100 gequoteten Märkten kann er relevant sein. Der Access zu ihrem Archive Node (voller historischer State) ist unter den drei großen Anbietern der günstigste, wenn deine Strategie ihn benötigt.
Der Schmerzpunkt: Die JSON-RPC-Fehlermeldungen sind weniger spezifisch als bei Alchemy, sodass das Debugging länger dauert, wenn eine Methode fehlschlägt.
Ankr: günstigstes Paid Tier
Ankr bietet den günstigsten bezahlten Polygon RPC im Tier der großen Provider - ungefähr 10 $/Monat für den Einstiegs-Premium-Plan mit 1.500 CU/Sekunde. Das Free Tier hat enge Rate Limits, ist aber für Paper Trading nutzbar.
Zwei Warnungen. Erstens liefert der load-balanced Endpoint von Ankr gelegentlich leicht veraltete Blockdaten (1-2 Blöcke hinter dem Tip). Für Balance-Reads ist das in Ordnung; für Arbitrage-Strategien, die vom neuesten Block abhängen, ist es ein echtes Problem. Zweitens ist die Support-Antwortzeit langsamer als bei Alchemy oder QuickNode, wenn Knoten in einer Region ein Problem haben.
Ankr ist ein sinnvoller Primary Provider für kostensensible Bots und unabhängig vom Primary ein exzellenter Backup-Provider. Der Abschnitt unten zu Failover-Patterns erklärt, wie man sie kombiniert.
Public Polygon RPCs (kostenlos, rate-limited)
Polygon veröffentlicht mehrere kostenlose öffentliche RPC-Endpoints - polygon-rpc.com, rpc.ankr.com/polygon (public, getrennt vom paid Ankr) und einige community-gehostete. Sie funktionieren, aber mit Einschränkungen.
- Rate Limits sind aggressiv und undokumentiert. Rechne mit Throttling, wenn du dauerhaft über etwa 10 req/sec kommst.
- Kein Support, kein Dashboard. Wenn ein Endpoint ausfällt, bemerkst du es daran, dass die Error Rate deines Bots steigt.
- Häufig 1-3 Blöcke hinterher. Für nicht zeitkritische Reads in Ordnung.
Nutze öffentliche Endpoints für: Entwicklung auf einem Laptop, die dritte Stufe eines Failover-Stacks (nach zwei Paid-Providern), One-Shot-Skripte. Betreibe Live-Bot-Trading nicht primär über einen öffentlichen Endpoint.
Self-hosted Polygon Node (wann es Sinn macht)
Den eigenen Polygon Full Node zu betreiben ist machbar - Bor + Heimdall auf einem 4-vCPU-/16GB-VPS mit rund 2 TB SSD, Synchronisation in ein paar Tagen. Die Rechnung dafür oder dagegen ist einfach.
Kosten: ungefähr 40-80 $/Monat für VPS + Storage bei einem großen Host. Etwa 4x so viel wie ein komfortabler Paid-RPC-Plan.
Vorteil: keine Gebühren pro Request, keine Rate Limits und die geringstmögliche Latenz zum Chain-State (1-3 ms statt 20-50 ms über das Internet zu einem gehosteten Provider).
Nachteil: Snapshot-Management, Heimdall und Bor haben jeweils eigene Crash-Modes, und eine hängende Sync mitten im Trading führt zu stillen veralteten Reads.
Für 95 % der Builder: nicht self-hosted betreiben. Die Stunden für Node-Maintenance übersteigen die Einsparungen bei der RPC-Rechnung deutlich. Self-hosting nur dann, wenn du eine Strategie hast, bei der 30 ms Read-Latenz in PnL-Begriffen relevant sind und du die Strategie bereits bei einem gehosteten Provider validiert hast.
Latency Benchmarks (US-East vs EU)
Gemessene mediane Round-Trip-Zeiten von VPSs in drei Regionen zu jedem Provider und dessen nächstem Polygon RPC, Mai 2026.
| VPS-Region | Alchemy | QuickNode | Ankr (paid) | polygon-rpc.com |
|---|---|---|---|---|
| NY (US-East) | 14ms | 11ms | 22ms | 34ms |
| AMS (EU) | 21ms | 17ms | 28ms | 41ms |
| SG (Asia) | 97ms | 89ms | 110ms | 140ms |
Die Zahlen verschieben sich von Woche zu Woche um etwa 3 ms. Das Muster ist stabil: QuickNode und Alchemy liegen innerhalb des Messrauschens nahe beieinander; Ankr liegt konstant 5-10 ms dahinter; öffentliche Endpoints liegen 15-25 ms dahinter. In Asien gehostete Bots zahlen eine unvermeidbare Taxe von etwa 80 ms gegenüber Polygons nordamerikanisch zentriertem Backbone.
Failover-Patterns
Ein RPC ist ein Single Point of Failure. Production-Bots nutzen zwei Provider mit einer einfachen Swap-Regel.
Pattern: primärer Call gegen Provider A; bei Timeout (3 s) oder 5xx-Response Retry gegen Provider B; wenn beide fehlschlagen, 5 s schlafen und den Primary erneut versuchen. Konsekutive Primary-Failures tracken und nach 3 Failures automatisch für 60 s auf B pinnen, dann Primary erneut prüfen.
Empfohlene Kombi: Alchemy paid als Primary, Ankr free oder öffentlicher Polygon Endpoint als Backup. Sie nutzen unterschiedliche Upstream Node Operators, sodass ein Ausfall bei einem selten mit dem anderen korreliert ist. Vermeide zwei Endpoints desselben Providers (z. B. zwei Alchemy-Keys) - das bringt keine echte Redundanz.
Implementierung: ein dünner Wrapper um web3.py oder ethers.js, der bei jedem Call zwischen Providern auswählt. Etwa 30 Zeilen Code; amortisiert sich beim ersten regionalen Ausfall eines Providers.
