DepthFeed/Both venues·So sánh

Dữ liệu Polymarket vs Kalshi: Thực sự có gì, và cách dùng cả hai

Polymarket và Kalshi nhìn bề ngoài rất giống nhau nhưng lại cung cấp dữ liệu hoàn toàn khác nhau bên dưới. Đây là phân tích trung thực, theo từng sàn.

DepthFeed··8 min

Polymarket là một CLOB on-chain trên Polygon với một websocket phát trực tiếp order book live nhưng không có kho lưu trữ lịch sử order book; Kalshi là một sàn giao dịch Mỹ được CFTC quản lý với REST API gọn gàng và sổ lệnh yes/no lên đến 100 levels mỗi bên, nhưng cũng không cung cấp độ sâu (depth) lịch sử của order book. Cả hai đều cho bạn order book live và không sàn nào phục vụ lịch sử depth của chính mình — đó chính là khoảng trống mà việc thu thập (capture) của bên thứ ba lấp đầy.

So sánh song song

PolymarketKalshi
Loại hìnhCLOB on-chain (Polygon)Sàn giao dịch Mỹ được CFTC quản lý
Dữ liệu thị trường liveCLOB websocket + RESTREST (orderbook, candlesticks, trades)
Hình dạng sổ lệnhBid/ask theo từng outcomeYes/no, lên đến 100 levels mỗi bên
Order book lịch sửSàn không phục vụSàn không phục vụ
Thị trường cryptoUp/down, 5m–24h15m, theo giờ, theo ngày, theo tuần
Thanh toánResolution / oracleGiá tham chiếu công bố tại thời điểm đáo hạn

Polymarket: dữ liệu live phong phú, không có lịch sử depth

Polymarket vận hành một sổ lệnh giới hạn tập trung (central limit order book) trên Polygon. CLOB websocket của nó phát trực tiếp các cập nhật order book và giá, còn REST API thì cung cấp markets, trades và một endpoint prices-history. Thứ mà nó không cung cấp là kho lưu trữ lịch sử các snapshot order book — một khi cập nhật sổ lệnh đã trôi qua, sàn không cho bạn phát lại (replay) nó. Đối với backtest phụ thuộc vào sổ lệnh đang chờ khớp (resting book), bạn cần một nhà cung cấp đã thu thập websocket một cách liên tục.

Kalshi: được quản lý, REST gọn gàng, vẫn không có kho lịch sử depth

Kalshi là một sàn giao dịch được CFTC quản lý, điều này định hình dữ liệu của nó: một REST API gọn gàng với markets, candlesticks, trades và một endpoint orderbook hiện tại, được phân thành tầng live và tầng lịch sử. Nhưng tầng lịch sử chỉ bao gồm trades và candlesticks, chứ không phải toàn bộ độ sâu order book theo thời gian — và endpoint orderbook công khai chỉ phản ánh trạng thái hiện tại. Vì vậy, giống như Polymarket, việc phát lại sổ lệnh yes/no của Kalshi đúng như nó từng có đòi hỏi phải có capture liên tục từ bên thứ ba.

Làm việc với cả hai trong một schema

Hai sàn khác nhau về hình dạng — bid/ask theo từng outcome của Polymarket so với thang yes/no của Kalshi — nên việc tự ghép chúng lại với nhau đồng nghĩa với hai bộ loader và hai mô hình thanh toán. DepthFeed chuẩn hóa cả hai vào một schema dạng cột (columnar): các mảng giá và khối lượng bid/ask, các timestamp exchange và receive dạng epoch-millis, cùng một giá tham chiếu của tài sản cơ sở được join theo từng snapshot, trên toàn bộ bảy tài sản crypto. Cùng một đoạn code backtest đọc được sàn nào cũng được.

Cách capture khác nhau theo từng sàn nhưng định dạng đầu ra thì không: Polymarket được capture theo sự kiện (event-driven) từ CLOB websocket (trung vị ~10 ms cho phân phối live, đã đo); Kalshi được poll liên tục ở độ sâu đầy đủ (khoảng mỗi 1.5 giây). Cả hai đều đến dưới dạng JSON giống hệt nhau qua REST API và luồng WebSocket live.

Key takeaways

  • 01Polymarket là một CLOB on-chain (Polygon); Kalshi là một sàn giao dịch Mỹ được CFTC quản lý.
  • 02Cả hai đều phát trực tiếp hoặc phục vụ order book live; không sàn nào phục vụ lịch sử depth order book của chính mình.
  • 03Sổ lệnh Kalshi là yes/no lên đến 100 levels mỗi bên; sổ lệnh Polymarket là bid/ask theo từng outcome.
  • 04DepthFeed chuẩn hóa cả hai vào một schema để một đoạn backtest duy nhất đọc được cả hai sàn.

Polymarket và Kalshi nhìn bề ngoài rất giống nhau nhưng lại cung cấp dữ liệu hoàn toàn khác nhau bên dưới. Đây là phân tích trung thực, theo từng sàn.

Bắt đầu miễn phí

Giải đáp thắc mắc.

Không sàn nào phục vụ lịch sử depth order book của chính mình. Websocket của Polymarket phát trực tiếp order book live và REST API của Kalshi trả về orderbook hiện tại, nhưng để phát lại sổ lệnh đang chờ khớp đúng như nó từng có tại một thời điểm trong quá khứ, bạn cần một bên thứ ba đã capture nó liên tục, chẳng hạn như DepthFeed.