x402 协议 2.0 版本借鉴产品部署实践经验，实现了架构层面的根本性变革。该协议在处理超 1 亿笔交易后，研发团队锁定了关键痛点问题，并围绕三大目标重新设计协议，分别是层级划分清晰化、跨区块链扩展性及契合网络标准。

2.0 版本有哪些更新

传统支付与 x402 智能代理支付对比

传统支付流程需经过多个手动操作步骤，且离不开人工干预。而 x402 通过实现自主即时支付，彻底解决了这一繁琐问题。

2.0 版本的架构优化

统一支付接口

2.0 版本默认支持多链支付。仅需一个 API，无需修改代码，就能接收基于 Base、Solana 等所有兼容区块链上的 USDC 支付。

网络标识：采用 CAIP-2 标准

1.0 版本采用“base-sepolia”“base”等自定义网络标识，2.0 版本则采用了 CAIP-2（跨链通用改进提案 2，Chain Agnostic Improvement Proposal 2），该标准采用“命名空间：引用标识”的格式。这一调整使其不仅能适配各类区块链，甚至可兼容非区块链支付通道。

支付请求结构优化

1.0 版本中，每一种支付方式都需重复填写资源元数据。若某服务器支持三种代币支付，就需重复填写三次 URL、描述信息及内容类型。2.0 版本将这类信息整合至共享资源对象中，既缩减了信息传输体量，也避免了数据不一致的问题。

扩展功能框架

2.0 版本新增标准化扩展功能体系，其涵盖的可选功能可独立于核心支付机制运行。每一项扩展功能都包含一个 info 对象与一个 schema 对象，info 对象存储该扩展的专属数据，schema 对象则通过 JSON Schema 定义数据结构。

支付方式明确化

1.0 版本依靠字段匹配规则判断客户端选定的支付方式，2.0 版本则新增“accepted”字段，该字段会完整记录用户选定的支付需求，使支付方式选择更加明确。

HTTP 传输层优化

符合 RFC 6648 标准

互联网工程任务组（IETF）已弃用 HTTP 请求头中“X-”前缀。原因是很多实验性请求头虽已成为事实标准，却始终被标记为实验性状态。2.0 版本删除了这类前缀，并将支付相关配置信息从响应体迁移至请求头中。如此调整的原因在于：将协议元数据与应用内容分离后，服务器既能向浏览器返回定制化的 HTML 付费墙页面，又能在请求头中保留机器可读取的支付配置信息，进而提升中间件兼容性与框架集成度。

SDK 重构

从硬编码到模块化架构

1.0 版本的 SDK 将区块链专属逻辑嵌套在多层条件判断语句（if/else chains）中。若要新增适配的区块链，需修改核心文件并发布 SDK 新版本。2.0 版本新增三大接口，实现了区块链适配的即插即用功能。

构建器模式注册机制

开发人员可通过 CAIP-2 通配符注册区块链适配方案。SDK 会依据网络模式，将操作指令定向至对应的适配方案。

通配符匹配规则具体如下：

eip155:* 可匹配所有 EVM 链；

solana:* 可匹配所有 Solana 网络；

eip155:8453 则专门匹配 Base 主网。

Lambda 策略引擎

1.0 版本中钱包类型与支付方案均采用硬编码形式。2.0 版本引入可组合策略函数，用于支付过程中的实时支付授权操作。

Hook 系统

1.0 版本的业务逻辑执行于验证完成后、支付结算前。一旦结算失败，服务器可能已执行文件传输、API 调用、数据库写入等不可逆操作。2.0 版本新增六个生命周期钩子（lifecycle hooks）以解决该问题。

动态配置功能

2.0 版本的中间件（middleware）支持按路由配置参数，同时搭配回调函数，实现运行时决策。

Facilitator API 升级

功能公示

如今“/supported”端点可公示三项核心功能，分别是按协议版本分类的兼容支付类型、结算专用签名地址以及已启用的扩展功能。

自动识别功能

自动识别扩展功能支持服务端对外公示结构化元数据，以便系统自动建立索引。协调器（Facilitators）可自动检索支持 x402 协议的端点，实时更新价格目录，无需人工手动提交信息。

版本迁移方案

2.0 版本借助命名空间隔离（namespace isolation）技术，保障了对旧版本的向后兼容性。同一套 SDK、协调器（Facilitator）及服务器可同时兼容两个版本。客户端通过“x402Version”字段指定所需版本，系统会匹配对应的协议版本并作出响应。

原文：https://x.com/yq_acc/status/1999606689641955337

作者：@yq_acc

（OpenBuild 翻译整理，原文有删减）