Polymarket 与 Kalshi 数据对比：到底能拿到什么，以及如何同时使用两家
Polymarket 和 Kalshi 从外表看很像，底层暴露的数据却大不相同。这里给出诚实、逐家拆解的对比。
Polymarket 是运行在 Polygon 上的链上 CLOB，配有一个推送实时订单簿的 websocket，但不提供历史订单簿存档；Kalshi 则是受 CFTC 监管的美国交易所，拥有干净的 REST API 以及每侧最多 100 档的 yes/no 订单簿，但同样不提供历史订单簿深度。两家都给你实时订单簿，谁都不提供自家的深度历史——这正是第三方采集所填补的空白。
并排对比
| Polymarket | Kalshi | |
|---|---|---|
| 类型 | 链上 CLOB（Polygon） | 受 CFTC 监管的美国交易所 |
| 实时市场数据 | CLOB websocket + REST | REST（订单簿、K 线、成交） |
| 订单簿形态 | 每个结果的买/卖盘 | yes/no，每侧最多 100 档 |
| 历史订单簿 | 交易所不提供 | 交易所不提供 |
| 加密市场 | 涨/跌，5m–24h | 15m、每小时、每日、每周 |
| 结算 | 裁定 / 预言机 | 到期时发布的参考价格 |
Polymarket：实时数据丰富，无深度历史
Polymarket 在 Polygon 上运行一套中央限价订单簿。它的 CLOB websocket 推送实时订单簿与价格更新，REST API 则暴露市场、成交以及一个 prices-history 端点。它没有提供的，是订单簿快照的历史存档——一旦某条订单簿更新流过，交易所就不让你回放它。对于依赖挂单簿（resting book）的回测，你需要一个持续采集了该 websocket 的数据提供方。
Kalshi：受监管、REST 干净，但依旧没有深度存档
Kalshi 是受 CFTC 监管的交易所，这塑造了它的数据形态：一套干净的 REST API，提供市场、K 线、成交以及一个当前订单簿端点，并划分为实时层与历史层。但历史层覆盖的是成交与 K 线，而非随时间推移的完整订单簿深度——而公开的订单簿端点只反映当前状态。所以，和 Polymarket 一样，要回放 Kalshi 当时的 yes/no 订单簿，仍然需要持续不断的第三方采集。
用同一套 schema 同时使用两家
两家交易所形态不同——Polymarket 是每个结果各自的买/卖盘，Kalshi 是 yes/no 阶梯——所以自己把它们拼接起来，就意味着要写两套加载器和两套结算模型。DepthFeed 把两家都归一化进同一套列式 schema：买/卖盘的价格与数量数组、epoch-millis 的交易所与接收时间戳，以及逐快照关联的底层参考价格，覆盖全部七种加密资产。同一份回测代码即可读取任一家交易所。
采集方式因交易所而异，但输出格式不变：Polymarket 以事件驱动方式从 CLOB websocket 采集（实测实时投递中位数约 10 ms）；Kalshi 则以完整深度持续轮询（大约每 1.5 秒一次）。两者都以完全相同的 JSON 通过 REST API 与实时 WebSocket 流抵达。
Key takeaways
- 01Polymarket 是链上 CLOB（Polygon）；Kalshi 是受 CFTC 监管的美国交易所。
- 02两家都推送或提供实时订单簿；谁都不提供自家的历史订单簿深度。
- 03Kalshi 订单簿是 yes/no、每侧最多 100 档；Polymarket 订单簿是每个结果的买/卖盘。
- 04DepthFeed 把两家归一化进同一套 schema，因此单份回测即可读取任一家交易所。
Polymarket 和 Kalshi 从外表看很像，底层暴露的数据却大不相同。这里给出诚实、逐家拆解的对比。
免费开始