一位開發者分享如何打造 Polymarket 交易機器人，透過捕捉 BTC 15 分鐘市場的價格波動，在幾天內將 1,000 美元變成 1,869 美元，回測收益率達 86%。文章詳細介紹機器人搭建邏輯、回測方法及其局限性。
（前情提要：預測市場龍頭 Polymarket 宣布自建 L2，Polygon 的王牌沒了？ ）
（背景補充：如何通過 Polymarket 套利實現年化 40% 收益？ ）

本文目錄

• 機器人搭建邏輯
• 回測
• 回測的局限性
• 基礎設施

幾週前，我決定構建屬於我自己的 Polymarket 機器人。完整版本花了我幾個星期的時間。

我願意投入這些精力，是因為 Polymarket 上確實存在效率漏洞，雖然市面上已經有一些機器人在利用這些低效獲利，但還遠遠不夠，這個市場的機會仍然遠多於機器人的數量。

機器人搭建邏輯

該機器人的邏輯基於我過去手動執行的一套策略，為了提高效率，我將其進行了自動化。該機器人運行在「BTC 15 分鐘 漲 / 跌（BTC 15-minute UP/DOWN）」市場上。

機器人運行著一個即時監控程式，能夠自動切換到當前的 BTC 15 分鐘輪次，通過 WebSocket 串流傳輸最優買價 / 賣價（best bid/ask），顯示一個固定的終端 UI，並允許通過文字命令進行全面控制。

在手動模式下，你可以直接下單。

buy up / buy down ：買入特定美元金額。

buyshares up / buyshares down ：購買精確數量的股數，使用對使用者介面友善的 LIMIT（限價）+ GTC（取消前有效）訂單，按當前最優賣價（best ask）成交。

自動模式運行一個重複的兩段式（two-leg）循環。

第一步，它僅在每輪開始後的 windowMin 分鐘內觀察價格波動。如果任何一方跌得夠快（在大約 3 秒內跌幅至少達到 movePct），它就會觸發「第一段（Leg 1）」，買入暴跌的那一方。

在完成 Leg 1 之後，機器人絕不會再次購買同一側。它會等待「第二段（Leg 2，即對沖）」，並且僅在滿足以下條件時觸發：leg1EntryPrice + oppositeAsk <= sumTarget。

當滿足此條件時，它購買相反的一側。在 Leg 2 完成後，該循環結束，機器人返回觀察狀態，等待下一個使用相同參數的暴跌訊號。

如果在循環過程中輪次發生了變化，機器人會放棄該打開的循環，並在下一輪中使用相同的設定重新開始。

自動模式的參數設定如下：auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares：用於兩段交易的倉位大小。
• sum：允許對沖的閾值。
• move (movePct)：暴跌閾值（例如 0.15 = 15%）。
• windowMin：從每輪開始算起，允許執行 Leg 1 的時長。

回測

機器人的邏輯很簡單：等待暴力砸盤，買入剛跌完的那一方，然後等待價格穩定並通過購買相反一側進行對沖，同時保證：priceUP + priceDOWN < 1。

但這個邏輯需要經過測試。它在長期內真的有效嗎？更重要的是，機器人有很多參數（股數、總和、移動百分比、窗口分鐘數等）。哪組參數集是最優的並能使利潤最大化？

我的第一個想法是讓機器人實盤運行一週並觀察結果。問題是這耗時太長，且只能測試一組參數，而我需要測試很多組。

我的第二個想法是使用來自 Polymarket CLOB API 的線上歷史數據進行回測。不幸的是，對於 BTC 15 分鐘漲 / 跌市場，歷史數據端點一直返回空數據集。沒有歷史價格跳動（ticks），回測就無法檢測到「大約 3 秒內的暴跌」，無法觸發 Leg 1，無論參數如何，都會產生 0 次循環和 0% 的投資回報率（ROI）。

經過進一步調查，我發現其他使用者在取得某些市場的歷史數據時也遇到了同樣的問題。我測試了其他確實返回歷史數據的市場，並得出結論：對於這個特定的市場，歷史數據根本沒有被保留。

