x402 v2 与 x402x：把付费 API 推向可演进的标准

x402 v2 发布，这不是一次简单升级，而是把 x402 从“一套实现”，推进为“一套可演进的标准 + 可插拔的参考实现”。让 x402 不再只是一个 SDK，而真正像一门互联网原生的付费接口语言。

从 v1 到 v2

在 v1 时代，x402 的模型非常简单：

服务端要钱 -> 客户端签名并支付 -> 服务端验证 -> 结算完成

这个模型很好理解，但也非常“直线”。

一旦你需要更多网络、更多支付方式，或者更复杂的结算形态，你很快就会走到 fork SDK、打补丁、私下维护协议边角的路径上。能跑，但生态很难协同演进。

x402 v2 的核心变化可以压缩成一句话：它把“变化”从核心协议里移了出去。

变化不再通过“改 spec / 改 core”引入，而是被明确安放在 Extensions、插件式机制（mechanisms）和生命周期 hooks 中。

这一步非常关键，因为它决定了生态中的新能力，能否在不修改核心协议前提下并行演进。

协议层：更 HTTP-native

首先是协议层，x402 变得更加 HTTP-native。

402 的语义回到 402，本该标准化的支付元数据进入 header；应用层可以自由返回 HTML paywall、JSON 或任意 body，而中间件和 facilitator 依然可以稳定处理支付语义。

这让支付协议第一次真正适配了现有互联网基础设施。

架构层：注册制和生命周期 hooks

其次是架构层。SDK 引入了注册制和生命周期 hooks。

支持新网络、新 scheme，不再需要往 core 里堆 if/else，而是实现接口并注册。

hooks 为策略性逻辑提供了官方入口，但核心 SDK 本身被收敛为“流程编排者”，而不是业务能力的承载者。

Extensions 的意义

再往上一层，是 Extensions 的意义。

v2 为生态提供了一个标准化的“可选能力槽位”。像 Discovery、Identity，以及 Settlement Router / Programmable Settlement 这类能力，都可以通过 Extension 被声明、被协商，并逐步形成共识。

服务端可以声明它支持哪些扩展，facilitator 可以声明实现了哪些扩展，客户端也可以据此选择或组合。这才是一个标准能够长期演进的方式。

x402x 在 v2 里的位置

在这个背景下，再看 x402 v2 对 x402x 的意义。

x402x 是 Settlement Router 这一类扩展的一个具体实现。

它通过一个 SettlementRouter 链上合约，提供了原子化、可编程、可组合的链上结算路径：

• 结算可以被路由到多个 recipient
• 可以原生支持分账和抽成
• 可以通过合约 Hook 和其他链上合约无缝组合，例如 token mint、DeFi 调用，或其他基于链上状态的结算逻辑

在 x402 v1 时代，这类结算能力往往需要 hack 核心协议，引入特殊的路由处理逻辑；而在 x402 v2 中，借助 Extensions 和注册制机制，它们第一次可以以标准扩展的形式存在，而不是以 fork 的形式存在。

这带来的变化是结构性的：

x402x 的价值不再来自实现路径本身，而来自它所表达的结算语义，以及这些语义在链上合约生态中的可组合性。

总结

x402 v2 让“付费 API”第一次具备了互联网规模化协作的结构条件。

而像 x402x 这样的结算扩展，也终于可以在这个标准框架内生长，不需要 hack 核心协议，而是作为 Extensions，被选择、被组合、被演进。