x402 刚刚获得巨大升级

x402 的承诺一直都很宏大：让互联网上的任何资源都能通过一个 HTTP 请求支付。没有账户，没有 API 密钥，没有计费面板。只有一个钱包和一个调用。

但有一个问题是大家都不愿说出口的：该协议只理解一个词：支付。

每次请求？支付。再次请求？支付。同一个用户，五秒后？支付。加载一个触发 30 个子请求的网页？支付 30 次。

这种模式适用于非常有限的用例——简单、无状态、一次性的 API 调用。但当你尝试做任何更有趣的事情时，它会立即崩溃。这正是为什么，当我们考虑在 x402 之上构建 @crossmint 的所有东西时，我们犹豫了。

三个实际问题阻碍了进展。

问题 1：延迟扼杀高频操作

x402 V1 下的每个 API 调用都需要一个完整的链上结算周期。钱包签名 → 协调器验证 → 区块链确认 → 响应。在 Base 上，每个请求大约有 1-2 秒的开销，在 Solana 上是 400 毫秒。对于现实世界来说太慢了。

LLM 推理调用、数据馈送、AI 代理在一个会话中进行 50 次工具调用——这些都无法承受每次跳跃 0.5-2 秒的支付开销。你会花更多时间在支付上，而不是在做事上。

问题 2：网站并非单一请求

加载一个付费网页会触发 20、30，有时甚至 50 个子请求——HTML、CSS、JS、图片、字体、API 调用。在 V1 下，从技术上讲，你需要为每个请求单独付费。

没有人会在此基础上构建付费网站。该协议对于单个 API 端点来说很好。它无法表达“访问体验”。

问题 3：V1 缺乏服务状态

这是一个微妙的问题。当你调用 Crossmint 的 API 创建一个嵌入式钱包时，该钱包会绑定到你的用户。如果你再次调用来为其充值，该调用需要知道你是谁——而不仅仅是有人支付了。

V1 没有身份概念。每次调用都是匿名的且不关联的。你支付，得到响应，然后又变回陌生人。如果你购买天气预报，这没问题。但如果服务需要记住你，这就行不通了。

这意味着整类服务：任何有状态的、任何有用户的、任何不纯粹是按事实付费的……都无法在 x402 中得到恰当表达。包括我们构建的许多东西。

这一切刚刚改变

x402 刚刚发布了基于凭证的授权，以及 Sign-In-With-X (SIWX)——一个基于 CAIP-122 构建的钱包身份验证层，CAIP-122 是链无关的“通过 X 登录”标准。

这个想法很简单，借鉴了网络已经处理这个问题的方式。

当你今天登录一个网站时，服务器会做一些耗时的操作：它检查你的凭证，验证你的身份，进行数据库查询。但它不会在每次点击时都这样做。登录后，它会给你一个会话Token——一个廉价、快速的加密证明，表明“这是经过身份验证的同一个人”。随后的每个请求都会在本地以微秒为单位验证该Token，无需数据库调用。

SIWX 对 x402 做了同样的事情，但将你的钱包作为身份。

支付一次。服务器记录你的钱包地址已支付。在随后的请求中，你签署一个轻量级的 CAIP-122 消息，证明你控制该钱包。服务器在本地验证——没有区块链，没有协调器，没有延迟。访问被授予。

上述三个问题都迎刃而解。

为什么是 CAIP-122

标准的选择很重要。CAIP-122 是一个经过实战检验、链无关的规范，从一开始就适用于 EVM（Ethereum、Base、Polygon 等）和 Solana。它处理常规钱包 (EIP-191 签名)、智能合约钱包 (EIP-1271)，甚至尚未部署的钱包 (EIP-6492)。

这不是 x402 团队发明的新协议。它是一个现有的、经过审计的、广泛部署的标准，社区建议将其用于这个特定的用例。结果是 x402 无需从头开始重新发明身份验证，就能获得身份功能，并且它适用于协议已经支持的所有链。

服务器在其 402 响应中声明 SIWX 支持。客户端匹配其钱包的链，签名一次，并在后续请求中发送 SIGN-IN-WITH-X 头。域绑定和过期窗口防止重放攻击。协调器完全脱离这个流程——这纯粹是客户端-服务器模式。

这实际上解锁了什么

用例远远超出了“按次计费的 API”。

付费网站或媒体：支付 0.10 美元访问一篇文章。随后的 30 个页面请求中的每一个都通过钱包签名进行身份验证——无需重复支付，无需账户，无需 cookie。支付一部电影 4 小时的费用。在你的会话期间，每个片段请求都通过你的钱包证明进行身份验证。当时间窗口到期时，你的访问权限也随之到期。

有状态的 API：@Crossmint 创建你的钱包并将其绑定到你的项目。后续引用该钱包的调用会根据你之前的支付进行身份验证。服务现在知道你是谁，而不仅仅是有人支付了。

高频代理工作流：AI 代理在会话开始时支付一次。随后的每个工具调用都通过钱包签名在微秒内进行身份验证。没有区块链往返，没有累积延迟。一个原本会产生 100 倍延迟开销的会话现在可以全速运行。

警告

SIWX 增加了灵活性，但它将复杂性转移到了服务器端。协议为你提供了原语；业务逻辑由你自己定义。

如果你调用 Crossmint 的 API 并创建一个钱包，一次性支付是否赋予你所有未来调用的权利？多长时间？如果你切换钱包怎么办？这些问题你的服务必须回答——SIWX 不会为你回答。这不是一个 bug，但值得指出。

越多服务采用这种模式，调用者就需要越了解他们所调用的每个服务的访问语义。这与“按次计费”的模型不同，在“按次计费”中，语义总是显而易见的。

总结

x402 最初是一个好主意，但有一个真正的限制：它只能表达“为这一个请求付费”。

SIWX 使表达“为访问付费”成为可能，这基本上涵盖了互联网上的所有服务模型。API、网站、流媒体、代理、具有持久用户的有状态服务。所有这些，都使用相同的标准。

最后一个主要障碍已经消除。现在轮到开发者们付诸实践了。

• 原文链接： x.com/alfongj/status/203...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～