面向 Polymarket Bots 的 Polygon RPC：Alchemy、QuickNode、Ankr

Polymarket Bot 教程 · 第 5 章，共 32 章

2026 年 Polymarket bot 的 Polygon RPC provider 对比：Alchemy、QuickNode、Ankr、公共 endpoints、自托管。延迟、rate limit、可用于 paper trading 的免费层。

Polymarkets.co.il 首席作家 Harley Young 撰写。最后审阅：2026 年 5 月。

本章内容

Polygon RPC endpoint 是 bot 对链上状态的唯一直接视图-余额、allowance、结算确认、UMA events。Polymarket 自己的 API 会隐藏其中大部分信息，但生产级 bot 需要读取链上真实状态来验证自己的账本。本章会在真实负载下对比主流 RPC provider，给出各自失效前的免费层阈值，并以大多数 bot 最终会采用的双 provider failover 模式收尾。

• RPC 对你的 bot 有什么作用
• Alchemy：免费层与定价
• QuickNode：专用节点
• Ankr：最便宜的付费层
• 公共 Polygon RPC（免费，受 rate limit 限制）
• 自托管 Polygon 节点（何时值得）
• 延迟基准测试（美国东部 vs 欧洲）
• Failover 模式

RPC 对你的 bot 有什么作用

RPC endpoint 是你的 bot 读取和写入 Polygon 链状态的 HTTPS 或 WebSocket URL。对于 Polymarket bot，RPC 负责四项工作。

• 读取余额：proxy 里有多少 pUSD 或 USDC，你实际持有多少 outcome token。用于验证 CLOB API 的视图是否与链上真实状态一致。
• 读取 allowance：Polymarket 合约是否可以花费你的 token。配置错误的 allowance 会导致静默的下单拒绝。
• 订阅事件：UMA Optimistic Oracle 的提案与争议、存款确认、其他钱包的大额链上转账。
• 验证结算：当 CLOB 显示“matched”时，链上还没有确认 ERC-1155 transfer。读取链状态可以确认它确实发生了。

bot 不会通过 RPC 对订单进行签名-订单签名在本地完成，签名后的 payload 发送到 CLOB HTTP API。对大多数策略来说，RPC 只是一个读取和事件通道。

Alchemy：免费层与定价

Alchemy 是我们所知的 Polymarket builder 中使用最广泛的 Polygon RPC provider。免费层足以覆盖大多数 paper trading 和小型 bot 场景：300 compute units 每秒、每月 3 亿，使用同一个 dashboard 来开通 Polygon mainnet 和 Polygon testnet endpoints。

一个典型的 20 个市场 bot，如果每 30 秒读取一次余额 + UMA events，月消耗大约 5000 万到 8000 万 CU，远低于免费上限。付费方案通常从每月 50 美元左右起，主要购买的是更高的每秒吞吐，而不是更多总调用次数。对 paper-trade bot 来说，最先碰到的通常是免费层 rate limit，而不是月总量限制。

Alchemy 提供了一个很好用的 dashboard，可以查看失败请求以及按方法划分的 latency breakdown，在排查慢读取问题时非常有帮助。仅凭这个 dashboard，就足以让第一次做 bot 的人优先选择它，而不是一个没有 dashboard 的 provider。

QuickNode：专用节点

QuickNode 更偏向高吞吐需求。它的定价随月请求量而变化，而不是按层级划分-这对订阅大量 WebSocket event filter 或进行大量历史日志查询的 bot 最相关。入门层大约每月 10-20 美元，包含某些免费 Alchemy 层会限速的 WebSocket 支持。

QuickNode 从美国东部发出的单请求 latency 通常是 5-15ms，在负载下略优于 Alchemy 免费层。对于单一策略 bot，这种差异几乎无感；但对于要给 100 个市场报价的 market-maker，就可能很重要。他们的 archive node access（完整历史状态）如果你的策略需要，是三大 provider 中最便宜的。

痛点在于：它的 JSON-RPC 错误响应不如 Alchemy 具体，因此当某个 method 失败时，调试会更耗时。

Ankr：最便宜的付费层

