آموزش Polymarket Bot · فصل ۵ از ۳۲

مقایسه ارائه‌دهنده‌های Polygon RPC برای botهای Polymarket در ۲۰۲۶: Alchemy، QuickNode، Ankr، endpointهای عمومی، self-hosted. Latency، rate limits، قابل‌استفاده در free-tier برای paper trading.

این فصل چه چیزهایی را پوشش می‌دهد

Polygon RPC endpoint تنها نمای مستقیم bot از وضعیت on-chain است - balanceها، allowanceها، تاییدهای settlement، رویدادهای UMA. API خود Polymarket بیشتر این موارد را پنهان می‌کند، اما یک bot production باید truth on-chain را بخواند تا bookkeeping خودش را verify کند. این فصل ارائه‌دهنده‌های اصلی RPC را زیر بار زنده مقایسه می‌کند، thresholdهای free-tier را که در آن هر کدام از کار می‌افتند مشخص می‌کند، و در پایان به الگوی failover دو-ارائه‌دهنده‌ای می‌رسد که بیشتر botها در نهایت adopt می‌کنند.

این فصل ۵ از مجموعه ۳۲ بخشی ما درباره ساختن یک Polymarket trading bot است. ما موضوع را در بخش‌های زیر به‌صورت عمیق پوشش می‌دهیم. محتوای اصلی هر بخش به‌صورت chapter-by-chapter در حال نوشته شدن و انتشار است؛ پاسخ‌های FAQ و references از قبل کامل شده‌اند و تجربه production حاصل از اجرای trader خودمان را بازتاب می‌دهند.

  • RPC برای bot شما چه کاری انجام می‌دهد
  • Alchemy: free tier و pricing
  • QuickNode: dedicated nodes
  • Ankr: ارزان‌ترین paid tier
  • Public Polygon RPCها (رایگان، با rate limit)
  • Self-hosted Polygon node (چه زمانی منطقی است)
  • Latency benchmarkها (US-East در برابر EU)
  • الگوهای failover

RPC برای bot شما چه کاری انجام می‌دهد

یک RPC endpoint آدرس HTTPS یا WebSocket است که bot شما از طریق آن وضعیت chain Polygon را می‌خواند و می‌نویسد. برای یک Polymarket bot، RPC چهار کار انجام می‌دهد.

  • خواندن balanceها: چه مقدار pUSD یا USDC در proxy قرار دارد، و واقعاً چند outcome token در اختیار دارید. این برای verify کردن این که view API CLOB با truth chain مطابقت دارد ضروری است.
  • خواندن allowanceها: این که آیا قراردادهای Polymarket می‌توانند tokenهای شما را خرج کنند یا نه. یک allowance اشتباه باعث rejectionهای خاموش order می‌شود.
  • Subscribe به eventها: proposalها و disputeهای UMA Optimistic Oracle، تاییدهای deposit، transferهای بزرگ on-chain از walletهای دیگر.
  • Verify کردن settlement: وقتی CLOB می‌گوید «matched»، chain هنوز انتقال ERC-1155 را confirm نکرده است. خواندن chain تایید می‌کند که واقعاً انجام شده است.

bot از طریق RPC order sign نمی‌کند - sign کردن order به‌صورت local انجام می‌شود و payload امضاشده به CLOB HTTP API فرستاده می‌شود. RPC برای بیشتر strategyها صرفاً یک کانال read-and-event است.

Alchemy: free tier و pricing

Alchemy پرکاربردترین ارائه‌دهنده Polygon RPC در میان Polymarket builderهایی است که ما می‌شناسیم. free tier بیشتر use caseهای paper trading و botهای کوچک را پوشش می‌دهد: 300 compute unit در ثانیه، 300 میلیون در ماه، همان dashboardی که برای provision کردن endpointهای Polygon mainnet و Polygon testnet استفاده می‌شود.

یک bot معمولی ۲۰-بازاری که balanceها + رویدادهای UMA را هر ۳۰ ثانیه می‌خواند، حدود 50-80 میلیون CU در ماه مصرف می‌کند، که به‌راحتی زیر cap رایگان است. planهای paid از حدود 50 دلار در ماه شروع می‌شوند و بیشتر throughput بالاتر در هر ثانیه می‌خرند، نه تعداد call بیشتر. rate limit free tier محدودیتی است که بیشتر botهای paper-trade به آن می‌خورند، نه حجم ماهانه.

Alchemy یک dashboard مفید برای بررسی requestهای ناموفق و یک latency breakdown به ازای هر method ارائه می‌دهد که هنگام debugging readهای کند بسیار کمک‌کننده است. همین dashboard به‌تنهایی ارزش انتخاب آن‌ها را نسبت به یک ارائه‌دهنده بدون dashboard برای bot اول دارد.

QuickNode: dedicated nodes

