x402 付款人签名并不涵盖统一资源定位符。它仅承诺金额、收款人、代币合约和区块链，而不包含任何说明你为何付款的内容。我修改了 x402 规范中发布的支付负载的 18 个叶子字段：其中 8 处修改后签名仍然验证通过，10 处修改导致验证失败。
我从该示例重新构建了以太坊改进提案-712 摘要，使用我自己编写的 secp256k1 代码恢复了签名者身份，然后每次更改一个字段。在 8 个仍然验证通过的字段中，包含了整个 resource（资源）对象。
将资源统一资源定位符更改为不同的主机。签名仍然验证通过。支付路径中的任何环节都没有察觉到这一变化。
人工智能披露： 我在人工智能助手的帮助下编写了
x402_intent_gate.py，并亲自在离线环境下，使用仅包含标准库的 Python 3.13.5 运行了该脚本，无网络连接，无私钥，无钱包，无资金。下面的每个数字和每个十六进制字符串都来自真实的本地运行结果。三次运行产生了字节完全相同的标准输出，其安全哈希算法256 值为6cfe746ec64d8a497b1cafe27ed351dab1f56f690d3195959f0993a6e57888a6。我引用的规范文本是其他人的作品，已在文中内联链接。
简而言之：
- x402
exact（精确）以太坊虚拟机方案中的签名结构是 以太坊改进提案-3009 的TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)（带授权的转账），包裹在一个添加了代币名称、版本、链标识符和合约地址的以太坊改进提案-712 域中。这就是全部列表。其中没有用于记录你购买内容的字段。 - 我枚举了 x402 v2 规范中
PaymentPayload（支付负载）示例的每个叶子字段，每次修改一个，并每次都重新运行真实的椭圆曲线数字签名算法恢复操作。18 次修改中有 8 次签名仍然验证通过。导致验证失败的 10 次涉及金额、代币、区块链和时间。 - 付款人签名的任何内容事后都无法检查。已结算的
transferWithAuthorization（带授权转账）会留下一个 ERC-20Transfer（转账）事件和AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce)（授权已使用）事件，两者均未命名资源。SettlementResponse（结算响应）有七个字段，其中只有extensions（扩展）字段可以携带资源信息，因为可选的报价与收据扩展将收据存储在该位置。该收据由服务器签名，而非由你签名。 - 修复此问题无需更改任何协议。随机数是由付款人选择的 32 字节数据，它位于签名内部，并在链上以索引形式发出。因此，不要再将其浪费在随机性上：
nonce = keccak256(canonical_intent || salt)（随机数 = Keccak256 哈希(规范意图 || 盐值)）。 - 网关在签名存在之前运行。在 17 个构建的案例中，有 10 个通过了促进者自身的验证步骤（包括真实的有效期窗口检查），但仍被网关拒绝。所有 3 个合法的案例仍然通过。
这不是一个无人部署的假设性协议。云flare 于 2026 年 7 月 1 日宣布了 x402 的货币化网关，该网关在其边缘节点背后的任何内容前放置了一个 402 状态码。签署此类协议的代理数量增长速度远快于询问签名含义的人数。
x402 付款人签名实际上承诺了什么？
从锚点开始，因为之后的所有内容都取决于我的计算是否正确。
x402 v2 规范 在第 5.2.1 节中发布了一个完整的 免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。PaymentPayload（支付负载）示例，包括一个真实的 65 字节签名。
