Written by: Jun

Translated by: AididiaoJP, Foresight News

CryptoSlate’s Akiba (@akibablade) recently published an article titled “31 Newly Discovered Vulnerabilities Expose 99% of x402 Crypto Payments to Asset Theft and Free Shopping Risks.”

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 published 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 shared payment infrastructure used by multiple independent merchants. Once a facilitator is compromised, it may affect many services.

The researchers defined eight security rules that facilitators should follow. Violation of these rules can trigger four types of attacks: free shopping, asset theft, denial of service, and Gas abuse. They evaluated 15 major facilitators, uncovering 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 study was possible because x402 has been developed as an open protocol from the beginning. Its protocol specifications and reference SDK are publicly available, allowing researchers to derive security rules for the payment process. They conducted their research using an open-source SDK and a test merchant they set up themselves.

Open source does not eliminate vulnerabilities, but it provides a pathway for externally discovered flaws to be translated into shared security standards. The x402 protocol was transferred 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 level, not limited to patches from a single vendor.

The researchers also released a public version of x402scope, removing sensitive exploits. They are in discussions with Coinbase and other major ecosystem participants on how to integrate their rule checks into development and deployment validation processes.

Discussions about the maturity of the protocol end 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 resulting from security incidents?

Centralization does not automatically equate to security. However, in the payment domain, the party exercising power should also bear the costs of failures.

Let’s look at how x402 actually operates. Anyone can run a server or become a facilitator. But the system is not entirely trustless. The paper also defines facilitators as "trusted 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 lacks requirements for corresponding capital, accountability mechanisms, or payment certainty. This gap is reflected in three parts of the design.

First, verify feels 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 it neither locks funds nor consumes 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 a facilitator's verification results and the subsequent settlement fails, the merchant bears the entire loss.

Third, many facilitators will sponsor on-chain settlement costs. Attackers can manipulate execution paths, causing facilitators to pay the resulting Gas fees. On Solana, attackers could 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 degree of payment certainty. If something goes wrong, there are authorizations to revoke, chargebacks, merchant sanctions, and dispute resolution procedures available.

x402 lacks an issuing bank to lock funds and guarantee payments. Servers thus check payment viability through verify, execute business logic, and then call settle. The issue is that the two ends do not share state. After verification, balances, nonces, or validities can change. If the server performs irreversible operations before settlement, the merchant could incur losses. If the facilitator submits a manipulated transaction, it could lose Gas or assets it controls.

Card networks take on this trust cost through the issuing bank's capital and risk management teams and recover it through transaction fees. x402 removes that role but does not eliminate the costs.

So, is there a need to establish an accountability layer above the open protocol on the actual path?

This form of centralization does not mean handing the entire x402 protocol over to a single operator. Each payment route should have a clear responsible party. Multiple operators can still compete under the same open standard, allowing users to switch facilitators. This structure centralizes operational responsibility while maintaining the open nature 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 controls under a single control layer. Another path is to use specialized facilitators that provide service level agreements, Gas limits, pre-settlement re-verification, and incident response.

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

This perspective also demands 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 differentiate between centralized operators providing guarantees and payment routing. From this perspective, there are two key players worth watching:

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

Orthogonal (@orthogonal_sh)'s integration strategy unifies service discovery, API key pools, standardized responses, 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 discuss payment guarantees or loss absorption. However, they place fragmented wallet, verification, billing, and discovery functionalities under a single operator, laying the groundwork for a centralized accountability layer.

If a centralized accountability layer becomes widespread, 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 as long as settlements are irreversible. Once operators take on the responsibility for refunds and dispute handling, this assumption changes. Settlements can be confirmed first, eliminating the merchant's unpaid risk. If subsequent execution fails, the operator can refund the consumer. The operator then must bear the liquidity demand and settlement obligations before the final settlement, making its capital and accountability structure even more crucial.

This model does not follow x402's current per-transaction settlement process. x402 will continue to serve as an open interface to communicate payment terms and authorization data. Operators will aggregate actual fund flows and complete final settlements on-chain. Individual payment records will remain on the operator's internal ledger, while the blockchain will record the aggregated final settlement. Since the internal ledger is reversible, this structure reduces issues surrounding 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 among operators. Individual payments will remain off-chain. At least in this market, reliably playing this role may already be sufficient. The system can still take advantage of low settlement costs and programmable currency.