x402 has been live since May 2025 and most of the coverage is still focused on the payment mechanics. That’s understandable. The mechanics are impressive. An AI agent requests a resource, receives a price in the HTTP response, signs a payment proof, and settles fractions of a cent in USDC on Base in roughly two seconds. No accounts, no API keys, no KYC.

But payments are the easy part. The harder problem—the one that actually determines whether autonomous agent commerce works at enterprise scale—is trust. Who is the agent on the other end of that transaction? How do you know it will deliver? And when it doesn’t, what recourse do you have?

That’s the problem I want to work through here.

What x402 Actually Does (and Doesn’t)

HTTP 402 “Payment Required” has been in the spec since the 1990s. It sat unused for thirty years because there was no digital cash and no sub-cent settlement layer, so the web defaulted to advertising instead. Two things changed that: USDC hit $75B in circulation and Base fees collapsed to fractions of a cent. x402 activated the dormant status code.

The protocol is deliberately minimal. Server responds 402 with a price, token type, and wallet address. Agent retries with a signed payment proof. Facilitator verifies and settles onchain. Resource delivered. Cloudflare and Stripe have documented direct x402 support, and one recent research estimate puts total volume at roughly $46.5M across approximately 165 million transactions.

What x402 explicitly doesn’t address: whether the agent paying is legitimate, whether it will honor its commitments, or whether you should trust it with a $100,000 engagement versus a $0.001 API call. That trust boundary is where three recently proposed ERC standards come in, and where I think the real architectural work is happening.

The Three-Layer Trust Stack

Layer 1: ERC-8004 — Know Your Agent

Traditional finance has KYC. Agentic commerce needs KYA. ERC-8004 defines a portable onchain identity for AI agents. Each agent gets an ERC-721 NFT as its credential, linked to metadata describing capabilities, endpoints, and provenance, portable across chains.

On top of that sits a Reputation Registry for verifiable track records and a Validation Registry for cryptographic proof of execution via TEEs, zkML, or staking. Any third party can verify an agent’s claimed history without trusting a central intermediary. There are currently around 70,000 registered agents across Ethereum, Base, and BNB.

Here’s the gap I’d flag for enterprise evaluators: ERC-721 passports are transferable. Accumulated reputation moves with the identity.

The co-author acknowledged this publicly. The standard relies on onchain visibility and reputational consequences as deterrents, not technical enforcement. For enterprise transactions that’s a trust model worth scrutinizing carefully. It behaves more like SSL certificate reputation than hardware-rooted identity attestation, and those are not the same thing.

Layer 2: ERC-8126 — The Risk Score

ERC-8004 handles identity. ERC-8126 adds a quantified trust signal: a 0–100 score any counterparty can query before transacting. Four verification types feed into it: onchain contract verification, staking contracts (skin in the game), web endpoint verification, and wallet transaction history analysis. Each generates a ZK-style proof via off-chain providers. Detailed results stay private to the agent’s wallet holder. The aggregated score is public.

The ZK approach is the right call. You get counterparty assurance without exposing the underlying data—the same trust model used in privacy-preserving credential systems, now applied to non-human actors.

My concern is score inflation. Anyone can implement ERC-8126 verification, and if verification services compete on leniency to attract agents, the 0–100 scale becomes noise.

There’s no minimum bar enforcement in the standard, which means a race to the bottom is structurally possible. We saw exactly this dynamic with credit rating agencies before 2008. I’m not saying it will happen. I’m saying the incentive structure allows it, and that’s worth building controls around.

Layer 3: ERC-8183 — The Commerce Contract

Published March 10, 2026. x402 handles payment. ERC-8004 handles identity. Neither handles the actual commercial relationship: agreed terms, escrow, delivery verification, dispute resolution.

ERC-8183 defines a single primitive for that: the Job. Client posts requirements and funds escrow. Funds revert automatically if no provider acts before the deadline. The agent executes and submits a verifiable deliverable onchain. An Evaluator attests to completion, triggering payment release or refund.

The Evaluator is defined only as an onchain address. It can be an LLM, a ZK verifier contract, or a multi-sig. The same interface handles a $0.10 image generation call and a $100,000 capital management engagement.

Every completed Job feeds a reputation signal back into ERC-8004. For the first time at this level of adoption, there’s a standard way to encode “did the agent do what it said it would do” into a verifiable, auditable, onchain record. That matters.

What’s Still Unresolved

The Evaluator problem. Everything runs through the Evaluator’s judgment. If the Evaluator is an LLM, who’s auditing the LLM? If it’s a multi-sig, you’ve reintroduced the human approval gate the protocol was designed to remove. High-value autonomous commerce needs a more rigorous attestation model—the kind enterprises use for non-repudiation in financial systems. This isn’t a knock on ERC-8183. It’s the hardest part of the problem and the spec doesn’t claim to have solved it.

The reputation inheritance gap. Transferable ERC-721 passports mean reputation can be bought and sold alongside identity. At sub-cent scales that’s noise. At enterprise scales it’s a real attack surface. A rogue actor buys a high-reputation agent identity and immediately has credibility it didn’t earn. I’d want to see revocation and transfer controls hardened before I’d recommend this stack for high-value production deployments.

The verification race to the bottom. I already flagged this in the ERC-8126 section, but it bears repeating here: no minimum bar enforcement on verification services is a structural vulnerability, not a theoretical one. The standard needs either a credentialing layer for verifiers or a mechanism that penalizes score inflation after the fact.

Where I Land

x402 plus ERC-8004, 8126, and 8183 is the most complete attempt to solve autonomous agent commerce that exists right now. Cloudflare and Stripe are in. Visa and Google are shaping the broader ecosystem. Roughly $3.5M in x402-mediated volume over the last 30 days without centralized oversight. This infrastructure is moving.

But there’s architectural debt in the enterprise trust model that I don’t think is getting enough attention in the coverage I’m seeing. These aren’t fundamental flaws. They’re the difference between infrastructure that works in a permissive environment and infrastructure that holds up under adversarial conditions.

If you’re evaluating x402 for a production deployment, I’d start with two questions before anything else: Who controls the Evaluator, and what’s the attestation model for high-value Jobs? And what’s the identity revocation mechanism when an agent’s ERC-721 passport is compromised or transferred?

The answers aren’t in the spec yet. That’s where the work is, and that’s the interesting part.

What questions are you asking before you put autonomous agents on the payment layer?