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

几周前，我决定构建属于我自己的 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

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

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

自动模式的参数设置如下：auto on [sum=0.95] [move=0.15] [windowMin=2]

· shares：用于两段交易的仓位大小。

· sum：允许对冲的阈值。

· move (movePct)：暴跌阈值（例如 0.15 = 15%）。

· windowMin：从每轮开始算起，允许执行 Leg 1 的时长。

回测

机器人的逻辑很简单：等待暴力砸盘，买入刚跌完的那一方，然后等待价格稳定并通过购买相反一侧进行对冲，同时保证：priceUP + priceDOWN

但这个逻辑需要经过测试。它在长期内真的有效吗？更重要的是，机器人有很多参数（股数、总和、移动百分比、窗口分钟数等）。哪组参数集是最优的并能使利润最大化？

我的第一个想法是让机器人实盘运行一周并观察结果。问题是这耗时太长，且只能测试一组参数，而我需要测试很多组。

我的第二个想法是使用来自 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 股

· 暴跌阈值 = 15%

· windowMin = 2 分钟

我还应用了恒定的 0.5% 费率和 2% 的价差，以保持在保守的情景中。

回测显示 ROI 为 86%，在短短几天内 $1,000 变成了 $1,869。

然后我测试了较激进的参数集：

· 初始余额：$1,000

· 每次交易 20 股

· 暴跌阈值 = 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 开发中不可或缺的语言。