Polymarket Bot Tutorial · Capitolo 3 di 32
Scegli lo stack del tuo bot Polymarket: Python (py-clob-client 0.34.6), Node.js (@polymarket/clob-client-v2 v1.0.2) o Rust (nessun SDK ufficiale, costruisci su ethers-rs). Pro, contro, latenza, esempi di codice.
Cosa copre questo capitolo
La scelta del linguaggio è molto meno determinante di quanto la maggior parte dei builder la tratti. Polymarket espone gli stessi endpoint REST e WebSocket a ogni linguaggio; la scelta dell'SDK determina principalmente quanto codice di glue scrivi tu. Python e Node hanno entrambi SDK mantenuti ufficialmente; Rust no, ma è fattibile per la hot path. Questo capitolo cammina attraverso i trade-off, mostra lo stesso compito "fetch dell'order book" in ciascun linguaggio così il diff è concreto e finisce con un pattern mixed-stack che è quello su cui si assesta la maggior parte dei bot di produzione.
- Framework di decisione
- Python (scelta di default)
- Node.js (full-stack dev)
- Rust (hot path latency-critical)
- Comandi di setup per stack
- Scheletro di codice: fetch dell'order book in 3 linguaggi
- Quando mixare stack (Python control plane + Rust hot path)
Framework di decisione
Tre domande risolvono il 90% della scelta dello stack.
- Hai una skill esistente forte? Se scrivi Python ogni giorno, scrivi il bot in Python. Se scrivi TypeScript ogni giorno, scrivi il bot in Node. Le differenze di qualità degli SDK qui sotto sono reali ma più piccole del costo di combattere un linguaggio non familiare.
- La strategia è latency-critical? Se il tuo edge dipende dal reagire sotto i 50ms (mercati crypto a 5 minuti, market-making durante news), la hot path beneficia di Rust o Go. La maggior parte delle strategie non ne ha bisogno.
- Girerai più di una strategia? Un singolo processo Python può comodamente gestire 10-20 mercati. Oltre, async Node o Python split-process scala meglio.
Il default onesto per un primo bot è Python. Cambia solo quando un vincolo misurato lo forza.
Python (scelta di default)
Python è il default perché l'SDK è il più completo e il loop di iterazione è il più veloce. py-clob-client alla versione 0.34.6 (maggio 2026) copre ogni endpoint CLOB v2 che conta: ordini market e limit, varianti FOK/FAK/GTC, letture dell'order book, letture di balance/allowance e operazioni dirette sulla chain via web3.py.
Pro: SDK maturo, analisi dati facile con pandas, community larga, web3.py per le letture on-chain. Contro: l'ergonomia async è goffa rispetto a JavaScript, il GIL limita lo speedup multi-core (raramente conta per un bot I/O-bound), il tempo di startup su container cold è lento.
Raccomandato per: l'80% dei builder. Specialmente chi ha strategie che includono backtesting, analisi statistica o qualsiasi data work accanto all'esecuzione.
Node.js (full-stack dev)
Node.js è lo stack con il secondo miglior supporto. @polymarket/clob-client-v2 alla versione 1.0.2 copre gli stessi endpoint dell'SDK Python con tipi TypeScript ovunque. L'async è nativo e veloce; la gestione WebSocket è eccellente.
Pro: la migliore storia async, tipi TypeScript nativi, grande ecosistema per HTTP + WS, deploy facile sullo stesso runtime Node di una web dashboard. Contro: la precisione numerica richiede BigInt o gestione a stringhe per grandi token ID (gli ID ERC-1155 sono 256-bit), gli strumenti dati equivalenti a pandas sono più deboli.
Raccomandato per: builder che già mantengono uno stack JavaScript e vogliono un runtime solo. Anche: chi costruisce una dashboard accanto al bot — condividere tipi tra il core del bot e una dashboard Next.js rimuove una classe di bug.
Rust (hot path latency-critical)
Rust non ha SDK ufficiale Polymarket. Costruisci contro le API V2 REST e WebSocket direttamente usando reqwest (HTTP), tokio-tungstenite (WebSocket) ed ethers-rs o alloy per la firma. Circa due giorni di lavoro di setup contro 30 minuti in Python.
Pro: firma EIP-712 nativa senza un subprocess JS, costruzione di ordine sub-millisecondo, profilo di memoria deterministico sotto carico, niente pause GC. Contro: niente SDK significa che reimplementi quello che gli utenti Python ottengono gratis (parsing degli ID clobToken, validazione dello schema di risposta, gestione di salt/nonce). Il vantaggio in latenza è 20-100ms rispetto a Python tunato, che conta solo per strategie sub-second.
Raccomandato per: la hot path di un bot di market-making, o la gamba di firing del trade di un bot news-arb. Quasi mai l'intero bot.
Comandi di setup per stack
Comandi minimi per un ordine firmato funzionante contro mainnet (singolo 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 .env
Node:
npm init -y
npm install @polymarket/[email protected] ethers dotenv
# Set POLYGON_RPC, PRIVATE_KEY, POLY_FUNDER in .env
Rust:
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 ore Rust.
Scheletro di codice: fetch dell'order book in 3 linguaggi
Lo stesso compito — fare fetch dell'order book per un token Polymarket — in ciascuno stack. Tutti e tre colpiscono lo stesso endpoint REST CLOB v2.
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 (HTTP diretto):
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]);
Stessa forma di risposta in tutti e tre. Il costo di Rust è ovunque altro — firma, costruzione dell'ordine, error handling — non nel read path.
Quando mixare stack (Python control plane + Rust hot path)
Il pattern su cui molti bot di produzione convergono: Python per tutto ciò che coinvolge decisioni, Rust per la gamba di esecuzione al millisecondo.
Architettura: un processo Python legge lo stato di mercato, esegue la logica di strategia e scrive un piccolo file di comando (es. {"action":"buy","token":"...","size":10,"price":0.45}) su un Unix socket. Un daemon Rust ascolta su quel socket, firma l'ordine e lo posta al CLOB. Il processo Python può essere lento e conveniente; il daemon Rust è veloce e minimale.
L'handoff è la chiave: isolando lo step dell'ordine firmato, il crash budget di Python viene recuperato senza sacrificare la latenza. Usiamo esattamente questo pattern nei nostri bot di produzione — Python emette intenzioni, un daemon Node su /tmp/clob.sock gestisce la firma. La versione Node del daemon va bene per sub-100ms; Rust guadagna la sua parte solo sotto i 50ms.











