Dados Polymarket vs Kalshi: o que realmente existe e como usar os dois
Polymarket e Kalshi parecem semelhantes por fora e expõem dados muito diferentes por baixo. Aqui está a análise honesta, venue por venue.
A Polymarket é um CLOB on-chain na Polygon com um websocket que transmite o order book ao vivo, mas sem arquivo histórico de order book; a Kalshi é uma exchange dos EUA regulada pela CFTC com uma API REST limpa e um book yes/no de até 100 níveis por lado, mas também não fornece profundidade histórica de order book. Ambas entregam o book ao vivo e nenhuma serve o próprio histórico de profundidade — e é justamente essa lacuna que a captura de terceiros preenche.
Lado a lado
| Polymarket | Kalshi | |
|---|---|---|
| Tipo | CLOB on-chain (Polygon) | Exchange dos EUA regulada pela CFTC |
| Dados de mercado ao vivo | Websocket CLOB + REST | REST (orderbook, candlesticks, trades) |
| Formato do book | Bid/ask por outcome | Yes/no, até 100 níveis por lado |
| Order book histórico | Não servido pela exchange | Não servido pela exchange |
| Mercados de cripto | Up/down, 5m–24h | 15m, horário, diário, semanal |
| Liquidação | Resolução / oráculo | Preço de referência publicado no vencimento |
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 venues diferem no formato — o bid/ask por outcome da Polymarket versus a escada yes/no da Kalshi — então juntá-los por conta própria significa dois loaders e dois modelos de liquidação. A DepthFeed normaliza ambos em um único schema colunar: arrays de preço e tamanho de bid/ask, timestamps de exchange e de recebimento em epoch-millis e um preço de referência do ativo subjacente associado por snapshot, em todos os sete ativos de cripto. O mesmo código de backtest lê qualquer um dos venues.
A captura difere por venue, mas o formato de saída não: a Polymarket é capturada de forma orientada a eventos pelo websocket CLOB (~10 ms de entrega mediana ao vivo, medido); a Kalshi é consultada continuamente em profundidade total (aproximadamente a cada 1,5 segundos). Ambas chegam como o mesmo JSON pela API REST e pelo stream WebSocket ao vivo.
Key takeaways
- 01A Polymarket é um CLOB on-chain (Polygon); a Kalshi é uma exchange dos EUA regulada pela CFTC.
- 02Ambas transmitem ou servem o book ao vivo; nenhuma serve o próprio histórico de profundidade do order book.
- 03Os books da Kalshi são yes/no de até 100 níveis por lado; os books da Polymarket são bid/ask por outcome.
- 04A DepthFeed normaliza ambos em um único schema para que um só backtest leia qualquer venue.
Polymarket e Kalshi parecem semelhantes por fora e expõem dados muito diferentes por baixo. Aqui está a análise honesta, venue por venue.
Começar grátis