Dados Polymarket vs Kalshi: o que realmente existe e como usar os dois

Lado a lado

Polymarket: dados ao vivo ricos, sem histórico de profundidade

A Polymarket opera um central limit order book na Polygon. Seu websocket CLOB transmite atualizações de book e de preço ao vivo, e a API REST expõe mercados, trades e um endpoint de prices-history. O que ela não fornece é um arquivo histórico de snapshots do order book — depois que uma atualização de book passa, a exchange não permite reproduzi-la. Para backtests que dependem do book em repouso, você precisa de um provedor que tenha capturado o websocket de forma contínua.

Kalshi: regulada, REST limpa, ainda sem arquivo de profundidade

A Kalshi é uma exchange regulada pela CFTC, o que molda seus dados: uma API REST limpa com mercados, candlesticks, trades e um endpoint de orderbook atual, particionada em camadas ao vivo e histórica. Mas a camada histórica cobre trades e candlesticks, não a profundidade completa do order book ao longo do tempo — e o endpoint público de orderbook traz apenas o estado atual. Então, como na Polymarket, reproduzir o book yes/no da Kalshi como ele era exige captura contínua de terceiros.

Trabalhando com os dois em um só schema

Os locais diferem na forma do livro, semântica de carimbo de data/hora e regras de liquidação. DepthFeed fornece observações de livro armazenadas através de REST e quadros de livro ao vivo normalizados através de WebSocket. Mapeie cada contrato documentado em seu modelo de pesquisa e mantenha referências subjacentes anuláveis e tempos específicos do local explícitos.

A captura e a cadência armazenada diferem por local. O REST histórico retorna observações armazenadas, enquanto WebSocket publica quadros de livro ao vivo; ambos usam JSON, mas seus campos e tempos não são intercambiáveis. Consulte os contratos de endpoint e a cobertura real em vez de assumir objetos idênticos ou uma latência de entrega fixa.