Polymarket Bot Tutorial · Capitolo 5 di 32
Confronto dei provider RPC Polygon per i bot Polymarket nel 2026: Alchemy, QuickNode, Ankr, endpoint pubblici, self-hosted. Latenza, rate limit, free tier utilizzabile per il paper trading.
Cosa copre questo capitolo
L'endpoint RPC Polygon è l'unica vista diretta del bot sullo stato on-chain — balance, allowance, conferme di settlement, eventi UMA. L'API di Polymarket nasconde la maggior parte di tutto questo, ma un bot di produzione deve leggere la verità on-chain per verificare la propria contabilità. Questo capitolo confronta i principali provider RPC sotto carico live, dà le soglie del free tier oltre le quali ciascuno smette di funzionare e finisce con il pattern di failover a due provider che la maggior parte dei bot finisce per adottare.
Questo è il capitolo 5 della nostra serie in 32 parti sulla costruzione di un trading bot per Polymarket. Trattiamo l'argomento in profondità nelle sezioni qui sotto. Il corpo di ogni sezione viene scritto e rilasciato capitolo dopo capitolo; le risposte FAQ e i riferimenti sono già completi e riflettono l'esperienza di produzione del nostro trader interno.
- Cosa fa un RPC per il tuo bot
- Alchemy: free tier e prezzi
- QuickNode: nodi dedicati
- Ankr: tier paid più economico
- RPC pubblici Polygon (gratis, con rate limit)
- Nodo Polygon self-hosted (quando ha senso)
- Benchmark di latenza (US-East vs EU)
- Pattern di failover
Cosa fa un RPC per il tuo bot
Un endpoint RPC è l'URL HTTPS o WebSocket attraverso cui il tuo bot legge e scrive lo stato della chain Polygon. Per un bot Polymarket, l'RPC gestisce quattro compiti.
- Leggere balance: quanto pUSD o USDC c'è nel proxy, quanti outcome token detieni davvero. Necessario per verificare che la vista dell'API CLOB combaci con la verità on-chain.
- Leggere allowance: se i contratti Polymarket possono spendere i tuoi token. Un allowance configurato male produce rifiuti silenziosi degli ordini.
- Sottoscriversi a eventi: proposte e dispute dell'UMA Optimistic Oracle, conferme di deposito, grandi trasferimenti on-chain da altri wallet.
- Verificare settlement: quando il CLOB dice "matched", la chain non ha ancora confermato il trasferimento ERC-1155. Leggere la chain conferma che è davvero successo.
Il bot non firma ordini tramite l'RPC — la firma dell'ordine è fatta localmente e il payload firmato è inviato all'API HTTP del CLOB. L'RPC è puramente un canale di read-and-event per la maggior parte delle strategie.
Alchemy: free tier e prezzi
Alchemy è il provider RPC Polygon più usato tra i builder Polymarket che conosciamo. Il free tier copre la maggior parte dei casi d'uso di paper trading e bot piccoli: 300 compute unit al secondo, 300 milioni al mese, la stessa dashboard usata per provisioning di endpoint Polygon mainnet e Polygon testnet.
Un tipico bot da 20 mercati che legge balance + eventi UMA ogni 30 secondi consuma circa 50-80 milioni di CU/mese, comodamente sotto il cap free. I piani paid partono intorno a 50 $/mese e comprano principalmente throughput per secondo più alto, non più chiamate totali. Il rate limit del free tier è il vincolo che la maggior parte dei bot paper trade colpisce, non il volume mensile.
Alchemy ha una dashboard utile per ispezionare richieste fallite e un breakdown di latenza per metodo che aiuta nel debug di letture lente. La dashboard da sola vale la scelta su un provider senza dashboard per un primo bot.
QuickNode: nodi dedicati
QuickNode si posiziona per esigenze di throughput più alto. I loro prezzi scalano con il volume mensile di richieste invece che per tier — più rilevante per bot che si sottoscrivono a molti filtri di eventi WebSocket o fanno query pesanti su log storici. Il tier d'entrata è circa 10-20 $/mese e include supporto WebSocket che alcuni tier Alchemy gratuiti throttle.
La latenza per richiesta di QuickNode da US-East è tipicamente 5-15ms, leggermente migliore del free tier di Alchemy sotto carico. Per un bot single-strategy la differenza è invisibile; per un market maker che quota 100 mercati può contare. Il loro accesso a archive node (stato storico completo) è il più economico tra i tre maggiori se la tua strategia lo richiede.
Il pain point: le loro risposte di errore JSON-RPC sono meno specifiche di quelle di Alchemy, quindi il debug richiede più tempo quando un metodo fallisce.
Ankr: tier paid più economico
Ankr offre l'RPC Polygon paid più economico nella categoria dei provider principali — circa 10 $/mese per il piano premium d'entrata con 1.500 CU/secondo. Il free tier ha rate limit stretti ma è praticabile per il paper trading.
Due avvertimenti. Primo, l'endpoint load-balanced di Ankr occasionalmente serve dati di blocco leggermente stantii (1-2 blocchi indietro rispetto al tip). Per le letture di balance va bene; per strategie di arbitraggio che dipendono dall'ultimo blocco, è un problema significativo. Secondo, il loro tempo di risposta del supporto è più lento di Alchemy o QuickNode quando i nodi di una regione hanno un problema.
Ankr è un primary provider sensato per bot cost-sensitive e un eccellente backup provider indipendentemente dal primary. La sezione sui pattern di failover qui sotto copre come combinarli.
RPC pubblici Polygon (gratis, con rate limit)
Polygon pubblica diversi endpoint RPC pubblici gratuiti — polygon-rpc.com, rpc.ankr.com/polygon (pubblico, separato dall'Ankr paid) e qualcuno community-hosted. Funzionano, ma con caveat.
- I rate limit sono aggressivi e non documentati. Aspettati di essere throttle se superi ~10 req/sec sostenuti.
- Niente supporto, niente dashboard. Quando un endpoint fallisce, lo scopri dall'error rate del tuo bot che sale.
- Frequentemente 1-3 blocchi indietro. Va bene per letture non time-sensitive.
Usa gli endpoint pubblici per: sviluppo su laptop, terzo tier di uno stack di failover (dopo due provider paid), script one-shot. Non lanciare trading live di un bot contro un endpoint pubblico come primary.
Nodo Polygon self-hosted (quando ha senso)
Far girare il proprio nodo full Polygon è fattibile — Bor + Heimdall su un VPS 4 vCPU/16GB con ~2 TB SSD, sync in un paio di giorni. La matematica pro/contro è semplice.
Costo: circa 40-80 $/mese in VPS + storage su un host importante. Circa 4x un piano RPC paid confortevole.
Vantaggio: zero fee per richiesta, nessun rate limit e la latenza più bassa possibile verso lo stato della chain (1-3ms vs 20-50ms su internet verso un provider hosted).
Dolore: gestione degli snapshot, Heimdall e Bor hanno ciascuno modalità di crash e uno sync stallato a metà trading produce letture stantie silenziose.
Per il 95% dei builder, non fare self-host. Le ore spese sulla manutenzione del nodo eclissano il risparmio sul conto RPC. Fai self-host solo se hai una strategia in cui 30ms di latenza di lettura contano in termini di PnL e hai già dimostrato la strategia presso un provider hosted.
Benchmark di latenza (US-East vs EU)
Mediana misurata dei round-trip da VPS in tre regioni verso l'RPC Polygon più vicino di ciascun provider, maggio 2026.
| Regione VPS | 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 |
I numeri oscillano settimana per settimana entro ~3ms. Il pattern è stabile: QuickNode e Alchemy sono nel rumore l'uno dell'altro; Ankr è consistentemente 5-10ms indietro; gli endpoint pubblici sono 15-25ms indietro. I bot ospitati in Asia pagano una tassa inevitabile di ~80ms contro la backbone Polygon centrata in Nord America.
Pattern di failover
Un RPC è un single point of failure. I bot di produzione usano due provider con una semplice regola di swap.
Pattern: chiamata primary contro il provider A; su timeout (3s) o risposta 5xx, retry contro il provider B; se entrambi falliscono, dormi 5s e ritenta il primary. Tieni traccia dei fallimenti consecutivi del primary e auto-pin su B per 60s dopo 3 fallimenti, poi sonda il primary di nuovo.
Combinazione raccomandata: Alchemy paid come primary, Ankr gratuito o endpoint Polygon pubblico come backup. Usano operatori di nodo upstream diversi, quindi un singhiozzo in uno è raramente correlato con l'altro. Evita di lanciare due endpoint dallo stesso provider (es. due key Alchemy) — non dà ridondanza reale.
Implementazione: un thin wrapper attorno a web3.py o ethers.js che seleziona tra provider ad ogni chiamata. Circa 30 righe di codice; si ripaga la prima volta che un provider ha un'outage regionale.