Ankr 提供主流 provider 里最便宜的 Polygon RPC 付费方案-入门 premium plan 大约每月 10 美元，包含 1,500 CU/second。免费层的 rate limit 比较紧，但用于 paper trading 还是可以的。

有两个提醒。第一，Ankr 的负载均衡 endpoint 偶尔会返回略微过时的 block 数据（比最新区块滞后 1-2 个 block）。对于余额读取，这没问题；但对于依赖最新区块的套利策略，这是一个实质性问题。第二，当某个区域的节点出现问题时，他们的支持响应速度比 Alchemy 或 QuickNode 更慢。

对于成本敏感型 bot 来说，Ankr 是合理的主 provider；无论主 provider 是谁，它也都是很好的备用 provider。下面的 failover 模式部分会介绍如何组合它们。

公共 Polygon RPC（免费，受 rate limit 限制）

Polygon 提供了几个免费的公共 RPC endpoints-polygon-rpc.com、rpc.ankr.com/polygon（公共端点，与付费 Ankr 分开）、以及少量社区自建端点。它们能用，但有一些注意事项。

• rate limit 很激进，而且没有公开文档。预计如果持续超过大约 10 req/sec，就会被限流。
• 没有支持，没有 dashboard。端点出问题时，你只能从 bot 的错误率上升中发现。
• 经常落后 1-3 个 block。对于不依赖时效性的读取还算可以。

公共 endpoint 适合：笔记本电脑上的开发、failover 栈的第三层（在两个付费 provider 之后）、一次性脚本。不要把 live bot trading 的主通道放在公共 endpoint 上。

自托管 Polygon 节点（何时值得）

运行你自己的 Polygon full node 是可行的-在一台 4-vCPU/16GB 的 VPS 上运行 Bor + Heimdall，配大约 2 TB SSD，同步大概需要几天。支持或反对它的算账很简单。

成本：在主流主机商上，VPS + 存储大约每月 40-80 美元。大约是一个舒服的付费 RPC 方案的 4 倍。

收益：没有每次请求费用，没有 rate limit，而且到链上状态的 latency 最低（托管 provider 经互联网通常是 20-50ms，而本地可做到 1-3ms）。

麻烦：snapshot 管理、Heimdall 和 Bor 各自都有崩溃模式，而且交易中途同步卡住会产生静默的过期读取。

对 95% 的 builder 来说，不要自托管。花在节点维护上的时间远远超过 RPC 账单节省。只有当你的策略在 PnL 上真的会被 30ms 读取延迟影响，而且你已经在托管 provider 上验证过该策略时，才考虑自托管。

延迟基准测试（美国东部 vs 欧洲）

以下是在 2026 年 5 月，从三个区域的 VPS 到各 provider 最近的 Polygon RPC 所测得的中位往返时间。

这些数字会在大约 3ms 的范围内每周波动。模式很稳定：QuickNode 和 Alchemy 彼此差异几乎落在噪声范围内；Ankr 稳定慢 5-10ms；公共 endpoint 慢 15-25ms。部署在亚洲的 bot 相比 Polygon 以北美为中心的 backbone，不可避免地要付出约 80ms 的额外代价。

Failover 模式

单一 RPC 是单点故障。生产 bot 会使用两个 provider，并采用一个简单的切换规则。

模式：先对 provider A 发起主请求；如果超时（3 秒）或返回 5xx，就重试 provider B；如果两个都失败，就 sleep 5 秒后重试主 provider。记录主 provider 的连续失败次数，若连续失败 3 次，则自动固定到 B 60 秒，然后再探测主 provider。

推荐组合：以付费 Alchemy 为主 provider，以 Ankr 免费层或公共 Polygon endpoint 作为备用。它们使用不同的上游节点运营方，因此一个出现抖动时，另一个很少会同步受影响。不要运行同一 provider 的两个 endpoint（例如两个 Alchemy key）-那样没有真正的冗余。

实现方式：在 web3.py 或 ethers.js 外面包一层薄薄的 wrapper，在每次调用时在 provider 之间选择。大约 30 行代码；当 provider 第一次出现区域性故障时，这些代码就能回本。

常见问题