支付方式#

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

---

单次支付#

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

场景：互联网上绝大多数付费行为都是一次性的——一次 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 卖家支持。

---

x402 协议#

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

Onchain OS Payment 使用 x402 的两个 scheme：

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

---

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 代为提交。