Polymarket vs Kalshi 數據：實際能拿到什麼，又該如何同時使用兩家
Polymarket 與 Kalshi 從表面看很像，底層暴露的數據卻大不相同。這是一份誠實、逐一拆解兩家的對照說明。
Polymarket 是建在 Polygon 上的鏈上 CLOB，提供 websocket 即時串流 order book，但沒有歷史 order book 的封存；Kalshi 是受 CFTC 監管的美國交易所，有乾淨的 REST API，以及每一側最多 100 levels 的 yes/no order book，但同樣不提供歷史 order book 的深度資料。兩家都給你即時 order book，卻都不對外提供自家的深度歷史——而這正是第三方資料擷取所填補的缺口。
逐項對照
| Polymarket | Kalshi | |
|---|---|---|
| 類型 | 鏈上 CLOB（Polygon） | 受 CFTC 監管的美國交易所 |
| 即時市場數據 | CLOB websocket + REST | REST（orderbook、candlesticks、trades） |
| Order book 形態 | 每個結果各有 bid/ask | yes/no，每一側最多 100 levels |
| 歷史 order book | 交易所不提供 | 交易所不提供 |
| 加密貨幣市場 | 漲/跌，5m–24h | 15m、每小時、每日、每週 |
| 結算 | Resolution／oracle | 到期時公布的參考價 |
Polymarket：即時數據豐富，但沒有深度歷史
Polymarket 在 Polygon 上運行一套中央限價 order book（CLOB）。它的 CLOB websocket 即時串流 order book 與價格更新，REST API 則對外暴露 markets、trades，以及一個 prices-history 端點。它沒有提供的，是 order book 快照的歷史封存——一筆 order book 更新過去之後，交易所不讓你重播它。對於仰賴掛單簿（resting book）的 backtest，你需要一家持續擷取 websocket 的供應商。
Kalshi：受監管、REST 乾淨，但同樣沒有深度封存
Kalshi 是受 CFTC 監管的交易所，這一點形塑了它的數據：一套乾淨的 REST API，含 markets、candlesticks、trades，以及一個當前 orderbook 端點，並切分為 live 與 historical 兩層。但 historical 那一層涵蓋的是 trades 與 candlesticks，而非隨時間變化的完整 order book 深度——而公開的 orderbook 端點只給當前狀態。所以，就跟 Polymarket 一樣，要重播 Kalshi 當時那一刻的 yes/no order book，就需要第三方持續擷取。
用同一套 schema 同時操作兩家
兩家交易所形態不同——Polymarket 是每個結果各有 bid/ask，Kalshi 則是 yes/no 階梯——所以若你自己把它們拼在一起，等於要寫兩套 loader 與兩套結算模型。DepthFeed 把兩家正規化成同一套欄式 schema：bid/ask 的價格與數量陣列、以 epoch-millis 表示的交易所與接收時間戳，以及每筆快照各自 join 進來的標的參考價，涵蓋全部七種加密資產。同一份 backtest 程式碼即可讀取任一家交易所。
擷取方式因交易所而異，輸出格式卻一致：Polymarket 是從 CLOB websocket 以事件驅動方式擷取（即時投遞中位數約 10 ms，實測值）；Kalshi 則是以完整深度持續輪詢（約每 1.5 秒一次）。兩者都以相同的 JSON，透過 REST API 與即時 WebSocket 串流送達。
Key takeaways
- 01Polymarket 是鏈上 CLOB（Polygon）；Kalshi 是受 CFTC 監管的美國交易所。
- 02兩家都串流或提供即時 order book；卻都不提供自家的歷史 order book 深度。
- 03Kalshi 的 order book 是 yes/no、每一側最多 100 levels；Polymarket 的 order book 是每個結果各有 bid/ask。
- 04DepthFeed 把兩家正規化成同一套 schema，讓單一份 backtest 即可讀取任一家交易所。
Polymarket 與 Kalshi 從表面看很像，底層暴露的數據卻大不相同。這是一份誠實、逐一拆解兩家的對照說明。
免費開始