据 Woofun AI 消息，x402 支付协议近期暴露出严重的安全隐患，Akiba（@akibablade）基于即将在 USENIX Security 2026 会议上发表的论文指出，该协议存在 31 个新漏洞，导致 99% 的交易面临资产盗窃风险。

这一发现不仅揭示了当前加密支付基础设施的脆弱性，更引发了关于开放协议是否需要引入中心化问责层的深层讨论。核心问题在于，当验证与结算逻辑被委托给第三方时，缺乏相应的资本约束与责任机制，使得系统极易受到攻击。

深入剖析这些漏洞，研究者定义了 facilitator（支付促进者）应遵守的八条安全规则，违反这些规则会引发四类攻击：免费购物、资产盗窃、服务拒绝和 Gas 滥用。在对 15 家主要 facilitator 进行的评估中，发现了 49 项规则违规和 31 个此前未知的漏洞。研究结果已私下披露给相关运营方，部分问题已得到修复，其余问题的修复工作正在进行中。这项研究之所以能开展，是因为 x402 从一开始就作为开放协议开发，其协议规范和参考 SDK 均公开。

x402 协议已于 4 月 2 日移交 Linux 基金会，x402 Foundation 也于 7 月 14 日正式启动运营，拥有 40 名成员。这为在规范和参考实现层面讨论发现结果提供了官方论坛。研究者还发布了 x402scope 的公开版本，已移除敏感的利用代码，并正与 Coinbase 及其他主要生态参与者讨论，如何将其规则检查整合进开发和部署前验证流程。

从信任架构的角度看，x402 的实际运作方式存在根本缺陷。任何人都可以运营服务器或成为 facilitator，但系统并非完全无信任。论文把 facilitator 定义为"承担信任的中介"。一旦验证和结算被委托出去，用户就必须对 facilitator 投入相当程度的信任。

然而，信任被集中了，协议却没有要求相应的资本、问责机制或支付确定性。这一缺口体现在设计的三个部分。第一，verify（验证）更像是在预测"此时结算仍然可行"，而不是像信用卡授权那样。它检查签名、余额、nonce 和过期时间，但既不锁定资金，也不消耗 nonce。第二，verify → 业务逻辑 → settle（结算）的分离本意是保护消费者和商家，但协议没有机制通过共享状态把验证和结算绑定在一起。

如果商家基于 facilitator 的验证结果采取行动，而后续结算失败，商家就要承担全部损失。第三，许多 facilitator 会赞助链上结算成本，攻击者可以操纵执行路径，让 facilitator 支付由此产生的 Gas 费用。在 Solana 上，攻击者甚至可能诱导 facilitator 为攻击者控制的账户支付租金。

Woofun AI 整理数据显示，相比之下，信用卡支付也分离了授权和扣款，但发卡行在授权时会预留持卡人的部分信用额度或资金，网络规则随后为商家提供一定程度的支付确定性。

如果出问题，还有授权撤销、拒付、商家制裁和争议处理程序可用。x402 没有发卡行来锁定资金并担保支付，服务器因此通过 verify 检查支付可行性，执行业务逻辑，然后再调用 settle。问题在于，两端并不共享状态，验证之后，余额、nonce 或有效期都可能发生变化。

如果服务器在结算前执行了不可逆操作，商家就可能蒙受损失。如果 facilitator 提交了被操纵的交易，它可能损失 Gas 或自己控制的资产。卡网络通过发卡行资本和风险管理团队承担了这种信任成本，再通过手续费收回。x402 移除了那个角色，却没有移除成本。因此，实际路径是否需要在开放协议之上建立一个问责层？这里的中心化并不意味着把整个 x402 协议交给单一运营方，每条支付路由都应有明确的责任主体。多个运营方仍可在同一开放标准下竞争，用户也能切换 facilitator。

这种结构集中了运营责任，同时保留了协议开放性和提供商之间的竞争。

Cloudflare 的 Monetization Gateway 就是一个可能的例子，它保留了 x402 的可编程支付格式，同时在单一控制层处理支付策略、验证和访问控制。另一条路径是使用专业 facilitator，提供服务等级协议、Gas 限额、结算前再验证和事件响应。ERC-8004 和声誉系统看似提供了替代方案，但声誉只是评估风险的额外信号，它既不预留资金，也不提供支付担保。单靠声誉无法填补问责缺口。

这一视角也要求重新审视发现层的角色和结构，该层可以超越单纯列出可用服务，成为信任和路由层，筛选哪些资源和 facilitator 符合既定安全标准。如果需要支付担保，它可以明确区分提供担保的中心化运营方和支付路由。从这个角度看，有两个关键玩家值得关注：CDP（@CoinbaseDev）的整合策略把 Agentic Wallet、CDP Facilitator 和 Bazaar 结合在一起，在一个技术栈中提供钱包、支付、合规和发现功能。

Orthogonal（@orthogonal_sh）的整合策略把服务发现、API 密钥池、响应标准化和计费统一在一个账户、一个余额和一张发票下。它支持 credits、x402 和 MPP，这把管理多个提供商和支付方式的复杂性放进了中央网关。这些策略目前还谈不上支付担保或损失吸收，但它们把碎片化的钱包、验证、计费和发现功能置于单一运营方之下，为中心化问责层提供了基础。

如果中心化问责层变得普遍，支付结构本身也可能改变。一种可能的模型是把 verify → 业务逻辑 → settle 替换为 verify → settle → 业务逻辑。当前顺序保护消费者，前提是结算不可逆。一旦运营方接受退款和争议处理责任，这一假设就会改变。可以先确认结算，消除商家的未付款风险。

如果后续执行失败，运营方可以退款给消费者。运营方则需承担最终结算前的流动性需求和结算义务，这让其资本和问责结构变得更加重要。这种模型并不遵循 x402 当前的逐笔结算流程，x402 将继续作为沟通支付条款和授权数据的开放接口。运营方会聚合实际资金流动，并在链上完成最终结算。单笔支付记录保留在运营方内部账本，区块链则记录聚合后的最终结算。因为内部账本可逆，这种结构降低了不可逆支付的问题。运营方也可以像发卡行一样处理退款和争议。有人可能会问："这不就是把区块链当成共享支付数据库吗？"是的。更准确地说，区块链会成为记录运营方之间最终余额的共享结算账本。单笔支付则留在链外。至少在这个市场中，可靠地扮演这一角色或许已经足够。系统仍可利用低结算成本和可编程货币的优势。