如何用訂單簿回測 Polymarket 策略

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

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

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

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

從雙方的記錄完整深度訂單簿開始。DepthFeed 接收 Polymarket CLOB 更新，但記錄的觀察值遵循記錄的擷取頻率，並且可能存在間隙。檢查您市場可用的時間戳記，而不是假設所有上游事件都已保留。

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

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

按時間戳記順序重播記錄的觀察值。每個觀察值描述該觀察值時的儲存訂單簿，包括最佳買價、最佳賣價、深度和價差。請勿推斷觀察值之間的確切訂單簿狀態或保證成交；在回測中明確說明任何內插或持續性假設。

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

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

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

步驟四——接上標的價格

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

步驟 5 — 驗證即時資料配接器

歷史 REST 回應和即時 WebSocket 框架使用不同的記錄合約。在將兩者饋送給共用策略邏輯之前，請驗證其識別碼、時間戳記和欄位的配接器。在儲存的觀察值上進行回測，然後使用模擬交易對即時配接器進行前測。

常見陷阱

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