本章按「概念」组织，每个条目都可以从右侧目录直接定位。先看四种支付方式，再按需查阅它们涉及的具体技术。

卖家形态的定义：

• HTTP 卖家：对外运营公开 HTTP 接口，通过公网域名提供服务。适用于已有 API / 数据集 / 推理端点等场景。
• Agent 卖家：运行在本地或私有环境，通过消息通道（XMTP、Telegram 等）对外提供服务。不需要公网域名、SSL 证书、HTTP 服务部署。

买家是 Agent，通过钱包完成 EIP-3009 / EIP-712 签名后向 Broker 提交凭证。任何支持这两类签名的钱包都能给 Agent 用——如果你不想自己处理签名细节，可以让 Agent 直接接 Agentic Wallet。HTTP 卖家和 Agent 卖家发出的支付请求语义一致，同一个 Agent 买家可以无缝处理两类载体。

---

支付方式 ↔ Agent Payments Protocol Intent 映射#

Agent Payments Protocol 定义了 4 种 intent：charge / escrow / session / upto。Onchain OS Payment 当前的产品支付方式与协议 intent 的映射如下：

为什么批量支付和按量支付都是 session intent：两者在协议层都属于"先消费、后结算"的会话型支付——买家先在链下签授权或凭证，链上结算推迟到会话末尾。区别在结算粒度：

• 批量支付按"次"结算：买家每次调用签一张小票（charge 凭证），多张攒到一起由 Broker 在 TEE 里聚合成一笔交易上链。
• 按量支付按"金额"结算：买家签一张累计金额单调递增的 Voucher（如"截至当前累计应付 12.34 USDC"），新 Voucher 覆盖旧值；通道关闭时只兑现最新一张。

---

单次支付#

定义：最朴素的支付形态——买家付一次、卖家交付一次、交易结束。调用前价格就明确，调用后没有后续消费关系。

场景：互联网上绝大多数付费行为都是一次性的——一次 API 调用、一份报告、一次推理。买家不希望被强制订阅，卖家不希望为每个陌生买家做账户管理。

举例：Agent 调用数据分析 API 获取一次链上追踪报告、Agent 按次调用 LLM 推理、买家按篇购买研报、Agent 之间小费 / 打赏。

底层技术：Agent Payments Protocol 的 charge intent。消息格式（challenge / credential 字段结构、签名格式）与 x402 exact 和 MPP charge 兼容——同一份 challenge / credential 在两个生态里都能被识别。

---

批量支付#

定义：针对高频微支付场景设计的支付形态。买家每笔都签名，多笔签名在后端压缩聚合成一笔链上交易统一提交。因为结算发生在消费之后，所以也叫"事后支付"。

场景：Agent 自动化场景里，一次任务可能串联几十次付费调用，每次几分钱甚至几厘钱。如果每笔都独立上链，链上拥堵、Gas 成本可能超过支付金额本身。批量支付解决"Agent 规模化高频调用"下的结算效率问题。

举例：Agent 跑复杂研究任务调用 20 个付费 API、IoT 设备按秒付费使用带宽或算力、Agent 之间相互调用工具。

底层技术：Agent Payments Protocol 的 session intent 的事后聚合形态——和按量支付同属 session，区别在于按"调用次数"聚合而非按"累计金额"结算。买家每次调用都用 Session Key 签一张 EIP-712 凭证（消息格式遵循 OKX 在 x402 框架内原创定义的 aggr_deferred scheme），Broker 把多张凭证在 TEE 中聚合成一笔合法链上交易后统一提交结算。

前置条件：要求买家使用 Agentic Wallet，普通 EVM 钱包无法支持 Session Key 授权机制。

仅 HTTP 卖家支持。

---

按量支付#

定义：买家先在链上存一笔钱，之后每次消费只签一张"累计账单"（不上链）。用完之后把最新账单提交上链一次性结算，没花完的自动退回买家。

场景：调用前算不准总费用——典型如 LLM 按 token 计费，让它写篇文章可能 500 token 也可能 5000 token，开始时谁都算不准。单次支付和批量支付都要求调用前明确单价——这种"用多少算多少"的场景它们都覆盖不了。

举例：LLM 按 token 计费、流式数据订阅按实际消耗字节结算、语音视频 API 按秒计费。

底层技术：Agent Payments Protocol 的 session intent，机制为 Escrow 合约 + 链下累计 Voucher 的双层结构（消息格式与 MPP EVM session 兼容）。HTTP 卖家与 Agent 卖家共用同一套消息格式，区别只在传输载体：

