# 结算并不是整个工作流。

**设计笔记 · 2026 年 9 月 7 日**

设想一个智能体雇用服务执行金融付款。这里至少有两笔支付：购买服务的费用，以及服务受托执行的付款。一方完成，并不证明另一方完成。

这是 Proof21 金融检查配置的出发点。它不意味着区块链需要另一层告诉自己原生转账是否存在。拟议价值是把证据连接成完整、事先约定的工作流。

## 三个不同问题

**请求了什么？** 指令标识操作、网络、精确资产、预期接收方、金额及相关约束。真实性和适用授权必须由外围系统确立，P21 报告不能自行编造。

**付钱购买了什么？** 商业交互证据标识服务及雇用服务商的付款。x402 签名报价／回执扩展是一种此类证据来源，仍需遵守自身验证规则。[1]

**实际执行了什么？** 底层交易必须在正确链上下文中评估。失败交易、不同合约上的同名代币、错误接收方或最终性不足，不能静默变成成功。

同一个钱包可能出现在多份记录中，但这不会使记录等价，也不证明它们属于同一操作。

## 有用的报告必须具体

拟议 P21 结果不说“这个智能体安全”，而是说明在具名检查配置下，所提供证据是否支持特定声明。报告应公开原始证据、预期绑定、评估版本和来源假设。

签名可以认证一份包含失败结果的报告。服务商 RPC 观察不同于独立验证链。缺失输入应保持无法判断，而不是让 LLM 补上。

即使工作流从未涉及比特币，这些区分仍有价值。比特币／DMT 是 Proof21 的核心支持能力，不是每个调用方都必须绕行的一站。

## 从现有控制旁开始

首个试点采用影子模式，保留钱包限额、签名规则和结算控制。P21 在旁提供结果，由独立接收方复现受支持检查。

若试点发现有意义的不匹配、减少对账工作，或产生对手方可使用的证据，才算成功；仅签署一个新的 JSON 对象不算成功。

首期计划样例包括错误网络、错误资产或接收方、指令修改、证据重放、交易失败、过期观察及数据不可用。这些是实现要求；网站不宣称已有发布验证器全部通过。

## 一个具体的绑定示例

假设一条合成指令要求向供应商 A 转账 100 个演示单位。如果精度为六位小数，预期金额就是整数字符串 `100000000`。服务提供者另收一笔服务费。这些数字仅用于说明记账关系，不代表真实代币、网络交易或价格报价。

现在假设提供者交回一份真实有效的服务费收据，以及一份向供应商 B 支付 100 个单位的交易记录。服务交互可能确实发生，但付款条件检查仍应失败。如果记录改为供应商 A，却使用了显示符号相同的另一种资产，检查依然失败。人类可读名称的相似性不能替代精确绑定。链标识与资产标识解决的是不同的命名问题；CAIP-2 和 CAIP-19 是有用的原始参考资料，而不是验证引擎。[2][3]

拟议的检查配置应绑定操作标识、指令摘要、预期网络、确切资产、收款方、整数金额、执行结果、观察时点与策略版本。商业收据和底层执行证据应分别保留。智能体的说明可以帮助人理解不匹配之处，却不能编造缺失的交易，也不能悄悄把未经授权的收款方改为“正确”对象。

## 失败与证据缺失必须走不同路径

如果一种受支持且已得到充分确认的记录显示收款方错误，就可以支持 `FAIL`。记录不可获得时，通常应返回 `INDETERMINATE`，而不是断定付款从未发生。这在操作上很重要：超时后自动再次付款可能造成重复支出。检查服务应明确其证据边界，由另一个获得授权的控制器根据应用的幂等策略决定等待、调查还是重试。

时效性是问题本身的一部分，而不是装饰性的时间戳。在相关事件之前观察到的记录，不能证明事件后来已经完成。同样，在某个观察时点达到确认要求的交易，遇到已检测出的链重组后可能需要重新评估。应保留两次观察及其理由，不要用一个没有解释的绿色标记覆盖先前结论。

## 独立使用方应当能够复现什么

一个有用的试点应向使用方提供原始指令、选定的配置版本、确切证据字节或经授权的获取引用，以及生成方的检查结果。使用方先确定自己正在检查哪些字节和哪个签发者，再复现受支持的比较，最后应用自己的接受规则。双方可以对是否接受产生分歧，而不必把这种分歧错误地解释为生成方的签名损坏。

试点测试集应每次只改变一个绑定条件，并记录预期原因。先建立一个已知匹配的合成案例，再依次修改收款方、资产、网络和金额。另行测试过时数据、执行失败、操作重放及证据源缺失。还应加入签名有效但结论为失败的报告，因为拒绝一切负面报告会违背系统的用途。明确记录哪些检查确已执行，哪些仍只是设计要求。

