Polymarket 构建者计划：构建者代码、归因与可复现的集成工作流

构建者计划实际归因什么

Polymarket 构建者计划是建立在 Polymarket 中央限价订单簿（CLOB）之上的归因和收入分成层。构建者是任何代表用户向 Polymarket 发送订单的应用程序、机器人或订单路由器。当这些订单匹配时，附加在订单上的构建者代码让 Polymarket 将交易量计入构建者档案。没有该代码，同一笔交易仍会执行，但不会记录构建者归因。

实际后果是，归因是订单负载和签名路径的属性，而不是你前端品牌的属性。用户可以通过你的 UI 交易，但如果订单在签名或提交时没有构建者字段，仍然产生零构建者交易量。相反，一个没有 UI 的无头路由器只要正确附加代码，就可以累积归因交易量。

本文侧重于集成机制和验证方法。关于读取链状态和提交交易的具体 Polygon RPC 端点选择，请使用 RPC Assistant 端点指南，而不是硬编码公共端点。

• 构建者代码：标识接收归因的应用程序或路由器。
• 构建者凭证：为你的构建者档案颁发的 API 密钥、密钥和口令。
• 代理钱包：持有抵押品和代币授权的合约钱包（通常是 Gnosis Safe）。
• CLOB 客户端：签名并提交订单，包括构建者归因字段。
• 构建者中继器：代表你提交无 gas 的代理钱包操作。

开始前的先决条件和假设

你需要一个带有 API 凭证的 Polymarket 构建者档案、一个你控制的 Polygon 主网 RPC 端点，以及代理钱包的签名策略。以下示例假设服务器端集成，构建者凭证永远不会到达浏览器。如果你正在构建消费者应用，请将其与嵌入式钱包提供商配对，以便用户无需管理种子短语即可获得钱包。

你还应该尽早决定是运行自己的代理钱包部署流程还是依赖现有的 Safe。中继器路径很方便，但引入了对中继器可用性和正确 nonce 处理的依赖。将中继器视为具有自身故障模式的基础设施，而不是神奇的免 gas 按钮。

关于路由器提交大量交易时的节点级可靠性预期，请查看 专用节点选项 和 RPC 定价模型，以便在启动前确定吞吐量。

• 构建者 API 密钥、密钥和口令仅存储在服务器端。
• 一个具有足够速率限制以支持你的订单量的 Polygon 主网 RPC URL。
• 一个已注资的代理钱包，并已完成相关交易所合约的代币授权。
• 一个记录订单 ID、构建者代码和匹配状态的日志管道。

心智模型：构建者归因如何流经订单

一个归因订单经过四个阶段。首先，你的应用程序构建一个包含市场、方向、价格、数量和构建者元数据的订单。其次，CLOB 客户端使用代理钱包的签名权限对订单进行签名。第三，订单被提交到 Polymarket 的匹配引擎。第四，如果订单匹配，成交记录会记入你的构建者档案。

关键洞察是归因在匹配时评估，而不是在提交时。一个挂起未成交然后被取消的订单不会产生归因交易量。这就是为什么路由可成交订单的构建者比发布被动流动性的构建者更快看到归因，以及为什么你的验证程序必须检查成交而不是提交。

第二个洞察是构建者费用和平台费用是分开的。你的构建者费用是 Polymarket 自身费用表的附加项，因此你必须模拟用户支付的总成本。不要假设你的构建者费用取代平台费用。

可运行诊断：确认你的凭证和 RPC 路径

在编写订单逻辑之前，确认你的构建者凭证能够通过认证，并且你的 RPC 端点可以读取代理钱包的状态。以下 Python 片段使用环境变量和占位符值；请替换为你自己的。它不会下订单，因此可以安全地针对生产凭证运行。

该脚本检查三件事：RPC 端点是否响应当前区块号，代理钱包是否有非零原生余额用于 gas（如果你不使用中继器），以及你的构建者凭证是否存在于环境中。任何步骤失败都会告诉你需要在接触订单构建之前修复哪一层。

import os, json, urllib.request

RPC_URL = os.environ["RPC_URL"]
PROXY_WALLET = os.environ["PROXY_WALLET"]

required = ["POLYMARKET_BUILDER_API_KEY", "POLYMARKET_BUILDER_SECRET", "POLYMARKET_BUILDER_PASSPHRASE"]
missing = [k for k in required if not os.environ.get(k)]
print("missing builder credentials:", missing)

