Dati Kalshi: Order Book live, API e i quattro livelli di dati

Kalshi nomina tutto con tre ticker annidati: una serie (KXBTC15M, ogni mercato Bitcoin da 15 minuti), un evento (una finestra di quella serie) e un mercato (uno strike dentro l'evento, come KXBTC15M-26JUN211530-30). Il ticker di mercato è la chiave di join; i ticker di serie ed evento sono come scoprire mercati in blocco. Sbagliare questo livello è il bug di riconciliazione più comune, perché un evento contiene diversi mercati con strike differenti e libri molto diversi.

L'API di Kalshi serve candele: apertura, massimo, minimo e chiusura del prezzo yes su periodi fissi, con volume. Per accuratezza di previsione, calibrazione e grafici questo è l'input corretto. Ciò che una candela non può dire è se la dimensione era disponibile: una chiusura di 32 centesimi significa che un'operazione è stata stampata lì, non che un ordine da 500 contratti avrebbe potuto riempirsi vicino a quel prezzo. Su un mercato da 15 minuti una serie di candele grossolana porta solo pochi punti sull'intera vita del contratto.

L'endpoint operazioni di Kalshi restituisce riempimenti eseguiti con prezzo, quantità e lato taker, e il suo livello storico li conserva. Questo copre ricerche su volume, flusso e tempistica dei riempimenti. Come ogni tape di operazioni, non può ricostruire il libro: un mercato sottile e uno profondo possono stampare le stesse operazioni, quindi lo slippage che un ordine avrebbe pagato non è derivabile solo dalle operazioni.

Un libro Kalshi è due scale di offerte: offerte sì e offerte no. Non esiste un lato di vendita separato, perché un'offerta nulla al prezzo p è un'offerta sì a 1 − p. Nel campione registrato sotto la migliore offerta sì è 0.32 e la migliore offerta nulla 0.67, quindi l'offerta sì implicita è 0.33 — un mercato da un centesimo. L'endpoint public orderbook di Kalshi restituisce questa struttura solo per il momento presente; il suo livello storico copre scambi e candele, non la profondità nel tempo. Riprodurre il libro com'era richiede una cattura continua, che è ciò che fa l'archivio di DepthFeed.

DepthFeed serve i livelli registrati su una superficie REST unica. La scoperta mercato prende un ticker di serie e un intervallo temporale e restituisce i mercati con ticker e metadati; la rotta snapshot restituisce libri registrati per un ticker di mercato esatto, con include_orderbook che espone entrambe le scale; orderbook/latest restituisce il libro registrato più recente. Il downsampling seleziona un’osservazione reale registrata invece di interpolarne una, così un gap resta un gap visibile.

Usa CSV per ispezione ed estratti piccoli, Parquet per ricerche colonnari grandi, e REST per estrazioni limitate o incrementali. Il formato dovrebbe cambiare come arrivano i byte, mai cosa significa un record: conserva il ticker di mercato, il timestamp di ricezione in millisecondi, gli array completi di prezzo e dimensione sì e no, e marcatori espliciti dove i dati mancano. Un dataset Kalshi ridotto a un prezzo per riga è una serie di candele con un altro nome.

L'archivio registrato inizia a gennaio 2026, dove è iniziata la cattura continua, non dove è iniziato Kalshi — le candele e i trade di Kalshi risalgono più indietro di qualsiasi archivio di libri di terze parti, motivo per cui gli strati sono complementari e non sostitutivi. La copertura qui riguarda i mercati crypto; le cifre descrivono campioni misurati su una coorte nominata, non una garanzia di servizio. Dove un mercato non è stato catturato, la risposta è un gap esplicito.