---

担保支付#

定义：Client 先把钱锁进链上托管合约，Provider 交付服务后——如果 Client 没异议，钱在争议窗口期过后自动释放给 Receiver；如果有争议，由第三方 Arbitrator 裁决。

场景：两个陌生 Agent 要合作时（一个干活、一个付钱），存在经典的双边不信任问题：谁先动都可能亏。这是淘宝、eBay 等电商平台几十年验证过的老问题——担保支付把这套模式搬到链上，用智能合约替代传统平台。Agent 场景下任务交付通常通过消息通道协商确认，和担保支付的对话式流程天然契合。

举例：Agent 外包另一个 Agent 生成营销素材、Agent 委托其他 Agent 做代码审计、DAO 发布任务委托 Agent 竞标接单。

底层技术：Agent Payments Protocol 的 escrow intent，基于 Optimistic Escrow——OKX 设计的合约标准，定义协议字段、签名格式、Challenge / Credential 流程、以及链上合约标准。

资金路径：Buyer → Escrow 合约（托管）→ Receiver（验收通过后释放）。上链 2–3 次：创建订单 + 释放 ±仲裁。

仅 Agent 卖家支持。

---

HTTP 402#

HTTP 规范中预留的状态码，含义是 "Payment Required"——客户端需要付费才能访问该资源。它在 1999 年的 HTTP/1.1 规范（RFC 2616）中就被定义了，但当时没有配套的支付机制，所以一直处于"保留未启用"状态长达二十多年。

为什么 402 一直没被用起来？ 因为 HTTP 规范只定义了状态码的语义（"需要付费"），但没有定义怎么付、付给谁、怎么验证。没有标准化的支付流程，浏览器和客户端就不知道收到 402 后该做什么。x402 协议 就是来补这块的——它定义了基于 402 的完整支付交互流程。

为什么选 402 而不是自定义状态码？ 因为 402 的语义本来就是"需要付费"，这是 HTTP 标准的一部分，所有 HTTP 客户端、代理、CDN、负载均衡器都能正确传递这个状态码。用标准状态码意味着不需要改造中间任何一层网络基础设施，支付协议可以在现有 HTTP 生态上直接运行。

---

x402 协议#

Coinbase 提出的开放支付协议，把 HTTP 402 状态码真正激活。它规定了 402 响应里要写什么（金额、币种、收款地址）、客户端该怎么签名付款、签名用什么格式（EIP-3009 标准）。

Onchain OS Payment 使用 x402 的两个 scheme：

• exact：单次支付场景，简单直接的代币转账
• aggr_deferred：批量支付场景，OKX 在 x402 框架内原创定义的扩展，详见批量支付

---

MPP 协议#

MPP（Machine Payments Protocol）是 Stripe / Tempo 主导的开放支付协议，定位是面向 Agent 经济的机器支付协议。MPP 和 x402 解决的是同一个问题（让机器能自主付款），但在协议设计上各有侧重——MPP 更早引入了"意图（intent）"的抽象。

Agent Payments Protocol 与 MPP 的关系：Agent Payments Protocol 的消息格式是 MPP EVM 的 challenge / credential 严格超集。接入 MPP EVM 等于已经接入了 Agent Payments Protocol 的 charge。Agent Payments Protocol 不是 MPP 的薄壳——它在 MPP 的 EVM 子集之外，扩展定义了 escrow / session / upto 三种 intent（含 deliveries、usage report、arbitration hook 等 MPP 未规范的字段），并把传输面从 HTTP 延伸到 IM / QR / 离线。

---

Session Key#

买家在钱包里预先授权的一把"临时签名钥匙"。Agent 在预先约定的授权范围内（额度上限、有效期、作用域如特定卖家域名 / 接口）可以用 Session Key 替买家签名，不触发买家主私钥。

为什么需要：Agent 自动化调用节奏是毫秒级的，"每笔都要人工确认签名"不可行。Session Key 让买家一次授权、多次使用，这是 Agent 支付能自动化跑起来的前提。

和主私钥的关系：Session Key 是受限签名凭证——能签的金额、用途、有效期都在主私钥授权的边界内。即使泄露，损失也限定在授权范围内。

Session Key 是批量支付的核心机制。

---

TEE（可信执行环境）#

Trusted Execution Environment——硬件级别隔离的可信执行环境。运行在 TEE 里的代码和数据对系统其他部分不可见、不可篡改，即使服务器操作系统被攻破，TEE 内部也安全。

为什么 批量支付 必须用 TEE：

