Dati Polymarket vs Kalshi: cosa è davvero disponibile e come usarli entrambi
Polymarket e Kalshi sembrano simili dall'esterno, ma sotto la superficie espongono dati molto diversi. Ecco il confronto onesto, venue per venue.
Polymarket è un CLOB on-chain su Polygon, con un WebSocket che trasmette l'order book live ma senza alcun archivio storico dell'order book; Kalshi è un exchange statunitense regolamentato dalla CFTC, con una REST API pulita e un book yes/no fino a 100 levels per lato, ma anch'esso non distribuisce la profondità storica dell'order book. Entrambi forniscono il book live e nessuno dei due offre lo storico della propria profondità — ed è proprio questa la lacuna che colma la cattura di terze parti.
Confronto diretto
| Polymarket | Kalshi | |
|---|---|---|
| Tipo | CLOB on-chain (Polygon) | Exchange USA regolamentato dalla CFTC |
| Dati di mercato live | WebSocket CLOB + REST | REST (orderbook, candlesticks, trade) |
| Struttura del book | Bid/ask per outcome | Yes/no, fino a 100 levels per lato |
| Order book storico | Non fornito dall'exchange | Non fornito dall'exchange |
| Mercati crypto | Up/down, 5m–24h | 15m, orari, giornalieri, settimanali |
| Settlement | Risoluzione / oracle | Prezzo di riferimento pubblicato alla scadenza |
Polymarket: dati live ricchi, nessuno storico della profondità
Polymarket gestisce un central limit order book su Polygon. Il suo WebSocket CLOB trasmette in tempo reale gli aggiornamenti del book e dei prezzi, e la REST API espone mercati, trade e un endpoint di prices-history. Ciò che non fornisce è un archivio storico degli snapshot dell'order book: una volta passato un aggiornamento del book, l'exchange non consente di rigiocarlo. Per un backtest che dipende dal resting book serve un provider che abbia catturato il WebSocket in modo continuo.
Kalshi: regolamentato, REST pulita, ma ancora nessun archivio della profondità
Kalshi è un exchange regolamentato dalla CFTC, e questo ne plasma i dati: una REST API pulita con mercati, candlesticks, trade e un endpoint per l'orderbook corrente, suddivisa in tier live e storico. Ma il tier storico copre trade e candlesticks, non la profondità completa dell'order book nel tempo — e l'endpoint pubblico dell'orderbook restituisce solo lo stato corrente. Quindi, come per Polymarket, rigiocare il book yes/no di Kalshi così com'era richiede una cattura continua da parte di terzi.
Lavorare con entrambi in un unico schema
Le due venue differiscono nella struttura — il bid/ask per outcome di Polymarket contro il ladder yes/no di Kalshi — perciò unirle da soli significa gestire due loader e due modelli di settlement. DepthFeed normalizza entrambe in un unico schema columnar: array di prezzo e size bid/ask, timestamp di exchange e di ricezione in epoch-millis, e un prezzo di riferimento dell'underlying associato a ogni snapshot, su tutti e sette gli asset crypto. Lo stesso codice di backtest legge l'una o l'altra venue.
La cattura cambia da venue a venue, ma il formato di output no: Polymarket viene catturato in modalità event-driven dal WebSocket CLOB (consegna live con mediana di ~10 ms, misurata); Kalshi viene interrogato di continuo a piena profondità (all'incirca ogni 1.5 secondi). Entrambi arrivano come JSON identico tramite la REST API e lo stream WebSocket live.
Key takeaways
- 01Polymarket è un CLOB on-chain (Polygon); Kalshi è un exchange USA regolamentato dalla CFTC.
- 02Entrambi trasmettono o forniscono il book live; nessuno dei due offre lo storico della profondità del proprio order book.
- 03I book di Kalshi sono yes/no fino a 100 levels per lato; i book di Polymarket sono bid/ask per outcome.
- 04DepthFeed normalizza entrambi in un unico schema, così un singolo backtest legge l'una o l'altra venue.
Polymarket e Kalshi sembrano simili dall'esterno, ma sotto la superficie espongono dati molto diversi. Ecco il confronto onesto, venue per venue.
Inizia gratis