Centralized Responsibility Is All x402 Needs

CryptoSlate’s Akiba (@akibablade) published an article titled “31 newly discovered vulnerabilities expose 99% of x402 crypto payments to asset theft and free shopping.”

Source: “When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments”

The article draws on the paper “When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments,” which was accepted for presentation at USENIX Security 2026.

The paper examines how x402 delegates payment proof verification and on-chain settlement to third-party facilitators. This design concentrates trust and verification logic in shared payment infrastructure used by multiple independent merchants. A flaw in one facilitator can therefore affect many services.

Source: “When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments”

The researchers also defined eight security rules that facilitators should follow. Violations of these rules led to four attack types: Free Shopping, Asset Theft, Service Denial, and Gas Abuse. The researchers evaluated 15 major facilitators and found 49 rule violations and 31 previously unknown vulnerabilities. They privately disclosed the findings to the relevant operators. Some issues have since been fixed, while work on the remaining issues is underway.

This research was possible because x402 was developed as an open protocol from the outset. Its protocol specification and reference SDK were public, which allowed the researchers to derive security rules for the payment flow. They conducted the study with the open-source SDK and a test merchant they built themselves.

Open source does not eliminate vulnerabilities. It does, however, provide a path for turning externally discovered flaws into shared security standards. The x402 protocol moved to the Linux Foundation on April 2, and the x402 Foundation formally began operations with 40 members on July 14. This created an official forum where findings can be discussed at the specification and reference implementation levels, beyond patches by individual vendors.

The researchers also released a public version of x402scope with sensitive exploit code removed. They are now discussing ways to integrate its rule checks into development and pre-deployment validation workflows with Coinbase and other major ecosystem participants.

That is enough on the protocol’s maturity. I want to raise one more basic question from the findings.

Rather than centralizing x402 itself, does an open protocol need a centralized accountability layer that enforces verification standards and bears settlement costs and losses from security incidents?

Centralization does not automatically guarantee security. In payments, however, the party that exercises authority should also bear the cost of failure.

Consider how x402 works. Anyone can operate a server or become a facilitator. Yet the system is not fully trustless. The paper also defines a facilitator as a “trust-bearing intermediary.” Once verification and settlement are delegated, users must place considerable trust in the facilitator.

The problem is that trust is concentrated, while the protocol does not require corresponding capital, accountability, or payment certainty. This gap appears in three parts of the design.

Source: Coinbase

• First, verify is closer to a prediction that settlement remains possible at that moment than to card authorization. It checks the signature, balance, nonce, and expiration time, but it neither locks the funds nor consumes the nonce.
• Second, verify → business logic → settle is separated to protect both consumers and merchants. The protocol has no mechanism that binds verification and settlement through shared state. If a merchant acts based on a facilitator’s verification result and settlement later fails, the merchant bears the full loss.
• Third, many facilitators sponsor on-chain settlement costs. An attacker can manipulate an execution path and make the facilitator pay the resulting gas costs. On Solana, an attacker may also induce the facilitator to pay rent for accounts controlled by the attacker.

Card payments also separate authorization from capture. The difference is that the issuer reserves part of the cardholder’s credit limit or funds during authorization. Network rules then provide the merchant with some degree of payment certainty. If a problem occurs, authorization reversals, chargebacks, merchant sanctions, and dispute procedures are available.

x402 has no issuer that locks funds and guarantees payment. The server therefore checks payment feasibility through verify, executes the business logic, and then calls settle. The problem is that the two endpoints do not share state. The balance, nonce, or validity period may change after verification. If the server performs an irreversible action before settlement, the merchant may incur a loss. If the facilitator submits a manipulated transaction, it may lose gas or assets under its control.

Card networks bear the cost of this trust through issuer capital and risk management teams, then recover it through fees. x402 removed that actor, but it did not remove the cost.

Does the practical path therefore require an accountability layer above the open protocol?

Centralization here does not mean placing the entire x402 protocol under one operator. Each payment route should have a clear accountable party. Multiple operators should still compete under the same open standard, and users should be able to switch facilitators. This structure concentrates operational responsibility while retaining protocol openness and competition between providers.

Cloudflare’s Monetization Gateway is one possible example. It retains x402’s programmable payment format while handling payment policies, verification, and access control within one control layer. Another path would use professional facilitators that provide service-level agreements, gas limits, pre-settlement revalidation, and incident response.

ERC-8004 and reputation systems may appear to offer an alternative. Reputation, however, is only an additional signal for assessing risk. It does not reserve funds or provide a payment guarantee. I do not think reputation alone can fill the accountability gap.

This perspective also calls for a review of the role and structure of the discovery layer. The layer could move beyond listing available services and become a trust and routing layer that screens which resources and facilitators meet defined security standards. If payment guarantees are required, it could clearly distinguish the centralized operators and payment routes that provide them. From this perspective, two key players stand out:

• CDP’s (@CoinbaseDev) integrated strategy combines Agentic Wallet, CDP Facilitator, and Bazaar to provide wallets, payments, compliance, and discovery in one stack.
• Orthogonal’s (@orthogonal_sh) integrated strategy combines service discovery, API key pooling, response normalization, and billing under one account, one balance, and one invoice. It supports credits, x402, and MPP. This places the complexity of managing multiple providers and payment methods inside a central gateway.

These strategies do not yet amount to payment guarantees or loss absorption. However, they place fragmented wallet, verification, billing, and discovery functions under one operator. This provides the basis for a centralized accountability layer.

If centralized accountability layers become common, the payment structure may also change. One possible model would replace verify → business logic → settle with verify → settle → business logic.

The current sequence protects consumers on the assumption that settlement cannot be reversed. That assumption changes once an operator accepts responsibility for refunds and dispute handling. Settlement could be confirmed first, removing the merchant’s risk of nonpayment. If execution later fails, the operator could refund the consumer. The operator would instead bear liquidity needs and settlement obligations until final settlement, which makes its capital and accountability structure more important.

This model does not follow x402’s current per-transaction settlement flow. x402 would remain an open interface for communicating payment terms and authorization data. The operator would aggregate actual fund movements and complete final settlement on-chain. Individual payment records would remain on the operator’s internal ledger, while the blockchain would record the aggregated final settlement. Because the internal ledger is reversible, this structure reduces the problem of irreversible payments. The operator could also handle refunds and disputes in a role similar to a card issuer.

Someone may then ask:

Does this simply use the blockchain as a shared payment database?

Yes.

More precisely, the blockchain would be a shared settlement ledger that records final balances between operators. Individual payments would remain outside it. At least in this market, performing that role reliably may be enough. The system could still use low settlement costs and programmable money.