1. 约束 Broker 本身不能作恶或绕过规则
2. 让聚合结果可审计——任何人都可以验证聚合是否诚实执行

TEE 是批量支付唯一的合规上链通道。

---

Escrow 合约#

"Escrow 合约"是行业通用名词，指链上托管合约。本文档涉及两个独立的 Escrow 合约：

按量支付的 Escrow 合约#

买家把钱存进这个合约后，资金被合约锁定——谁都不能随意挪用，包括卖家、甚至买家自己，只能按协议规则（凭 Voucher 结算 or 通道关闭退回）动这笔钱。

为什么需要：解决按量支付里双方的信任问题——买家不用担心"钱给你了你跑了"，卖家不用担心"买家签了账单赖账"。规则写在合约代码里，双方都只能按规则走。

担保支付场景下的 Escrow 合约详见 Optimistic Escrow。

---

Voucher（累计凭证）#

按量支付 里的签名凭证。但它和传统"每次签一笔金额"的凭证不一样——Voucher 写的是"截至当前累计应付 X"，而不是"本次扣 Y"。

为什么用累计金额：累计结构自带两重保障：

• 防重放：金额单调递增，旧 Voucher 会被链上合约拒绝
• 抗丢失：即使中途几张 Voucher 丢了或重复了，只要卖家手上有最新一张，结算时就能拿到完整金额

什么时候上链：Voucher 本身不上链——卖家本地验签即可。只有在中途结算（settle）或通道关闭（close）时，卖家才把最新一张 Voucher 提交上链，链上合约按 Voucher 金额划账。

卖家本地需要存什么：只需保留累计金额最大的那张 Voucher（即最新一张）。旧 Voucher 可以丢弃——它们的累计金额已经被新 Voucher 覆盖，链上合约也不会接受比已结算金额小的 Voucher。

Voucher 用 EIP-712 签名，钱包界面能清晰展示"你正在签一张累计账单"。

---

Optimistic Escrow#

担保支付 的链上合约标准（OKX 设计）。定义了四方角色（Client / Provider / Receiver / Arbitrator）、六状态状态机、以及三条主要执行路径（乐观释放、争议仲裁、终止请求）。

为什么叫"乐观"：因为大多数交易都不需要仲裁——双方合作愉快，资金在争议窗口过后自动释放给 Receiver。Arbitrator 只在例外路径（Client 主动发起争议）被调用。这对应传统电商的真实数据：绝大多数订单不会走售后争议。

和具体任务系统是什么关系：解耦的。Optimistic Escrow 只规范资金托管和结算，不绑定任何具体的任务发布系统。可以和 ERC-8004（可信 Agent 身份）、ERC-8211（智能批处理）等协议组合使用。

---

Challenge / Credential#

Agent Payments Protocol 在传输层只定义两类消息：Challenge 和 Credential。

A2T（HTTP 卖家）和 A2A（Agent 卖家）共用同一套消息格式——区别只在于谁扮演 Seller、challenge 走哪个传输（HTTP 402 响应 vs IM 消息体 / URL / 卡片 / 二维码）。

结算结果不通过协议消息传递，Buyer / Seller 通过 Broker 的状态查询接口（或链上 tx hash）获取。

---

消息通道#

Agent 卖家场景下承载 Challenge / Credential 的传输载体——任何能让两个 Agent 互发文本的渠道都可以，不限定具体协议。

常见消息通道：

• IM：XMTP、Telegram、Discord、Slack
• 邮件 / Webhook：Email、自有 HTTP webhook
• 离线 / 半在线：deep link、QR 码、卡片

和 HTTP 的关系：协议消息语义在两类传输上完全一致，差异只在载体——HTTP 走 402 响应头，消息通道走消息体 / URL / 卡片 / 二维码。

仅 Agent 卖家走消息通道：HTTP 卖家始终走 HTTP 协议；Agent 卖家因为不需要公网部署，可灵活选择消息通道。

---

Broker（协议角色）#

Agent Payments Protocol 定义的第三方角色，负责验证、结算、状态承载三件事：

• Verification（验证）：检查买家提交的签名是不是合法
• Settlement（结算）：把验证通过的签名提交到链上结算
• State（状态）：Agent Payments Protocol 的消息（challenge / credential）不携带会话记忆，状态由 Broker 承载——铸造 paymentId、保存 challenge、跟踪状态机、对外提供查询

