آموزش Polymarket Bot · فصل 3 از 32
استک Polymarket bot خود را انتخاب کنید: Python (py-clob-client 0.34.6)، Node.js (@polymarket/clob-client-v2 v1.0.6)، یا Rust (بدون SDK رسمی، بر پایه ethers-rs). مزایا، معایب، latency، نمونه کد.
این فصل چه مواردی را پوشش میدهد
انتخاب زبان خیلی کماهمیتتر از چیزی است که بیشتر سازندگان فکر میکنند. Polymarket همان endpoints REST و WebSocket را برای هر زبانی ارائه میدهد؛ انتخاب SDK بیشتر تعیین میکند که چقدر glue code باید خودتان بنویسید. Python و Node هر دو SDK رسمی و نگهداریشده دارند؛ Rust چنین چیزی ندارد، اما برای hot path کاملاً شدنی است. این فصل trade-offها را بررسی میکند، همان کار "fetch order book" را در هر زبان نشان میدهد تا تفاوتها ملموس شود، و در پایان به یک mixed-stack pattern میرسد که در عمل اکثر botهای production به آن میرسند.
- Decision framework
- Python (default choice)
- Node.js (full-stack devs)
- Rust (latency-critical hot path)
- Setup commands per stack
- Code skeleton: fetch order book in 3 languages
- When to mix stacks (Python control plane + Rust hot path)
Decision framework
سه سؤال، 90% انتخاب stack را مشخص میکنند.
- آیا یک skill موجود و قوی دارید؟ اگر هر روز Python مینویسید، bot را با Python بنویسید. اگر هر روز TypeScript مینویسید، bot را با Node بنویسید. تفاوت کیفیت SDKها در ادامه واقعی است، اما از هزینه جنگیدن با یک زبان ناآشنا کمتر است.
- آیا strategy به latency حساس است؟ اگر edge شما به واکنش در کمتر از 50ms وابسته است (بازارهای crypto پنجدقیقهای، market-making هنگام خبر)، hot path از Rust یا Go سود میبرد. بیشتر strategyها به این نیاز ندارند.
- آیا بیش از یک strategy اجرا میکنید؟ یک Python process واحد میتواند بهراحتی 10-20 market را مدیریت کند. فراتر از آن، async Node یا Python با چند process جدا بهتر scale میشود.
default صادقانه برای bot اول، Python است. فقط وقتی محدودیت اندازهگیریشده شما را مجبور کرد، تغییر دهید.
Python (default choice)
Python default است چون SDK کاملتر است و iteration loop سریعتر است. py-clob-client در نسخه 0.34.6 (مه 2026) همه endpointهای مهم CLOB v2 را پوشش میدهد: market و limit order، انواع FOK/FAK/GTC، خواندن order book، خواندن balance/allowance، و عملیات مستقیم chain از طریق web3.py.
مزایا: SDK بالغ، data analysis آسان با pandas، community بزرگ، web3.py برای خواندن on-chain. معایب: ergonomics در async نسبت به JavaScript دستوپاگیرتر است، GIL سرعتگیری multi-core را محدود میکند (که برای botهای I/O-bound معمولاً مهم نیست)، زمان startup روی cold containerها کند است.
مناسب برای: 80% سازندگان. بهخصوص هر کسی که strategy او شامل backtesting، statistical analysis، یا هر کار data دیگری در کنار execution باشد.
Node.js (full-stack devs)
Node.js دومین stack با پشتیبانی بهتر است. @polymarket/clob-client-v2 در نسخه 1.0.6 همان endpointهای Python SDK را با TypeScript types در سراسر آن پوشش میدهد. Async بومی و سریع است؛ handling مربوط به WebSocket عالی است.
مزایا: بهترین story برای async، TypeScript types بومی، ecosystem بزرگ برای HTTP + WS، deploy آسان روی همان Node runtime که dashboard وب هم از آن استفاده میکند. معایب: دقت عددی برای token IDهای بزرگ نیاز به BigInt یا handling بهصورت string دارد (ERC-1155 IDها 256-bit هستند)، ابزارهای دادهای همسطح pandas ضعیفترند.
مناسب برای: سازندگانی که از قبل یک JavaScript stack را نگه میدارند و یک runtime میخواهند. همچنین هر کسی که همزمان با bot یک dashboard میسازد - sharing typeها بین core bot و یک Next.js dashboard یک کلاس از bugها را حذف میکند.
Rust (latency-critical hot path)
Rust هیچ official Polymarket SDK ندارد. شما مستقیماً با V2 REST و WebSocket APIها با استفاده از reqwest (HTTP)، tokio-tungstenite (WebSocket)، و ethers-rs یا alloy برای signing کار میکنید. این یعنی حدود دو روز زمان setup در برابر 30 دقیقه در Python.
مزایا: EIP-712 signing بومی بدون subprocess جاوااسکریپت، ساخت order در sub-millisecond، memory profile قابل پیشبینی زیر load، بدون pause ناشی از GC. معایب: چون SDK وجود ندارد، باید چیزهایی را که Python کاربران رایگان میگیرند خودتان پیادهسازی کنید (parsing شناسه clobToken، اعتبارسنجی schema پاسخ، مدیریت salt/nonce). سود latency چیزی حدود 20-100ms نسبت به Python بهینهشده است، که فقط برای strategyهای زیر-ثانیهای مهم میشود.
مناسب برای: hot path یک market-making bot، یا بخش اجرای معامله در یک news-arb bot. تقریباً هیچوقت کل bot نیست.
Setup commands per stack
حداقل commandها برای رسیدن به یک signed order کارکردی روی mainnet (یک endpoint واحد CLOB v2).
Python:
python -m venv venv && source venv/bin/activate
pip install py-clob-client==0.34.6 web3 python-dotenv
# Set POLYGON_RPC, PRIVATE_KEY, POLY_FUNDER in .envNode:
npm init -y
npm install @polymarket/[email protected] ethers dotenv
# Set POLYGON_RPC, PRIVATE_KEY, POLY_FUNDER in .envRust:
cargo new --bin pmt
cd pmt
cargo add tokio reqwest serde serde_json ethers alloy tungstenite tokio-tungstenite
# Hand-write signer + endpoint client; no SDK shortcut.Time-to-first-order: حدود 10 دقیقه Python، 15 دقیقه Node، 4-8 ساعت Rust.
Code skeleton: fetch order book in 3 languages
همان task - دریافت order book برای یک Polymarket token - در هر stack. هر سه به همان CLOB v2 REST endpoint وصل میشوند.
Python (py-clob-client):
from py_clob_client.client import ClobClient
client = ClobClient(host="https://clob.polymarket.com", chain_id=137)
book = client.get_order_book("<token_id>")
print(book.bids[:3], book.asks[:3])Node (@polymarket/clob-client-v2):
import { ClobClient } from "@polymarket/clob-client-v2";
const c = new ClobClient({ host: "https://clob.polymarket.com", chain: 137 });
const book = await c.getOrderBook("<token_id>");
console.log(book.bids.slice(0,3), book.asks.slice(0,3));Rust (direct HTTP):
let url = format!("https://clob.polymarket.com/book?token_id={}", token);
let book: serde_json::Value = reqwest::get(&url).await?.json().await?;
println!("{:?} {:?}", &book["bids"][..3], &book["asks"][..3]);ساختار پاسخ در هر سه یکی است. هزینه Rust تقریباً همهجای دیگر است - signing، ساخت order، error handling - نه در read path.
When to mix stacks (Python control plane + Rust hot path)
الگویی که بسیاری از botهای production به آن میرسند: Python برای هر چیزی که شامل تصمیمگیری است، Rust برای بخش اجرای میلیثانیهای.
معماری: یک Python process state بازار را میخواند، logic استراتژی را اجرا میکند، و یک فایل command کوچک (مثلاً {"action":"buy","token":"...","size":10,"price":0.45}) را به یک Unix socket مینویسد. یک Rust daemon روی آن socket listen میکند، order را sign میکند، و آن را به CLOB ارسال میکند. Python میتواند کند و راحت باشد؛ Rust daemon سریع و مینیمال است.
handoff کلید ماجراست: با جدا کردن مرحله signed-order، بودجه crash در Python بدون قربانیکردن latency بازیابی میشود. ما دقیقاً از همین pattern در botهای production خودمان استفاده میکنیم - Python intentionها را تولید میکند، یک Node daemon روی /tmp/clob.sock signing را انجام میدهد. نسخه Node این daemon برای زیر-100ms عالی است؛ Rust فقط زیر 50ms واقعاً ارزشش را نشان میدهد.
