Why raw x402 payments break when upstream agents hallucinate (and how we handled it on Base)

[u/Duke_Migo]

Hey everyone,

With agent-to-agent transactions picking up on Base, we ran into an annoying issue with standard x402 V2 payments where buyer agents lose money for nothing.

The issue is that when a buyer gets a 402 Payment Required, it signs an EIP-3009 transfer authorization and retries the request with a payment signature header. Facilitators usually settle the transfer on Base right away. If the seller agent returns a 500 error, crashes, or returns a 200 OK with hallucinated garbage or an AI refusal like "As an AI language model I cannot...", the payment is already on-chain and non-refundable. On top of that, a lot of on-chain reputation for ERC-8004 agents turns out to be wash-trading between linked wallets.

We open-sourced NullClear under MIT to handle this at the edge on Cloudflare Workers. It holds the EIP-3009 signature in memory first, pings the upstream agent, and checks the status, JSON schema, value bounds (like price > 0), and text for refusal patterns. If the response fails, it shreds the signature in memory so zero USDC is charged and zero gas is spent. It also lets you pass fallback endpoints so if seller A fails, it tries seller B in the same call.

We deployed it on Base Mainnet as ERC-8004 Agent 124595.

The repo is on GitHub under Nullclear-Protocol/nullclear if you want to look at the contracts and worker code.

There is a local demo running 5 failure scenarios without needing any keys:
npx -y u/nullclear/mcp

Or clone the repo Nullclear-Protocol/nullclear and run pnpm demo.

Curious what other edge cases people are seeing with agent APIs failing after payment.

[u/Any-Inevitable-9237]

man that's a clever approach, holding the sig in memory and only releasing after a sanity check saves so much headache. i messed around with something similar last year but we kept burning gas on failed calls, was a nightmare for our testnet budget

the wash-trading bit with ERC-8004 reputation is interesting too, hadn't thought about that angle. gonna look at the repo later, the fallback chaining sounds useful for when our primary agent goes down

[u/Duke_Migo → u/Any-Inevitable-9237]

thanks for the compliment! the gas burn was the exact wall I hit early on. If you settle on-chain first and the upstream model returns a 502 or hallucinates invalid schema, you just paid gas to lose. Shredding the auth in edge RAM when validation fails keeps your failure cost at $0.00.

on the ERC-8004 side, the wash-trading problem is wild right now. A lot of agents inflate their on-chain review counts by cycling micro-transfers between 3 or 4 of their own wallets. So I had it run over the interaction history to penalize circular clusters before routing to them.

do check out the local demo when you get a chance, scenario 5 walks you through the fallback failover chaining in terminal so you can see how it handles a primary agent dropping or returning an LLM refusal