QuickNode خودش را برای نیازهای با throughput بالاتر position می‌کند. pricing آن بر اساس حجم ماهانه request scale می‌شود نه tierها - که بیشتر برای botهایی مهم است که تعداد زیادی WebSocket event filter subscribe می‌کنند یا queryهای سنگین historical log انجام می‌دهند. tier ورودی حدود 10-20 دلار در ماه است و پشتیبانی WebSocket را شامل می‌شود که بعضی free tierهای Alchemy آن را throttle می‌کنند.

latency هر request در US-East معمولاً 5-15ms است، که زیر load کمی بهتر از free tier Alchemy است. برای یک bot تک-strategy این تفاوت محسوس نیست؛ برای یک market-maker که 100 market را quote می‌کند می‌تواند مهم باشد. دسترسی archive node آن‌ها (state تاریخی کامل) اگر strategy شما به آن نیاز داشته باشد، از سه ارائه‌دهنده اصلی ارزان‌تر است.

نقطه درد: پاسخ‌های خطای JSON-RPC آن‌ها از Alchemy کمتر مشخص است، بنابراین وقتی یک method fail می‌شود debugging زمان بیشتری می‌برد.

Ankr: ارزان‌ترین paid tier

Ankr ارزان‌ترین Polygon RPC paid را در سطح ارائه‌دهندگان اصلی ارائه می‌دهد - حدود 10 دلار در ماه برای premium plan ابتدایی با 1,500 CU در ثانیه. free tier محدودیت‌های سختی دارد اما برای paper trading قابل استفاده است.

دو هشدار. اول، endpoint load-balanced Ankr گاهی اوقات داده‌های block کمی stale سرویس می‌دهد (1-2 block عقب‌تر از tip). برای balance readها، این خوب است؛ برای strategyهای arbitrage که به آخرین block وابسته‌اند، مشکل مهمی است. دوم، زمان پاسخ support آن‌ها وقتی nodeهای یک region مشکل دارند، از Alchemy یا QuickNode کندتر است.

Ankr برای botهای حساس به هزینه یک primary provider منطقی و به‌عنوان backup provider، صرف‌نظر از primary، عالی است. بخش failover-pattern زیر توضیح می‌دهد که چگونه آن‌ها را با هم ترکیب کنید.

Public Polygon RPCها (رایگان، با rate limit)

Polygon چندین endpoint عمومی رایگان RPC منتشر می‌کند - polygon-rpc.com، rpc.ankr.com/polygon (عمومی، جدا از Ankr paid)، و چند مورد community-hosted دیگر. آن‌ها کار می‌کنند، اما با caveatهایی.

  • rate limitها شدید و undocumented هستند. اگر به‌طور پایدار از حدود 10 req/sec بیشتر شوید، انتظار throttle داشته باشید.
  • بدون support، بدون dashboard. وقتی یک endpoint fail می‌شود، از بالا رفتن error rate botتان متوجه می‌شوید.
  • اغلب 1-3 block عقب هستند. برای readهای غیرحساس به زمان مناسب است.

از endpointهای عمومی برای این موارد استفاده کنید: development روی لپ‌تاپ، tier سوم یک failover stack (بعد از دو ارائه‌دهنده paid)، scriptهای یک‌باره. برای live bot trading از endpoint عمومی به‌عنوان primary استفاده نکنید.

Self-hosted Polygon node (چه زمانی منطقی است)

اجرای full node خودتان برای Polygon قابل انجام است - Bor + Heimdall روی یک VPS با 4 vCPU و 16GB RAM و حدود 2 ترابایت SSD، و sync شدن در چند روز. محاسبه به‌نفع یا به‌ضرر آن ساده است.

هزینه: حدود 40-80 دلار در ماه برای VPS + storage روی یک host بزرگ. تقریباً 4 برابر یک plan paid RPC راحت.

مزیت: بدون fee به ازای هر request، بدون rate limit، و کمترین latency ممکن تا وضعیت chain (1-3ms در برابر 20-50ms از طریق اینترنت به یک ارائه‌دهنده hosted).

دردسر: مدیریت snapshot، crash modeهای Heimdall و Bor، و sync متوقف‌شده در میانه trading باعث readهای stale و خاموش می‌شود.

برای 95٪ builderها، self-host نکنید. ساعت‌هایی که صرف نگهداری node می‌شود، صرفه‌جویی در bill RPC را چند برابر می‌بلعد. فقط زمانی self-host کنید که strategy شما به 30ms latency خواندن در PnL اهمیت می‌دهد و قبلاً strategy را روی یک ارائه‌دهنده hosted اثبات کرده‌اید.

Latency benchmarkها (US-East در برابر EU)

میانه round-trip time اندازه‌گیری‌شده از VPS در سه region به نزدیک‌ترین Polygon RPC هر ارائه‌دهنده، مه 2026.

region VPSAlchemyQuickNodeAnkr (paid)polygon-rpc.com
NY (US-East)14ms11ms22ms34ms
AMS (EU)21ms17ms28ms41ms
SG (Asia)97ms89ms110ms140ms

