Should Your Agent Pay via x402? Why Agentic Commerce Needs a Check First

Agentic commerce is usually described as a stack: x402 moves the money, discovery layers like Coinbase's Bazaar catalog make endpoints findable, and ERC-8004 provides on-chain identity and reputation so a payment isn't just money sent to a stranger. We've written about that stack before. What we hadn't done until recently was check whether the stack, as actually deployed today, gives an agent enough to make a safe payment decision on its own. It doesn't — and we have real numbers, not a guess, to show why.

What We Actually Found

We pulled 135 real, live services from Coinbase's own public x402 Bazaar catalog — not a curated "best of" list, a representative sample of what's actually listed as agent-payable right now — and ran them through ContextIQ's own free tools. The results:

33% have no SPF record at all.
63% aren't actively enforcing DMARC — missing, set to p=none, or monitoring-only.
27% have zero agent-discoverability signal whatsoever: no llms.txt, no MCP, no A2A, no ARD.

None of that shows up in an x402 402 response. A service can be fully compliant with the payment protocol — correct challenge shape, valid network, real USDC address — while having no email-spoofing protection and no way for an agent to learn anything about it beyond "send money here." "This endpoint speaks x402" and "this endpoint is safe to pay" are unrelated claims, and right now, a meaningful fraction of the ecosystem only satisfies the first one.

What a 402 Challenge Actually Tells You

Read the x402 spec literally and a 402 response is remarkably narrow. It tells you: this scheme, this network, this exact amount, this address, this timeout. That's the entire contract. It does not tell you:

Whether the operator has ever done business with anyone before.
Whether the wallet receiving payment is even the same one the operator's own published identity claims to use.
Whether the challenge itself is internally consistent, or just happens to parse.
Whether the endpoint is reachable at all beyond the single request that produced the 402.

An agent that pays as soon as it sees a well-formed challenge is trusting exactly as much as that challenge contains — which, per the numbers above, is often not much. This is the actual gap in "agentic commerce is live": the payment rail works, but the pre-payment judgment call has been left to each agent to improvise, usually by not making it at all.

How Policy Check Answers It

Policy Check exists specifically to fill that gap, by combining two things ContextIQ already builds independently — ERC-8004 identity/reputation lookup and x402 challenge validation — into a single call an agent framework makes right before authorizing payment:

curl -X POST https://contextiq.trango-compute.com/api/v1/policy-check \
  -H "Content-Type: application/json" \
  -d '{"endpoint": "https://api.example.com/paid-resource", "agentId": "1", "network": "ethereum"}'

The response is a categorical allow / warn / block decision backed by a transparent 0–100 score — every point traced to a named check, never a black box:

Identity (35 pts) — is the counterparty even registered on ERC-8004? Does it have a wallet set, resolvable metadata, and does its own declared x402 endpoint actually match the one you're about to pay?
Reputation (25 pts) — how many distinct clients have given feedback, not how positive it is. ERC-8004 doesn't standardize a value scale across registrations, so scoring the magnitude of feedback would be fabricated precision; breadth of independent feedback is the signal that's actually comparable.
Payment (40 pts) — is the challenge well-formed, free of spec-hygiene warnings, on a recognized network?

block is reserved for genuine impossibility — no identity to check at all, or a target that's actually unreachable — never for "the score was too low." Deciding how much reputation is "enough" is the caller's judgment call, not something ContextIQ makes unilaterally on an agent's behalf. Five real worked examples show exactly what this looks like against currently-registered agents, and a full technical walkthrough covers calling it via x402 payment instead of an API key, if that's the integration you need.

Where This Sits in an Agent's Decision Loop

The intended call site is narrow and specific: your agent framework gets a 402 from some counterparty, and instead of immediately signing a payment, it calls Policy Check with that same endpoint plus the counterparty's ERC-8004 agentId and network. The response's decision field is enough to gate on directly — allow proceeds to the normal x402 pay-and-retry flow, block or warn routes to a human, a fallback provider, or just gets logged and skipped. Agents that want finer control can apply their own threshold to score and read reasons for the specific factors that mattered, rather than trusting a single opaque gate.

What This Doesn't Solve

Worth being direct about the limits, the same way we are about ContextIQ's other inspectors: a block on identity means "not registered," not "malicious" — plenty of legitimate services simply haven't registered with ERC-8004 yet. A high reputation score means "many independent clients left feedback," not "verified good," since ERC-8004's Validation Registry — the piece meant to carry independent attestations — has no canonical deployed address yet, so it isn't part of the score. And a clean x402 challenge only means the payment mechanics are sound; it says nothing about whether the resource you're paying for will actually be delivered as described. Policy Check turns "we found real, checkable signals" into a decision you can act on automatically — it doesn't turn those signals into a guarantee.

Try It

The 135-service numbers above and the check itself run on the same free tools — DNS Inspector and Agent Protocol Inspector for the ecosystem scan, ERC-8004 Inspector and x402 Inspector feeding directly into Policy Check's combined decision. If you're building an agent that pays autonomously, the practical move is wiring Policy Check into the moment right before that payment gets signed — not after something's already gone wrong.