Datos de Polymarket vs Kalshi: qué hay disponible realmente y cómo usar ambos
Polymarket y Kalshi parecen similares por fuera y exponen datos muy distintos por dentro. Aquí va el desglose honesto, venue por venue.
Polymarket es un CLOB on-chain en Polygon con un websocket que transmite order books en vivo pero sin archivo histórico de order book; Kalshi es un exchange estadounidense regulado por la CFTC con una API REST limpia y un libro yes/no de hasta 100 niveles por lado, pero tampoco entrega profundidad histórica del order book. Ambos te dan el libro en vivo y ninguno sirve su propio histórico de profundidad — y ese es el hueco que llena la captura de terceros.
Comparación lado a lado
| Polymarket | Kalshi | |
|---|---|---|
| Tipo | CLOB on-chain (Polygon) | Exchange estadounidense regulado por la CFTC |
| Datos de mercado en vivo | Websocket CLOB + REST | REST (orderbook, candlesticks, trades) |
| Forma del libro | Bid/ask por outcome | Yes/no, hasta 100 niveles por lado |
| Order book histórico | No lo sirve el exchange | No lo sirve el exchange |
| Mercados cripto | Up/down, 5m–24h | 15m, hourly, daily, weekly |
| Liquidación | Resolución / oracle | Precio de referencia publicado al vencimiento |
Polymarket: datos en vivo ricos, sin histórico de profundidad
Polymarket opera un central limit order book en Polygon. Su websocket CLOB transmite el libro y las actualizaciones de precio en vivo, y la API REST expone mercados, trades y un endpoint de prices-history. Lo que no provee es un archivo histórico de snapshots del order book — una vez que pasa una actualización del libro, el exchange no te deja reproducirla. Para backtesting que depende del libro en reposo, necesitas un proveedor que haya capturado el websocket de forma continua.
Kalshi: regulado, REST limpio, aun así sin archivo de profundidad
Kalshi es un exchange regulado por la CFTC, lo que da forma a sus datos: una API REST limpia con mercados, candlesticks, trades y un endpoint de orderbook actual, particionada en capas live e histórica. Pero la capa histórica cubre trades y candlesticks, no la profundidad completa del order book a lo largo del tiempo — y el endpoint público de orderbook es solo de estado actual. Así que, igual que con Polymarket, reproducir el libro yes/no de Kalshi tal como estaba requiere captura continua de terceros.
Trabajar con ambos en un solo esquema
Los venues difieren en forma — el bid/ask por outcome de Polymarket frente a la escalera yes/no de Kalshi —, así que unirlos por tu cuenta significa dos loaders y dos modelos de liquidación. DepthFeed normaliza ambos en un único esquema columnar: arrays de precio y tamaño de bid/ask, timestamps de exchange y de recepción en epoch-millis, y un precio de referencia del subyacente unido por snapshot, a lo largo de los siete activos cripto. El mismo código de backtest lee cualquiera de los dos venues.
La captura difiere según el venue pero el formato de salida no: Polymarket se captura por eventos desde el websocket CLOB (~10 ms de entrega en vivo en mediana, medido); Kalshi se sondea de forma continua a profundidad completa (aproximadamente cada 1.5 segundos). Ambos llegan como el mismo JSON idéntico por la API REST y el stream WebSocket en vivo.
Key takeaways
- 01Polymarket es un CLOB on-chain (Polygon); Kalshi es un exchange estadounidense regulado por la CFTC.
- 02Ambos transmiten o sirven el libro en vivo; ninguno sirve su propio histórico de profundidad del order book.
- 03Los libros de Kalshi son yes/no de hasta 100 niveles por lado; los de Polymarket son bid/ask por outcome.
- 04DepthFeed normaliza ambos en un solo esquema, de modo que un único backtest lee cualquiera de los dos venues.
Polymarket y Kalshi parecen similares por fuera y exponen datos muy distintos por dentro. Aquí va el desglose honesto, venue por venue.
Empieza gratis