اعداد هفته‌به‌هفته در حدود 3ms بالا و پایین می‌شوند. الگو ثابت است: QuickNode و Alchemy در محدوده نویز به هم نزدیک‌اند؛ Ankr به‌طور پیوسته 5-10ms عقب‌تر است؛ endpointهای عمومی 15-25ms عقب‌تر هستند. botهای مستقر در Asia یک tax اجتناب‌ناپذیر حدود 80ms در برابر backbone متمرکز بر آمریکای شمالی Polygon پرداخت می‌کنند.

الگوهای failover

یک RPC نقطه شکست واحد است. botهای production از دو ارائه‌دهنده با یک قانون جابه‌جایی ساده استفاده می‌کنند.

الگو: درخواست اولیه به provider A؛ در صورت timeout (3 ثانیه) یا پاسخ 5xx، retry روی provider B؛ اگر هر دو fail شدند، 5 ثانیه صبر کنید و دوباره provider اصلی را امتحان کنید. تعداد شکست‌های پیاپی provider اصلی را track کنید و بعد از 3 شکست، به‌صورت خودکار برای 60 ثانیه روی B pin شوید، سپس دوباره provider اصلی را probe کنید.

ترکیب پیشنهادی: Alchemy paid به‌عنوان primary، و Ankr free یا endpoint عمومی Polygon به‌عنوان backup. آن‌ها از upstream node operatorهای متفاوتی استفاده می‌کنند، بنابراین یک hiccup در یکی به‌ندرت با دیگری همبستگی دارد. از اجرای دو endpoint از یک provider واحد (مثلاً دو Alchemy key) خودداری کنید - این کار هیچ redundancy واقعی‌ای ایجاد نمی‌کند.

پیاده‌سازی: یک wrapper نازک روی web3.py یا ethers.js که در هر call بین providerها انتخاب می‌کند. حدود 30 خط کد؛ و اولین بار که یک provider دچار outage منطقه‌ای می‌شود، هزینه‌اش را جبران می‌کند.

سؤالات متداول

آیا برای Polymarket bot خود به یک Polygon RPC paid نیاز دارم؟
برای paper trading یا botهای کم‌حجم، نه. public Polygon RPCها (polygon-rpc.com) اگر به‌طور متوسط کمتر از حدود 1 request/sec بفرستید، خوب کار می‌کنند. وقتی به چند market scale می‌کنید یا به WebSocket subscription نیاز دارید، به Alchemy، QuickNode یا Ankr بروید - free tierها بیشتر botهای retail را پوشش می‌دهند.
اگر از SDK استفاده کنم، آیا Polymarket به Polygon RPC نیاز دارد؟
CLOB SDK APIهای REST/WebSocket خود Polymarket را صدا می‌زند - آن‌ها به Polygon RPC نیاز ندارند. شما فقط برای readهای on-chain به Polygon RPC نیاز دارید (balance USDC/pUSD، eventهای قرارداد، readهای UMA oracle، جریان‌های امضای custom EIP-712). بسیاری از botها هرگز نیازی به صحبت مستقیم با Polygon ندارند.
ارزان‌ترین Polygon RPC قابل‌اعتماد چیست؟
تا سال 2026، Ankr Premium از حدود 10 دلار در ماه شروع می‌شود و تا سقف quota سخاوتمندانه، fee به ازای هر request ندارد. free tier Alchemy هم برای بیشتر botهای retail کافی است (300 میلیون compute unit در ماه). QuickNode گران‌تر است اما اگر performance قابل‌پیش‌بینی بخواهید، گزینه‌های dedicated-node دارد.
آیا می‌توانم node خودم را برای Polygon host کنم؟
بله، اما مگر این که یک bot high-frequency اجرا می‌کنید یا آنالیز سنگین on-chain انجام می‌دهید، زیاده‌روی است. یک full node برای Polygon به حدود 1 ترابایت SSD و چند هفته زمان sync نیاز دارد. هزینه disk + maintenance معمولاً برای هر bot در مقیاس retail از یک plan paid RPC بیشتر می‌شود.
به کدام WebSocket باید subscribe کنم؟
برای داده‌های order book در Polymarket، به WebSocket خود Polymarket در wss://ws-subscriptions-clob.polymarket.com/ws/market subscribe کنید. برای eventهای block در Polygon (که برای بیشتر botها نادر است)، به endpoint WS ارائه‌دهنده RPC خود subscribe کنید (مثلاً wss://polygon-mainnet.g.alchemy.com/v2/YOUR_KEY).
چطور از رسیدن به rate limit جلوگیری کنم؟
به‌شدت cache کنید (snapshotهای order book، metadata گاما)، برای داده‌های real-time به‌جای polling از WebSocket استفاده کنید، در صورت امکان read callها را batch کنید، و روی پاسخ‌های 429 backoff بگذارید. بیشتر hitهای rate limitی که می‌بینیم از loopهای بد نوشته‌شده می‌آیند، نه از demand واقعی.