Polymarket Bot Tutorial · Kabanata 5 ng 32
Comparison ng Polygon RPC providers para sa Polymarket bots noong 2026: Alchemy, QuickNode, Ankr, public endpoints, self-hosted. Latency, rate limits, free-tier na magagamit para sa paper trading.
Ano ang sinasaklaw ng kabanatang ito
Ang Polygon RPC endpoint ay ang tanging direktang view ng bot sa on-chain state - balances, allowances, settlement confirmations, UMA events. Itinatago ng sariling API ng Polymarket ang karamihan nito, pero ang production bot ay kailangang basahin ang on-chain truth para i-verify ang sariling bookkeeping. Ang kabanatang ito ay naghahambing ng major RPC providers sa ilalim ng live load, nagbibigay ng free-tier thresholds kung saan tumitigil ang bawat isa sa paggana, at nagtatapos sa two-provider failover pattern na karamihan ng bots ay eventually nag-a-adopt.
- Ano ang ginagawa ng RPC para sa iyong bot
- Alchemy: free tier at pricing
- QuickNode: dedicated nodes
- Ankr: pinakamurang paid tier
- Public Polygon RPCs (libre, rate-limited)
- Self-hosted Polygon node (kailan makatuwiran)
- Latency benchmarks (US-East vs EU)
- Failover patterns
Ano ang ginagawa ng RPC para sa iyong bot
Ang RPC endpoint ay ang HTTPS o WebSocket URL kung saan ang iyong bot ay nagbabasa at nagsusulat ng Polygon chain state. Para sa Polymarket bot, ang RPC ay humahawak ng apat na trabaho.
- Basahin ang balances: kung magkano ang pUSD o USDC ang nasa proxy, ilang outcome tokens ang aktwal na hawak mo. Kailangan para i-verify na tumutugma ang view ng CLOB API sa chain truth.
- Basahin ang allowances: kung ang Polymarket contracts ay maaaring gumastos ng iyong tokens. Ang misconfigured allowance ay gumagawa ng silent order rejections.
- Mag-subscribe sa events: UMA Optimistic Oracle proposals at disputes, deposit confirmations, malalaking on-chain transfers mula sa ibang wallets.
- I-verify ang settlement: kapag sinabi ng CLOB na "matched," hindi pa nakumpirma ng chain ang ERC-1155 transfer. Ang pagbabasa ng chain ay nagkukumpirma na talagang nangyari ito.
Hindi nag-sign ang bot ng orders sa pamamagitan ng RPC - ang order signing ay ginawa nang lokal at ang signed payload ay ipinadala sa CLOB HTTP API. Ang RPC ay purong read-and-event channel para sa karamihan ng strategies.
Alchemy: free tier at pricing
Ang Alchemy ay ang pinakaginagamit na Polygon RPC provider sa mga Polymarket builders na alam namin. Sinasaklaw ng free tier ang karamihan ng paper-trading at small-bot use cases: 300 compute units per second, 300 million per month, ang parehong dashboard na ginagamit upang mag-provision ng Polygon mainnet at Polygon testnet endpoints.
Ang tipikal na 20-market bot na nagbabasa ng balances + UMA events bawat 30 segundo ay kumukonsumo ng tinatayang 50-80 million CU/buwan, komportableng nasa ibaba ng free cap. Nagsisimula ang paid plans sa paligid ng $50/buwan at pangunahin nagbibili ng mas mataas na per-second throughput, hindi mas maraming total calls. Ang free tier rate limit ang constraint na karamihan ng paper-trade bots ay tinatamaan, hindi ang monthly volume.
Ang Alchemy ay nag-ship ng kapaki-pakinabang na dashboard para sa pag-iinspect ng failed requests at per-method latency breakdown na nakakatulong kapag nag-de-debug ng mabagal na reads. Ang dashboard mismo ay sulit na piliin sila sa isang no-dashboard provider para sa unang bot.
QuickNode: dedicated nodes
Ang QuickNode ay nag-position ng kanyang sarili para sa higher-throughput needs. Ang kanilang pricing ay nag-scale sa monthly request volume sa halip na tiers - pinaka-relevant para sa bots na nag-subscribe sa maraming WebSocket event filters o gumagawa ng heavy historical-log queries. Ang entry tier ay halos $10-20/buwan at kasama ang WebSocket support na nilil-throttle ng ilang free Alchemy tiers.
Ang per-request latency ng QuickNode mula sa US-East ay karaniwang 5-15ms, bahagyang mas mahusay kaysa sa free tier ng Alchemy sa ilalim ng load. Para sa single-strategy bot ang pagkakaiba ay hindi nakikita; para sa market-maker na nag-quote ng 100 markets ay maaaring mahalaga ito. Ang kanilang archive node access (full historical state) ay ang pinakamura sa tatlong majors kung kailangan ito ng iyong strategy.
Ang pain point: ang kanilang JSON-RPC error responses ay mas hindi specific kaysa sa Alchemy, kaya ang debugging ay umaabot nang mas matagal kapag nabigo ang isang method.
Ankr: pinakamurang paid tier
Ang Ankr ay nag-aalok ng pinakamurang paid Polygon RPC sa major-provider tier - halos $10/buwan para sa entry premium plan na may 1,500 CU/second. Ang free tier ay may tight rate limits pero workable para sa paper trading.
Dalawang babala. Una, ang load-balanced endpoint ng Ankr ay paminsan-minsan ay nag-serve ng bahagyang stale block data (1-2 blocks behind tip). Para sa balance reads, ayos iyan; para sa arbitrage strategies na umaasa sa pinakabagong block, ito ay meaningful problem. Pangalawa, ang kanilang support response time ay mas mabagal kaysa sa Alchemy o QuickNode kapag may issue sa nodes ng isang region.
Ang Ankr ay sensible primary provider para sa cost-sensitive bots at mahusay na backup provider anuman ang primary. Ang failover-pattern section sa ibaba ay sumasaklaw kung paano sila pagsamahin.
Public Polygon RPCs (libre, rate-limited)
Ang Polygon ay naglalathala ng ilang libreng public RPC endpoints - polygon-rpc.com, rpc.ankr.com/polygon (public, hiwalay sa paid Ankr), at ilang community-hosted. Gumagana sila, pero may caveats.
- Ang rate limits ay aggressive at hindi documented. Asahan na ma-throttle kung lumampas ka sa ~10 req/sec sustained.
- Walang support, walang dashboard. Kapag nabigo ang endpoint, malalaman mo sa pamamagitan ng pagtaas ng error rate ng iyong bot.
- Madalas na 1-3 blocks behind. Ayos para sa non-time-sensitive reads.
Gamitin ang public endpoints para sa: development sa laptop, ang ikatlong tier ng failover stack (pagkatapos ng dalawang paid providers), one-shot scripts. Huwag mag-run ng live bot trading laban sa public endpoint bilang primary.
Self-hosted Polygon node (kailan makatuwiran)
Ang pag-run ng iyong sariling Polygon full node ay feasible - Bor + Heimdall sa 4-vCPU/16GB VPS na may ~2 TB SSD, syncing sa loob ng ilang araw. Ang math para sa o laban dito ay simple.
Cost: halos $40-80/buwan sa VPS + storage sa major host. Mga 4x ng komportableng paid RPC plan.
Win: zero per-request fees, walang rate limits, at ang pinakamababang posibleng latency sa chain state (1-3ms vs 20-50ms sa internet sa hosted provider).
Pain: snapshot management, ang Heimdall at Bor ay parehong may crash modes, at ang stalled sync mid-trading ay gumagawa ng silent stale reads.
Para sa 95% ng builders, huwag mag-self-host. Ang mga oras na ginugol sa node maintenance ay dwarfing the RPC bill savings. Mag-self-host lamang kung mayroon kang strategy kung saan ang 30ms ng read latency ay mahalaga sa PnL terms at napatunayan mo na ang strategy sa hosted provider.
Latency benchmarks (US-East vs EU)
Nasukat na median round-trip times mula sa VPS sa tatlong regions sa pinakamalapit na Polygon RPC ng bawat provider, Mayo 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 |
Ang numbers ay nag-shift linggo-linggo sa loob ng ~3ms. Ang pattern ay stable: ang QuickNode at Alchemy ay nasa loob ng noise ng isa't isa; ang Ankr ay consistent 5-10ms behind; ang public endpoints ay 15-25ms behind. Ang Asia-hosted bots ay nagbabayad ng hindi maiiwasang ~80ms tax laban sa Polygon North-America-centric backbone.
Failover patterns
Ang isang RPC ay single point of failure. Ang production bots ay gumagamit ng dalawang providers na may simpleng swap rule.
Pattern: primary call laban sa provider A; sa timeout (3s) o 5xx response, retry laban sa provider B; kung parehong nabigo, mag-sleep 5s at i-retry ang primary. I-track ang consecutive primary failures at auto-pin sa B sa loob ng 60s pagkatapos ng 3 failures, pagkatapos ay i-probe ulit ang primary.
Inirerekomendang combo: Alchemy paid bilang primary, Ankr free o public Polygon endpoint bilang backup. Gumagamit sila ng iba't ibang upstream node operators, kaya ang hiccup sa isa ay bihirang correlated sa isa pa. Iwasan ang pag-run ng dalawang endpoints mula sa parehong provider (e.g. dalawang Alchemy keys) - wala iyong nagbibigay ng real redundancy.
Implementation: manipis na wrapper sa paligid ng web3.py o ethers.js na pumipili sa pagitan ng providers sa bawat call. Halos 30 lines ng code; nagbabayad para sa sarili nito sa unang pagkakataon na ang provider ay may regional outage.
