如何用訂單簿回測 Polymarket 策略

為什麼最後成交價回測會騙人

大多數可免費取得的 Polymarket 資料都是最後成交價，而且往往每小時才取樣一次。這樣的資料只夠畫出一張圖，僅此而已。回測要回答的是更難的問題：如果我的單在那個當下正掛著（或正好穿越價差），它會不會成交？成交多少量？又是在什麼價格成交？

要回答這個問題，你需要的是訂單簿——每一筆掛著的買價與賣價連同其數量——而不是單一數字。用中間價回測的策略，等於假設你永遠能在中間價零滑價成交，但這從來不是事實。在臨近結算時價差會放大的短天期加密貨幣市場裡，這個假設足以把一個賠錢策略，翻轉成看似賺錢的策略。

步驟一——取得完整深度的訂單簿資料

從一開始就要使用記錄雙邊完整訂單簿的資料，而且是在每次變動時擷取，而非按固定時鐘取樣。DepthFeed 直接從 CLOB websocket 以事件驅動方式擷取 Polymarket，因此每一次訂單簿與價格變動事件都會連同完整買賣價階一併記錄——不是那種每小時或每分鐘取樣、會跳過一個五分鐘市場整段生命週期的資料。

透過 REST API 拉取你想要的市場：先用 GET /v3/{coin}/markets 發掘市場，再從 /v3/{coin}/markets/{id}/snapshots 拉取深度。每一筆 snapshot 都帶有買賣價與數量陣列，外加以 epoch-millis 為單位的交易所時間戳與接收時間戳。

步驟二——重建每一刻的訂單簿

依時間戳順序重播這些 snapshot，即可重建任一瞬間當下的訂單簿狀態。由於資料是事件驅動的，事件之間的重建是精確的——沒有任何內插的猜測成分。這正是你的策略所反應的狀態：最佳買價、最佳賣價、各價位後方的深度，以及價差。

步驟三——對著真實深度模擬成交

接下來要誠實地模擬執行。一筆可立即成交的單會「走過」整本訂單簿：先吃掉最佳價位，再吃下一個，直到數量消化完畢——所以只要它吃掉的量超過最頂層，它的平均成交價就會比最佳價更差。一筆掛著的單則加入排隊，唯有當市場以足夠後方數量穿越它的價格時才會成交。

對著記錄下來的價階來估算成交量，正是整件事的重點：它給你真實的滑價與成交機率，而不是「你永遠在中間價成交」那種虛構。

步驟四——接上標的價格

Polymarket 的加密貨幣漲跌市場，是由標的資產的現貨走勢所驅動。每一筆 DepthFeed snapshot 都以 epoch-millis 時間戳接上一個高頻 Binance 參考價，讓你能把訂單簿狀態與那段重新定價合約的現貨走勢對齊——對任何交易加密貨幣價格與市場隱含機率之間關係的策略而言，這是不可或缺的。

步驟五——用同一份程式碼上線實盤

歷史 REST API 與即時 WebSocket 串流發出的是完全相同的 JSON snapshot 物件。這意味著你為重播歷史所寫的載入程式，原封不動就能讀取即時資料源——研究與生產之間無需重寫。先回測、驗證，然後把同一份程式碼指向 wss://api.depthfeed.com/v3/stream，就能開始交易。

常見陷阱

• 使用最後成交價資料：隱藏了價差與滑價，會灌水回測報酬。
• 固定間隔 snapshot：每小時或每分鐘取樣會錯過一個 5 分鐘市場的絕大部分生命週期。
• 忽略排隊位置：假設掛單永遠會成交，會高估被動型策略。
• 前視偏誤：只能對接收時間戳在你決策時間點當下或之前的資料做出反應。
• 跳過標的：加密貨幣漲跌的優勢通常藏在現貨對機率的關係裡。