Polymarket 交易機器人參數最適化研究

來源: @the_smart_ape | 原文連結

日期: Mon Dec 29 09:46:15 +0000 2025

標籤: 機器人交易 參數優化 回測框架

---

★ Insight ───────────────────────────────────── • 這篇文章深入探討了量化交易中的「回測基礎設施」議題——當市場數據 API 不可靠時，如何自建錄製系統來驗證策略 • 展示了參數最適化的重要性：同樣的策略邏輯，保守參數達 86% ROI，激進參數卻虧損 50% • 揭示了回測與實盤交易的落差來源：滑價、市場衝擊、訂單深度等現實因素無法完美模擬 ─────────────────────────────────────────────────

來源: @the_smart_ape (The Smart Ape 🔥)
日期: 2025-01-23（推文發布日期）
標籤: polymarket trading-bot backtesting parameter-optimization market-making

---

概述

開發者分享自建的 Polymarket BTC 15 分鐘漲跌預測市場交易機器人開發與回測經驗。核心發現：

參數組合	ROI	說明
保守策略	+86%	shares=20, sum=0.95, dump=15%, window=2min
激進策略	-50%	shares=20, sum=0.6, dump=1%, window=15min

結論：參數選擇比策略邏輯本身更關鍵，決定盈虧的分界線。

---

機器人邏輯

市場與操作模式

• 目標市場：Polymarket 的「BTC 15-minute UP/DOWN」市場
• 數據來源：WebSocket 即時串流 best bid/ask 價格
• 操作介面：固定終端 UI + 文字指令控制

手動模式

# 花費美元金額購買
buy up <usd>
buy down <usd>

# 購買精確份額（使用 LIMIT + GTC 訂單，價格為當前最佳賣價）
buyshares up <shares>
buyshares down <shares>

自動模式：雙腿循環策略

觸發條件：

auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

參數	說明
shares	每條腿的倉位大小
sum	對沖觸發閾值（例如 0.95 表示兩邊價格總和 < 0.95）
move	暴跌閾值（例如 0.15 = 15% 跌幅）
windowMin	從回合開始算起，允許 Leg 1 執行的時間窗口

執行邏輯：

1. Leg 1（首次進場）：

   • 只在回合開始後的前 windowMin 分鐘內監控
   • 當任一邊在 ~3 秒內跌幅 ≥ movePct 時觸發
   • 買入暴跌的那一邊
   • 之後不再買入同一邊

2. Leg 2（對沖）：

   • 等待條件：leg1EntryPrice + oppositeAsk <= sumTarget
   • 滿足時買入相反邊
   • 完成後回到監控狀態

3. 特殊情況：

   • 若回合中途切換，放棄當前循環，下回合重新開始

---

回測挑戰與解決方案

數據問題

方案	問題
方案一：實盤運行一週	耗時長且只能測試單一參數組合
方案二：使用 Polymarket CLOB API 歷史數據	BTC 15min UP/DOWN 市場的歷史端點返回空數據集

原因分析：該特定市場不保留歷史數據（其他用戶也遇到同樣問題）。

自建錄製系統

由於無法取得歷史數據，開發者建立了自己的即時價格錄製系統：

錄製內容：

• 時間戳
• 回合標識 (round slug)
• 剩餘秒數
• UP/DOWN token IDs
• UP/DOWN best ask 價格

回測方式：

• 重播快照數據
• 確定性地應用自動交易邏輯
• 確保能捕捉高頻數據以偵測暴跌和對沖條件

數據規模：4 天內累積 6 GB 數據。

---

參數測試結果

保守參數組合

參數	數值
初始資金	$1,000
每筆交易份額	20 shares
sumTarget	0.95
暴跌閾值	15%
時間窗口	2 分鐘
手續費率	0.5%
滑價	2%

結果：ROI +86%，數天內從 $1,000 成長至 $1,869。

激進參數組合

參數	數值
初始資金	$1,000
每筆交易份額	20 shares
sumTarget	0.6
暴跌閾值	1%
時間窗口	15 分鐘

結果：ROI -50%，2 天內虧損一半。

關鍵結論：參數選擇是最重要的因素，可以決定盈利或虧損。

---

回測局限性

儘管已納入手續費和滑價，回測仍有以下限制：

數據與市場建模

限制	說明
數據量不足	只有數天數據，可能無法反映完整市場狀況
訂單簿深度未建模	只使用 best-ask 快照，實際訂單可能部分成交或以不同價格成交
微秒級波動未捕捉	數據每秒採樣一次，秒內價格變動無法記錄
滑價假設固定	實際網路延遲為 200-1500ms 且會波動，回測中滑價為常數

執行假設

限制	說明
即時成交	假設每條腿都是瞬間執行，無訂單佇列或掛單延遲
手續費簡化	統一套用固定費率，實際可能因 market/token、maker/taker、費用層級而異
保守虧損估計	若 Leg 2 在市場關閉前未執行，Leg 1 視為全額虧損（現實中可能提早平倉、以 ITM 結束或部分虧損）

市場影響

未模擬項目：

• 自身訂單對訂單簿的影響
• 吸引或排斥其他交易者的效應
• 非線性滑價
• API 限流、錯誤、拒單、暫停、超時、斷線重連
• 機器人忙碌時錯過訊號的情況

回測價值：極有價值於識別良好的參數範圍，但不能作為 100% 保證，因為某些真實世界效應無法建模。

---

基礎設施優化方向

當前架構

• 計劃在 Raspberry Pi 上運行，避免佔用主機資源並實現 24/7 運作

改進方向

優化項目	效益
使用 Rust 取代 JavaScript	大幅提升效能和處理速度
運行專用 Polygon RPC 節點	進一步降低延遲
部署在靠近 Polymarket 伺服器的 VPS	顯著減少網路延遲

學習路徑：作者正在學習 Rust，認為它已成為 Web3 開發的必備語言。

---

重點整理

1. 策略核心：等待暴跌 → 買入暴跌方 → 等待穩定 → 對沖買入相反方（確保 priceUP + priceDOWN < 1）

2. 參數至關重要：同樣邏輯，不同參數可導致 +86% 至 -50% 的巨大差異

3. 回測必要性：由於官方 API 歷史數據不完整,需自建錄製系統進行回測

4. 回測與實盤落差：訂單深度、市場衝擊、網路延遲、部分成交等真實因素難以完美模擬

5. 基礎設施投資：語言選擇(Rust)、專用節點、伺服器位置等都會影響實際表現