Polymarket Bot Tutorial · Kabanata 3 ng 32
Piliin ang iyong Polymarket bot stack: Python (py-clob-client 0.34.6), Node.js (@polymarket/clob-client-v2 v1.0.6), o Rust (walang opisyal na SDK, gumawa sa ethers-rs). Pros, cons, latency, code samples.
Ano ang sinasaklaw ng kabanatang ito
Ang pagpili ng language ay mas hindi consequential kaysa sa pinapakitang ng karamihan ng builders. Ang Polymarket ay naglalantad ng parehong REST at WebSocket endpoints sa bawat language; ang SDK choice ay karaniwang nagpapasiya kung gaano karaming glue code ang isusulat mo mismo. Ang Python at Node ay parehong may opisyal na maintained na SDKs; ang Rust ay wala, pero feasible para sa hot path. Ang kabanatang ito ay naglalakad sa trade-offs, ipinapakita ang parehong "fetch order book" task sa bawat language para concrete ang diff, at nagtatapos sa mixed-stack pattern na ito ang karamihan ng production bots ay umaabot.
- Decision framework
- Python (default choice)
- Node.js (full-stack devs)
- Rust (latency-critical hot path)
- Setup commands per stack
- Code skeleton: fetch order book sa 3 languages
- Kailan mag-mix ng stacks (Python control plane + Rust hot path)
Decision framework
Tatlong tanong ang nag-resolve ng 90% ng stack choice.
- Mayroon ka bang strong existing skill? Kung nagsusulat ka ng Python araw-araw, isulat ang bot sa Python. Kung nagsusulat ka ng TypeScript araw-araw, isulat ang bot sa Node. Ang SDK quality differences sa ibaba ay totoo pero mas maliit kaysa sa cost ng pakikipaglaban sa unfamiliar language.
- Ang strategy ba ay latency-critical? Kung ang edge mo ay depende sa pag-react sa ibaba ng 50ms (5-minute crypto markets, market-making sa panahon ng news), ang hot path ay nakikinabang sa Rust o Go. Karamihan ng strategies ay hindi nito kailangan.
- Magpapatakbo ka ba ng higit sa isang strategy? Ang isang Python process ay maaaring komportable na pamahalaan ang 10-20 markets. Sa kabila niyan, ang async Node o split-process Python ay mas mahusay na nag-iscale.
Ang honest default para sa unang bot ay Python. Lumipat lamang kapag napilitan ito ng nasusukat na constraint.
Python (default choice)
Ang Python ay default dahil ang SDK ay ang pinaka-complete at ang iteration loop ay ang pinakamabilis. Ang py-clob-client sa version 0.34.6 (Mayo 2026) ay sumasaklaw sa bawat CLOB v2 endpoint na mahalaga: market at limit orders, FOK/FAK/GTC variants, order book reads, balance/allowance reads, at direct chain operations sa pamamagitan ng web3.py.
Pros: matured na SDK, madaling data analysis sa pandas, malaking community, web3.py para sa on-chain reads. Cons: ang async ergonomics ay awkward kumpara sa JavaScript, ang GIL ay nililimitahan ang multi-core speedups (bihirang mahalaga para sa I/O-bound bot), ang startup time sa cold containers ay mabagal.
Inirerekomenda para sa: 80% ng builders. Lalo na sinuman na ang strategy ay nag-iinvolve ng backtesting, statistical analysis, o anumang data work kasama ng execution.
Node.js (full-stack devs)
Ang Node.js ay ang pangalawang pinakamahusay na sinusuportahang stack. Ang @polymarket/clob-client-v2 sa version 1.0.6 ay sumasaklaw sa parehong endpoints bilang ang Python SDK na may TypeScript types sa lahat. Ang async ay native at mabilis; ang WebSocket handling ay excellent.
Pros: pinakamahusay na async story, native TypeScript types, malaking ecosystem para sa HTTP + WS, madaling deploy sa parehong Node runtime bilang web dashboard. Cons: ang number precision ay nangangailangan ng BigInt o string handling para sa malalaking token IDs (ERC-1155 IDs ay 256-bit), ang pandas-equivalent data tools ay mas mahina.
Inirerekomenda para sa: builders na nagmaintain na ng JavaScript stack at gustong ng isang runtime. Gayundin: sinumang nagbuo ng dashboard kasama ng bot - ang pagbabahagi ng types sa pagitan ng bot core at Next.js dashboard ay nag-aalis ng isang class ng bugs.
Rust (latency-critical hot path)
Ang Rust ay walang opisyal na Polymarket SDK. Magbuo ka laban sa V2 REST at WebSocket APIs nang direkta gamit ang reqwest (HTTP), tokio-tungstenite (WebSocket), at ethers-rs o alloy para sa signing. Halos dalawang araw ng setup work kumpara sa 30 minuto sa Python.
Pros: native EIP-712 signing nang walang JS subprocess, sub-millisecond order construction, deterministic memory profile sa ilalim ng load, walang GC pauses. Cons: walang SDK ibig sabihin nag-re-implement ka kung ano ang kinukuha ng Python users nang libre (clobToken ID parsing, response schema validation, salt/nonce management). Ang win sa latency ay 20-100ms kumpara sa tuned Python, na mahalaga lamang para sa sub-second strategies.
Inirerekomenda para sa: hot path ng market-making bot, o trade-firing leg ng news-arb bot. Halos hindi kailanman ang buong bot.
Setup commands per stack
Minimum commands sa working signed order laban sa mainnet (single CLOB v2 endpoint).
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 min Python, ~15 min Node, ~4-8 oras Rust.
Code skeleton: fetch order book sa 3 languages
Ang parehong task - fetch ang order book para sa Polymarket token - sa bawat stack. Lahat ng tatlo ay tumatama sa parehong 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]);Parehong response shape sa lahat ng tatlo. Ang cost ng Rust ay nasa lahat ng iba pa - signing, order construction, error handling - hindi sa read path.
Kailan mag-mix ng stacks (Python control plane + Rust hot path)
Ang pattern na maraming production bots ay nag-converge: Python para sa lahat ng nag-iinvolve ng decisions, Rust para sa millisecond execution leg.
Architecture: ang Python process ay nagbabasa ng market state, nag-run ng strategy logic, at nagsusulat ng maliit na command file (e.g. {"action":"buy","token":"...","size":10,"price":0.45}) sa Unix socket. Ang Rust daemon ay nakikinig sa socket na iyon, nag-sign ng order, at nag-post sa CLOB. Ang Python process ay maaaring mabagal at convenient; ang Rust daemon ay mabilis at minimal.
Ang handoff ang susi: sa pamamagitan ng pag-iisolate ng signed-order step, ang Python crash budget ay recovered nang hindi nagsasakripisyo ng latency. Ginagamit namin ang exact pattern na ito sa aming production bots - ang Python ay nag-emit ng intentions, ang Node daemon sa /tmp/clob.sock ay humahawak ng signing. Ang Node version ng daemon ay fine para sa sub-100ms; ang Rust ay kumikita lamang ng keep sa ibaba ng 50ms.
