The Trust Trap of Open Protocols: Why Does x402 Need a Centralized Accountability Layer?

The x402 payment protocol has revealed 31 new vulnerabilities, putting 99% of transactions at risk of asset theft.

Written by: @Jun__Yoo

Compiled by: AididiaoJP, Foresight News

Akiba (@akibablade) from CryptoSlate recently published an article titled "31 Newly Discovered Vulnerabilities Put 99% of x402 Crypto Payments at Risk of Asset Theft and Free Shopping."

This article is based on a paper titled "When HTTP 402 Meets Blockchain: Risks of Emerging x402 Payments." The paper has been accepted and will be presented at the USENIX Security 2026 conference.

The paper focuses on how x402 delegates payment proof verification and on-chain settlement to third-party facilitators. This design centralizes trust and verification logic onto a shared payment infrastructure used by multiple independent merchants. If a facilitator has a vulnerability, it can affect a large number of services.

The researchers also defined eight security rules that facilitators should adhere to. Violating these rules can lead to four types of attacks: free shopping, asset theft, denial of service, and gas abuse. They assessed 15 major facilitators and found 49 rule violations and 31 previously unknown vulnerabilities. The findings have been privately disclosed to the relevant operators. Some issues have been resolved, while others are still being addressed.

This research was possible because x402 has been developed as an open protocol from the start. Its protocol specifications and reference SDK are publicly available, allowing researchers to derive security rules for the payment process. They conducted the research using open-source SDKs and their own test merchants.

Open sourcing does not eliminate vulnerabilities, but it provides a pathway for externally discovered flaws to be transformed into shared security standards. The x402 protocol was handed over to the Linux Foundation on April 2, and the x402 Foundation officially began operations on July 14, with 40 members. This provides an official forum for discussing findings at the specification and reference implementation levels, rather than being limited to patches from individual vendors.

The researchers also released a public version of x402scope, which has removed sensitive exploit code. They are in discussions with Coinbase and other major ecosystem participants on how to integrate their rule checks into pre-development and deployment verification processes.

The discussion on the maturity of the protocol ends here. I would like to raise a more fundamental question from these findings.

Rather than centralizing x402 itself, does an open protocol need a centralized accountability layer to enforce verification standards and bear the settlement costs and losses arising from security incidents?

Centralization does not automatically equate to security. However, in the payment domain, those who wield power should also bear the costs of failure.

Let’s look at how x402 actually operates. Anyone can operate a server or become a facilitator. But the system is not completely trustless. The paper also defines facilitators as "trust-bearing intermediaries." Once verification and settlement are delegated, users must place a considerable degree of trust in the facilitator.

The problem is that trust is centralized, but the protocol does not require corresponding capital, accountability mechanisms, or payment certainty. This gap is reflected in three parts of the design.

First, verify is more like predicting "settlement is still feasible at this moment" rather than like credit card authorization. It checks signatures, balances, nonces, and expiration times, but does not lock funds or consume nonces.

Second, the separation of verify → business logic → settle is intended to protect consumers and merchants. The protocol lacks a mechanism to bind verification and settlement together through shared state. If a merchant acts based on the facilitator's verification results and the subsequent settlement fails, the merchant bears the entire loss.

Third, many facilitators sponsor on-chain settlement costs. Attackers can manipulate execution paths, causing facilitators to pay the resulting gas fees. On Solana, attackers may even induce facilitators to pay rent for accounts controlled by the attackers.

Credit card payments also separate authorization and deduction. The difference is that issuing banks reserve part of the cardholder's credit limit or funds during authorization. Network rules then provide merchants with a certain degree of payment certainty. If something goes wrong, there are options for authorization revocation, chargebacks, merchant sanctions, and dispute resolution processes.

x402 does not have issuing banks to lock funds and guarantee payments. Servers thus check payment feasibility through verify, execute business logic, and then call settle. The problem is that the two ends do not share state. After verification, balances, nonces, or expiration times may change. If the server performs an irreversible operation before settlement, the merchant may incur losses. If the facilitator submits a manipulated transaction, it may lose gas or assets it controls.

Card networks bear this trust cost through the capital and risk management teams of issuing banks, and then recover it through fees. x402 removes that role but does not eliminate the cost.

Therefore, does the actual path need to establish an accountability layer above the open protocol?

This centralization does not mean handing the entire x402 protocol over to a single operator. Each payment route should have a clear responsible entity. Multiple operators can still compete under the same open standard, and users can switch facilitators. This structure centralizes operational responsibility while retaining the openness of the protocol and competition among providers.

Cloudflare's Monetization Gateway is a possible example. It retains the programmable payment format of x402 while handling payment policies, verification, and access control at a single control layer. Another path is to use specialized facilitators that provide service level agreements, gas limits, pre-settlement verification, and event response.

ERC-8004 and reputation systems seem to offer alternatives. However, reputation is merely an additional signal for assessing risk; it neither reserves funds nor provides payment guarantees. I believe that reputation alone cannot fill the accountability gap.

This perspective also requires a re-examination of the role and structure of the discovery layer. This layer can go beyond merely listing available services to become a trust and routing layer, filtering which resources and facilitators meet established security standards. If payment guarantees are needed, it can clearly distinguish between centralized operators providing guarantees and payment routing. From this perspective, there are two key players worth noting:

The integration strategy of CDP (@CoinbaseDev) combines Agentic Wallet, CDP Facilitator, and Bazaar to provide wallet, payment, compliance, and discovery functions within a single tech stack.

Orthogonal's (@orthogonal_sh) integration strategy unifies service discovery, API key pools, response standardization, and billing under a single account, a single balance, and a single invoice. It supports credits, x402, and MPP. This centralizes the complexity of managing multiple providers and payment methods into a central gateway.

These strategies currently do not provide payment guarantees or loss absorption. However, they place fragmented wallets, verification, billing, and discovery functions under a single operator, laying the foundation for a centralized accountability layer.

If a centralized accountability layer becomes common, the payment structure itself may also change. One possible model is to replace verify → business logic → settle with verify → settle → business logic.

The current order protects consumers, provided that settlements are irreversible. Once operators accept responsibility for refunds and dispute resolution, this assumption will change. Settlement can be confirmed first, eliminating the merchant's risk of unpaid amounts. If subsequent execution fails, the operator can refund the consumer. The operator would then need to bear the liquidity demands and settlement obligations before the final settlement, making its capital and accountability structure more important.

This model does not follow x402's current per-transaction settlement process. x402 will continue to serve as an open interface for communicating payment terms and authorization data. Operators will aggregate actual fund flows and complete final settlements on-chain. Individual payment records will be retained in the operator's internal ledger, while the blockchain will record the aggregated final settlement. Because the internal ledger is reversible, this structure reduces the issue of irreversible payments. Operators can also handle refunds and disputes like issuing banks.

One might ask:

Isn't this treating the blockchain as a shared payment database?

Yes.

More accurately, the blockchain will become a shared settlement ledger recording the final balances between operators. Individual payments will remain off-chain. At least in this market, reliably playing this role may already be sufficient. The system can still leverage the advantages of low settlement costs and programmable currency.