由於這個限制，回測該策略唯一可靠的方法是在機器人運行時，通過記錄即時最優賣價（best-ask）來創建我自己的歷史數據集。

記錄器將快照寫入磁碟，包含以下內容：

• 時間戳
• 輪次標識（round slug）
• 剩餘秒數
• UP/DOWN 代幣 ID
• UP/DOWN 最優賣價

隨後，「記錄回測（recorded backtest）」會重播這些快照，並確定性地應用相同的自動邏輯。這保證了能夠取得檢測暴跌和對沖條件所需的高頻數據。

我總共在 4 天內收集了 6 GB 的數據。我本可以記錄更多，但我認為這足以測試不同的參數集。

我開始測試這組參數：

• 初始餘額：$1,000
• 每次交易 20 股
• sumTarget = 0.95
• 暴跌閾值 = 15%
• windowMin = 2 分鐘

我還應用了恆定的 0.5% 費率和 2% 的價差，以保持在保守的情景中。

回測顯示 ROI 為 86%，在短短幾天內 $1,000 變成了 $1,869。

然後我測試了較激進的參數集：

• 初始餘額：$1,000
• 每次交易 20 股
• sumTarget = 0.6
• 暴跌閾值 = 1%
• windowMin = 15 分鐘

結果：2 天後投資回報率為 -50%。

這清晰地表明參數選擇是最重要的因素。它可以讓你賺很多錢，也可以導致重大損失。

回測的局限性

即使包含了費用和價差，回測仍有其局限性。

• 首先，它僅使用了幾天的數據，這可能不足以獲得全面的市場視角。
• 它依賴於記錄的最優賣價快照；在現實中，訂單可能會部分成交，或以不同的價格成交。此外，訂單簿深度和可用成交量未被建模。
• 未捕捉到秒級以下的微波動（數據每秒採樣一次）。回測雖然有 1 秒的時間戳，但在每秒之間可能會發生很多事情。
• 在回測中，滑點是恆定的，沒有模擬可變的延遲（例如 200–1500 毫秒）或網路峰值。
• 每一段交易都被視為「即時」執行（沒有訂單排隊，沒有掛單）。
• 費用是統一收取的，而現實中費用可能取決於：市場 / 代幣、掛單者與吃單者、費用等級或條件。

為了保持悲觀（審慎），我應用了一條規則：如果 Leg 2 在市場關閉前未能執行，Leg 1 將被視為全損（total loss）。

這是刻意保守的，但並不總是符合現實：

• 有時 Leg 1 可以提前關閉，
• 有時它最終處於價內（ITM）並獲勝，
• 有時損失可以是部分的而非全部。

雖然損失可能被高估了，但這提供了一個實用的「最壞情況」情景。

最重要的是，回測無法模擬你的大單對訂單簿造成的衝擊或吸引其他交易者圍獵你的行為。在現實中，你的訂單可以：

• 擾動訂單簿，
• 吸引或排斥其他交易者，
• 導致非線性滑點。

回測假設你是一個純粹的流動性提取者（price taker），沒有任何影響。

最後，它沒有模擬頻率限制（rate limits）、API 錯誤、訂單被拒絕、暫停、超時、重連，或者機器人忙碌而錯過訊號的情況。

回測對於識別良好的參數範圍極其有價值，但它不是 100% 的保證，因為一些現實世界的效果無法被建模。

基礎設施

我計劃在樹莓派（Raspberry Pi）上運行該機器人，以避免消耗我主機的資源，並保持 24/7 全天候運行。

但這仍有顯著的改進空間：

• 使用 Rust 代替 JavaScript 將提供遠為出色的效能和處理時間。
• 運行專用的 Polygon RPC 節點將進一步降低延遲。
• 部署在靠近 Polymarket 伺服器的 VPS 上也將顯著降低延遲。

肯定還有其他我尚未發現的優化方法。目前，我正在學習 Rust，因為它正成為 Web3 開發中不可或缺的語言。

#####