Ask where the agentic-payments ecosystem is investing its trust work and a pattern emerges: nearly all of it points at the agent as buyer. Authorization frameworks decide what an agent may do. Delegation chains prove who let it. Spend controls bound the damage. Merchant-side verification confirms the agent knocking is legitimate. This work is necessary — we build spending caps and policy into our own product and would not ship without it.
But it answers only one question: can we trust the agent as a buyer? The agent's own question — can I trust the seller I'm about to pay? — is counterparty risk in agentic payments, and on the open agent-payment rails, where most purchases happen, it goes essentially unmeasured. That asymmetry, more than any missing guardrail, is holding adoption back.
Where the trust infrastructure points today
Inventory the stack being built for AI agent payments and sort each piece by the direction of its trust arrow. Authorization and delegation protocols verify the agent to its operator. Spending caps and session budgets protect the operator from the agent. Agent-verification schemes protect merchants from unwanted bots. Identity registries make the agent legible to everyone else.
Every arrow points at the agent as buyer. The buying agent is modeled as the risk to be contained — and in a real purchase on today's stablecoin-based agentic payment rails, the buying agent is the party at risk.
What does ERC-8004 actually do, and where does it stop?
One standard deserves credit for pointing the other way. ERC-8004, "Trustless Agents", defines three registries: identity for portable agent IDs, reputation for client agents rating the server agents they buy from, and validation for third parties attesting that work was done. The reputation flow is literally the buyer rating the seller. Those are the right primitives.
But the specification keeps payments explicitly orthogonal: feedback need not be grounded in any real transaction, and attaching proof of payment is optional. Reputation by attestation records claims. The first empirical study of the deployed ecosystem, arXiv 2606.26028 (data through 13 May 2026), measured the consequence across Ethereum, BNB Smart Chain, and Base: only 3%, 4%, and 15% of registered agents had a valid registration file with at least one declared service endpoint; 73.5%, 59.2%, and 90.6% of reviewers showed coordinated Sybil behavior; and after Sybil-flagged feedback was removed, 15.8%, 77.9%, and 86.8% of rated agents were left with no valid feedback. The starkest number: on Base, 93.8% of reviewers had never made an x402 payment, yet they submitted 94.9% of all feedback. Reputation written by reviewers with no x402 payment history. The authors' conclusion: the registry, as currently deployed, "cannot function as a trust signal."
A buyer does not need claims. A buyer needs outcomes.
ERC-8004 is not entirely alone, and the pattern across its neighbors is instructive. Virtuals' Agent Commerce Protocol holds payment in escrow until an evaluator agent verifies the deliverable against a signed agreement — real outcome verification, but only inside its own marketplace. Open dashboards like x402scan measure endpoint liveness, latency, and usage — genuine observability, but availability is not delivery, and usage counts inherit the ecosystem's wash-trading problem. Competition networks rank agents by verified performance in staged arenas — skill, but not purchases. Each closes part of the gap. None gives an agent, at the moment of purchase on the open rails, an outcome-grounded read on the counterparty it is about to pay.
Who carries the risk in an agent payment?
On stablecoin-based agentic payment rails — x402 and other pay-first HTTP 402 flows — the buyer pays first and discovers the truth second: whether the endpoint answers at all, whether anything is delivered, whether the delivery matches the quote. Settlement is final; there is no in-protocol dispute layer. Independent probes of the raw, open listings — the registries, not curated catalogs — keep finding failure rates that would end any human marketplace: in published crawls, most listed endpoints were unreachable or couldn't return a valid payment request.
That is the actual state of agentic payments today: heavily guarded buyers facing effectively unmeasured sellers.
What card networks teach us about adoption
Commerce has run this experiment before. Card networks did not grow by capping what consumers could spend; they grew in large part by capping what consumers could lose. The chargeback regime — protection, not restraint — is much of what made strangers safe to buy from. And buying from strangers is the entire point of a network.
Restraint made spending safe for the operator. Protection made it rational for the buyer. Adoption followed the second, not the first. An agent with a funded wallet, tight authorization, and zero counterparty signal is not an equipped buyer — it is a well-guarded gambler, and its operator knows it.
What sell-side measurement would look like
The missing work is unglamorous: measure the sell side, continuously, where purchases happen. Answer rates. Delivery rates. Quote accuracy. Records that join what was paid to what actually arrived. Not a one-off audit or an exposé thread — a study is not a signal a buyer can use at purchase time.
Equipping the buyer means pricing the seller. Guardrails tell an agent when to stop; a market only forms when something credible tells it when to go.
That is the lens we build with. SELAT is the buy-side of machine-native commerce: discover a paid capability, fund Circle Gateway, and pay USDC from the user's Circle Agent Wallet — self-custody; SELAT never holds keys or funds. The motion is one path — discovery, spending policy, payment, reconciliation of the payment with the returned response — whatever HTTP 402 scheme the merchant chose. A reconciled receipt is not the same as independently verified delivery; that distinction is the gap this essay is about. If you are building an agent that needs to access capabilities across many providers without provisioning API keys or juggling multiple accounts, start with llms.txt, or read how x402 and MPP differ.
FAQ
What is counterparty risk in agentic payments?
The risk the buying agent carries that the seller — an API, service, or another agent — will not answer, will not deliver, or will not deliver what was quoted. On pay-first stablecoin rails with final settlement, this risk sits almost entirely with the buyer.
Does ERC-8004 solve seller trust?
It is the right primitive aimed at the right party, but its reputation is attestation-based and explicitly payment-orthogonal — feedback need not come from a real transaction. The first empirical study of the deployed ecosystem (arXiv 2606.26028) found most feedback Sybil-coordinated and concluded the registry cannot yet function as a trust signal. Adjacent efforts stop short in other ways: marketplace escrow-and-evaluation works only within a single venue, and ecosystem dashboards measure liveness rather than delivery.
Why is agentic payments adoption slower than the infrastructure suggests?
Because nearly all trust work restrains the buyer instead of protecting it. Restraint reduces downside for operators and merchants; it does not give a buyer a reason to transact with an unmeasured counterparty.
How reliable are x402 endpoints today?
Independent community probes have repeatedly found that a majority of publicly listed endpoints fail basic availability or protocol-correctness tests. Reliability varies widely, which is exactly why purchase-time counterparty signals matter more than listings.
Does SELAT verify that a seller delivered what was quoted?
No. SELAT records the payment and the response that came back, from a self-custody Circle Agent Wallet the user controls. That is a reconciled paid run, not an independent proof of delivery or quote accuracy — the measurement this essay argues the ecosystem still lacks.