衡量节省了多少工作，而不是仅统计生成了多少收据。一项有用的指标是：另一位操作人员能否不让原智能体重新讲述过程，就找到相关证据并解释不匹配。不要把合成测试样例计为客户收入或成功的真实付款。Proof21 可下载的离线演示只说明这些区分中的有限一部分，并不等同于拟议的生产级金融适配器。

## 常见问题

### 有效的服务收据能证明所要求的付款已成功吗？

不能。它可以在自身签名与验证规则下支持某次服务交互。所要求的付款是另一个主张，需要与指令绑定的执行证据。应保留两份产物，而不是扩大一份收据的含义。

### 无法确定的结果是否应该自动触发再次付款？

不应该。证据缺失与执行失败是两种不同情况。任何重试都应由具有明确授权并设有防重复付款措施的控制器负责，而不是让大语言模型推断“超时就是什么也没发生”。

### 每次检查都需要 Bitcoin 或新代币吗？

不需要。金融检查设计可以在不新增 Bitcoin 写入的情况下评估受支持的工作流。可选的承诺以及 Bitcoin/DMT 能力各有不同作用。这里的 P21 是项目简称，不是已经可用的支付代币。

## 补充原始参考资料

- [2：CAIP-2 — 区块链标识规范](https://standards.chainagnostic.org/CAIPs/caip-2)
- [3：CAIP-19 — 资产类型与资产标识规范](https://standards.chainagnostic.org/CAIPs/caip-19)

<!-- p21-ecosystem-payments-v09 -->

## 与各集成匹配的稳定币

初始核心要求原生 NAT 和 Base 上的 USDC。每项新增商业集成上线时都采用明确的资产／网络／方法许可列表，而不是假定所有生态都使用同一种稳定币。2026 年 9 月 9 日审阅的提供方文档确立了以下实现目标；不代表 P21 已运行这些服务。

| 集成 | 支付范围 | 方法边界 |
| --- | --- | --- |
| Coinbase CDP / x402 | 首先为 Base USDC；其他文档所列网络须经适配器测试 | 保留支持的方案及准确网络／合约 |
| Binance B402 / BNB Smart Chain | B402 上线范围包含 USDT、USDC、USD1 和 U | USDT/USDC 使用 Permit2；USD1/U 也支持 EIP-3009 |
| PayAI | Solana 及获批 EVM 网络上的 USDC；其他资产须通过能力检查 | 列出网络不代表支持其全部代币 |
| Virtuals ACP | 按任务生命周期支付 USDC 服务费 | 保留任务、资金和结算语义，不能直接替换成通用 x402 |
| MCP / A2A | 协议不强制指定付款币种 | 通信与发现不选择或授权付款 |

Binance 公布的 BSC 主网资产均使用 18 位精度，包括其 USDC 和 USDT 合约。Base USDC 使用另一合约和 6 位精度。不得跨网络复制精度假设，也不能混淆测试网与主网资产。不要仅因某币与交易所相关就加入 FDUSD 等资产；须核实具体支付产品。

在宣告某方式可用前，取所有者许可列表与已配置提供方当前支持能力的交集。固定网络、代币、精度、支付方法和收款方；验证获准 spender／signer 地址，并保留必要授权元数据。刷新能力信息不得悄悄扩大许可列表。B402 生产访问需要提供方接入审批。所有 P21 通道均保持关闭，直到实现、结算测试及批准完成。

[Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882)

<!-- p21-enforcement-v10 -->

## 更新 · 签名拒绝不会改写结算

接收智能体的 `REJECT` 不是账本裁决。Proof21 现在把完整性、确定性评估、结算和接收方决策保持为独立维度。交易可以继续是 `CONFIRMED`，同时接收方按自己的策略签署 `REJECT`。

需要客观责任时，接收方先承诺 acceptance-policy 摘要／版本，再在操作后签署决策凭证。若确定性策略从完整证据得到 PASS 而签名决策相矛盾，独立评估者可以保存该矛盾；若依赖不可得私有输入，则必须是 `UNRESOLVED`。

## 继续阅读

- [P21 金融检查设计](https://proof21.xyz/zh-hans/docs/capabilities/check/)
- [验证、评估、接纳](https://proof21.xyz/zh-hans/docs/protocol/verification/)
- [合作试点指南](https://proof21.xyz/zh-hans/docs/partners/pilot/)
- [1：x402 签名报价与回执](https://docs.x402.org/extensions/offer-receipt)