收益率86%？如何利用機器人在Polymarket上「躺賺」

几周前，我决定构建属于我自己的 Polymarket 机器人。完整版本花了我几个星期的时间。

我愿意投入这些精力，是因为 Polymarket 上确实存在效率漏洞，虽然市面上已经有一些机器人在利用这些低效获利，但还远远不够，这个市场的机会仍然远多于机器人的数量。

该机器人的逻辑基于我过去手动执行的一套策略，为了提高效率，我将其进行了自动化。该机器人运行在「BTC 15 分钟 涨 / 跌（BTC 15-minute UP/DOWN）」市场上。

机器人运行着一个实时监控程序，能够自动切换到当前的 BTC 15 分钟轮次，通过 WebSocket 流式传输最优买价 / 卖价（best bid/ask），显示一个固定的终端 UI，并允许通过文本命令进行全面控制。

在手动模式下，你可以直接下单。

buy up <usd> / buy down <usd>：买入特定美元金额。

buyshares up <shares> / buyshares down <shares>：购买精确数量的股数，使用对用户界面友好的 LIMIT（限价）+ GTC（取消前有效）订单，按当前最优卖价（best ask）成交。

自动模式运行一个重复的两段式（two-leg）循环。

第一步，它仅在每轮开始后的 windowMin 分钟内观察价格波动。如果任何一方跌得足够快（在大约 3 秒内跌幅至少达到 movePct），它就会触发「第一段（Leg 1）」，买入暴跌的那一方。

在完成 Leg 1 之后，机器人绝不会再次购买同一侧。它会等待「第二段（Leg 2，即对冲）」，并且仅在满足以下条件时触发：leg1EntryPrice + oppositeAsk <= sumTarget。

当满足此条件时，它购买相反的一侧。在 Leg 2 完成后，该循环结束，机器人返回观察状态，等待下一个使用相同参数的暴跌信号。

如果在循环过程中轮次发生了变化，机器人会放弃该打开的循环，并在下一轮中使用相同的设置重新开始。

自动模式的参数设置如下：auto on <shares> [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 開發中不可或缺的語言。