1.38亿笔x402交易背后，签名有效不等于授权

一笔x402支付发出去，服务器验过EIP-712签名，完成结算，把货交出去。流程挑不出毛病。可只要换四个问题问一遍，"合规"这个词就站不住了：这笔钱，代理有权花吗？这个接口，在委托方授权的范围内吗？这次调用，真的交付了吗？如果没有交付，记录里写没写清楚是谁判定的、钱去了哪？

签名只能证明一把密钥同意了一笔支付。它证明不了这笔支付被授权过、被限定过范围、值得做，更不会记录事后发生了什么。这是x402当下最容易被忽略的一层：协议被调用得远比被托付资金要多。

规模已经不是零头。Chainalysis的数据显示，截至2026年第三季度末，Base上的x402累计交易约1.385亿笔；基于XRPL的x402支付超过1340万笔，当时七日平均每天约21.6万笔。同一份报告也提醒，笔数不等于价值。

这个提醒值得认真对待。10月的一周快照显示，Base和Solana上实际的x402服务支出约29.45万美元，而对应的USDC总流水要大得多。两条链、数百万次调用、每周几十万美元的真实付费需求——协议跑得很快，但被信任托付的钱还很少，可审计性是原因之一。10月的一篇批评文章说得直接："合规"目前只意味着支付签名验证通过，而不是支付被授权。

x402基金会10月1日任命了首任执行董事，目前成员已超过50家，工作组正在组建。现在正是争论"一条支付记录该装什么"的时机。

以下四类失败，签名看不见。它们不是假设，而是一个按次付费平台在结算与交付分离时真实撞上的形状。

拒绝不是失败。调用方传了个非法参数，处理程序返回400类错误，什么都没交付。如果平台的计数器把它算成上游故障，这个接口就会不断累积"过错"，最终被下架——因为调用方的输入，惩罚了服务方。签名有效、支付已结算，记录却把责任方写错了。支付记录必须把调用方错误、处理程序失败、上游失败分开，因为对应的补救手段不同：退款、记过，还是重试。

没有交付不等于没有付款。结算可以在交付失败之前就成功。钱动了，响应说任务没跑。只存"签名有效"的记录，让付款方回答不了唯一重要的问题：这笔钱能退回来吗，我凭什么知道？答案必须是一个状态，而不是一个布尔值——退款：已入队、不适用、失败，外加选择该状态的理由。

重试是一笔新支付。防重放是真实存在的：同一笔已签名支付不能被兑换两次。但客户端读到错误后，常常带着同一个请求头重试。如果记录不说清这笔支付已花掉并锁定，客户端就是在反复撞一把锁，什么也学不到。"可重试"应该写进记录，而对于已结算但未交付的调用，诚实的取值是false——重试需要一笔新支付，而不是一个新请求。

未知不是否。代理工具里最贵的bug类型不是错误答案，而是"一个答案"。上游超时或空标量被压成0、false或"服务不可达"时，代理会基于一个从未被确立的事实行动。继承这种压缩的支付记录，会让账本断言系统根本没观测到的事。未知必须是记录里的一等值，缺失永远不能被渲染成一个笃定的否定。

承载这些信息的形状，应当被当作可选扩展，而不是新的状态码。设计原则是：忽略它的验证方不损失任何东西，读取它的验证方可以审计这笔支出。记录里需要授权链（委托方、代理、授权范围与额度上限、过期时间）、决策（自动批准还是人工，依据哪条策略，理由是什么）、结果（已交付、被拒绝、失败、未测量，是否结算，退款状态，是否可重试，以及证据哈希）。

把它放在402响应的扩展字段里，作为策略要约——服务器声明自己会记录什么；再在结算回执里回填完整记录。付款方和任何审计方，都不必信任任何一方的说辞，就能回答那四个问题。

几条决定成败的约束：失败开放，客户端不带这个扩展，调用照常进行，强制字段会一夜之间割裂生态；体积有界，挑战本身就在请求头里走，每加一项都在消耗硬上限，记录要紧凑，证据用哈希而不是内联；不含秘密，范围只命名接口，不能命名参数、提示词或载荷，一个哈希足够日后证明一致性；结果至少三值，已交付、被拒绝、未测量是三个不同的世界，压平它们就是账本开始说谎的方式；记录必须能在拒绝中存活，如果记录只在成功交付时存在，那么最要紧的那些情况——付了钱没拿到货——恰恰没有记录。

如果你在做x402服务：现在就开始在支付旁边记录结果和退款状态，哪怕标准还不存在。成本是一行数据，换来的是"我们收了钱"和"我们知道发生了什么"之间的差别。如果你在参与规范：授权记录比一个新协议版本改动更小，而且正好回应了那条批评——交易笔数的增速，一直快过信任的增速。

代理支付的下一阶段，不会由调用量最多的链赢下。它会由那些出了事之后记录还能被审计的轨道赢下。签名有效只是入场券，记录才是产品。