和 x402 Facilitator 是什么关系：同一架构位置，scope 不同。Facilitator 为单次 HTTP 往返设计、无状态；Broker 承担可能跨多步、跨多天的商业关系（如 按量支付 的累计 Voucher、担保支付 的争议窗口），需要持久化 challenge / paymentId / Voucher / 状态机。对单次支付场景，Broker 行为与 Facilitator 一致。

为什么需要：技术上 Buyer 可以直接转账给 Seller，但 Broker 解决了几个实际问题：

• Seller 不需要跑节点：Broker 替 Seller 处理链上交互（RPC 连接、Gas 管理、交易提交），Seller 只需要一个收款地址。
• 验证与结算分离：Broker 先做密码学验证（~100ms，不上链），确认支付凭证合法后再提交链上结算。这让验证速度极快，同时保证结算可靠。
• 统一合规入口：KYT 审查等合规检查可以在 Broker 层统一执行，而不是每个 Seller 各自实现。

Onchain OS 就是一个 Broker 吗：是的。Onchain OS Payment 的核心角色就是 Broker——接收 Buyer 的支付凭证、验证合法性、执行 KYT 审查、提交链上结算、向 Seller 确认支付完成；同时承担跨会话的状态管理。Coinbase 提供的 CDP Facilitator 是 x402 语境下的对应实现（仅覆盖单次往返场景）。

会接触到资金吗：Broker 提交链上交易，但资金直接从 Buyer 转到 Seller 的收款地址。Broker 不托管资金，也不作为中间账户。它的角色更类似于"公证人"——验证和执行，但不持有。（按量支付 / 担保支付 中资金锁在链上 Escrow 合约，同样不经过 Broker。）

可以自建吗：Agent Payments Protocol 和 x402 都是开放协议，任何人都可以实现自己的 Broker。但自建意味着你需要维护区块链节点连接、Gas 管理、交易签名和广播、KYT 合规、状态持久化等全套基础设施。使用 Onchain OS Payment 的 Broker 服务可以省去这些工作。

---

EIP-3009#

以太坊的一个签名标准，允许用户签一张"转账授权"——合约拿到签名后可以代替用户发起链上转账。

作用：单次支付 的签名底座。意义在于：买家不需要自己提交链上交易、不用付 Gas，只要签一个消息就够了，由 Broker 代为提交。

---

EIP-712#

以太坊的结构化数据签名标准。相对于传统的随意字符串签名，EIP-712 让签名内容结构化、可读——钱包界面能清楚展示"你正在签什么"（金额、地址、截止时间等），而不是一串 hex。

作用：批量支付 里的 Session Key 签名、按量支付 里的 Voucher 签名都基于 EIP-712。

---

Gas 补贴#

OKX 为 X Layer 上的支付交易提供的费用减免。通常链上交易需要支付 Gas 费（矿工/验证者处理费），但在 X Layer 上使用 USDG 或 USD₮0 进行支付时，Gas 费为零——由 OKX 承担。

适用范围：仅适用于 X Layer 上使用 USDG 和 USD₮0 的支付交易。具体见 支持的网络。

对微支付的意义：再小的金额都具备经济可行性。在有 Gas 费的链上，一笔 $0.001 的支付如果 Gas 费就要 $0.01，显然不合理。在 X Layer 上 Gas 为零，买家的实际成本 = 卖家标价，没有额外开销。这是 AI Agent 高频小额调用场景的基础条件。

会取消吗：Gas 补贴政策取决于 OKX 的运营策略。建议关注 Onchain OS 官方公告获取最新信息。即使未来政策调整，X Layer 的 Gas 费率本身也远低于以太坊主网等高成本链。

---

KYT#

KYT（Know Your Transaction）是交易级别的合规审查技术。它通过分析链上资金流向，识别与制裁名单地址、混币器、暗网市场、被盗资金等高风险实体关联的交易。

KYT 和 KYC 有什么区别：

x402 协议不要求用户注册和 KYC，但 Onchain OS 通过 KYT 在交易层面实现合规，在保持匿名性的同时过滤违规资金。

会拖慢支付速度吗：不会有感知。KYT 审查与交易验证并行执行，对端到端延迟的影响在毫秒级。

被标记了怎么办：被标记的交易将不会通过验证，服务器不会返回付费资源，买家不会被扣款。具体的拒绝原因会通过错误码返回。如果你认为是误判，可以联系 Onchain OS 支持团队。

作为卖家需要自己做 KYT 吗：不需要。Onchain OS 在交易验证环节自动执行 KYT 检查，对卖家完全透明。这是 Onchain OS 相比 x402 协议的核心差异之一。

---

下一步#

想动手接入#

想深入协议层#