def rpc(method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(RPC_URL, data=body, headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        return json.loads(resp.read())

block = rpc("eth_blockNumber", [])
balance = rpc("eth_getBalance", [PROXY_WALLET, "latest"])
print("block:", int(block["result"], 16))
print("proxy native balance wei:", int(balance["result"], 16))

集成骨架：将构建者代码附加到订单

确切的客户端 API 会随时间变化，因此将以下内容视为结构模板，而不是复制粘贴的生产脚本。重要的部分是关注点分离：凭证在服务器端加载，客户端使用代理钱包和构建者凭证初始化，订单负载携带构建者归因字段。

在实践中，你将使用 Polymarket 发布的客户端库。下面的模板展示了初始化和订单提交调用的形状，以便你可以将其映射到当前库版本。将签名端点保留在你自己的服务器后面，这样构建者密钥永远不会暴露给客户端。

import { ClobClient } from "@polymarket/clob-client";

const client = new ClobClient({
  host: process.env.CLOB_HOST,
  chainId: 137,
  signer: proxyWalletSigner,
  creds: {
    key: process.env.POLYMARKET_BUILDER_API_KEY,
    secret: process.env.POLYMARKET_BUILDER_SECRET,
    passphrase: process.env.POLYMARKET_BUILDER_PASSPHRASE,
  },
  builderCode: process.env.POLYMARKET_BUILDER_CODE,
});

const order = await client.createOrder({
  tokenID: process.env.TOKEN_ID,
  price: 0.42,
  size: 10,
  side: "BUY",
});

const response = await client.postOrder(order);
console.log(JSON.stringify({ orderId: response.orderID, builderCode: process.env.POLYMARKET_BUILDER_CODE }));

验证程序和结果表

只有当匹配的成交出现在你的构建者档案中时，归因才是真实的。构建一个验证循环，提交一个小型、故意可成交的订单，等待匹配，然后核对三条记录：你自己的订单日志、CLOB 响应以及构建者仪表板或 API 视图中的归因交易量。在每次客户端升级后以及签名路径的任何更改后运行此循环。

为每个测试订单记录以下字段，以便你可以比较不同时间的运行。不要编造预期值；用你自己观察到的结果填写表格，并将原始响应保留在旁边。

通过的运行显示匹配的成交，并在计划的报告窗口内显示归因交易量的相应正增量。失败的运行显示匹配的成交但没有归因增量，这几乎总是意味着构建者字段在订单构建和签名之间的某个地方被丢弃了。

排查常见的归因和中继失败

大多数集成失败属于少数几类。按顺序处理它们，因为较早层的失败会伪装成较后层的失败。

如果订单在匹配前被拒绝，首先检查代币授权。代理钱包必须授权抵押品和相关交易所合约；缺少授权会产生回滚，看起来像订单错误。如果订单提交但从未归因，检查签名负载并确认构建者代码在序列化后仍然存在。如果中继器拒绝代理钱包操作，检查 nonce 顺序以及之前的操作是否仍在待处理。

• 交易所合约的代币授权缺失或过期。
• 构建者凭证在浏览器而不是服务器中加载，导致静默回退到未归因订单。
• 并发提交多个操作时中继器 nonce 冲突。
• 高交易量订单提交期间 RPC 速率限制，产生看起来像匹配失败的 超时。
• 对主网合约使用测试网 RPC 端点，或反之。

限制、权衡以及该计划不保证什么

构建者计划归因匹配的交易量；它不保证收入。你的收益取决于你配置的费率、任何奖励池中归因交易量的份额以及你的用户行为。公开排行榜显示交易量高度集中在少数构建者中，因此计划长期爬坡而不是立即支付。

中继器路径和自行提交交易之间也存在操作权衡。中继器简化了 gas 管理，但增加了依赖和 nonce 排序约束。自行提交给你更多控制权，但需要你为代理钱包注资并监控。两种路径都不能消除对可靠 RPC 访问的需求；当节点层不稳定时，两者都以相同方式失败。

最后，计划条款、费用上限和奖励机制可能会变化。将你阅读到的任何具体费率视为快照，并在向用户发布定价之前重新检查官方计划文档。

后续步骤：从可工作的集成到可靠运营

一旦单个归因订单端到端验证通过，就加固路径。在订单构建、签名、提交和成交核对周围添加结构化日志。对归因增量降至零而订单量保持正值的模式添加警报，因为这种模式通常表明凭证或负载的静默回归。

然后确定你的基础设施规模。查看 网络指南 了解你的集成涉及的链，以及 RPC 端点指南 了解如何根据延迟和一致性评估提供商。如果你预计持续订单流，在第一个高交易量日之前比较 专用节点选项 与共享端点。

对于构建相邻工具 的团队，Hyperliquid RPC 提供商比较 和 多链端点指南 说明了应用于其他交易场所的相同可靠性原则。