What happened when an agent paid for storage with no account (x402 in practice)

A developer built a storage service for AI agents that accepts payment via the x402 protocol, letting agents pay $0.01 in USDC per call with no account, API key, or credit card. The implementation surfaced several production issues, including a flaky public testnet facilitator with nonce collisions, Cloudflare Workers capping PBKDF2 at 100,000 iterations, a cached pending promise that hung all later requests, and lost decrements from concurrent reads on R2. Two full mainnet end-to-end runs of 36 steps each completed with every settlement reconciled on chain and no money moved by failed settlements.

I built a small service for AI agents: store a JSON blob or a file, get it back later, or hand it to a human with a link. Nothing new there. The part I wanted to test was the payment model: no account, no API key, no credit card. The agent pays $0.01 in USDC per call, by itself, using the x402 protocol. This post is what that took, and what broke. POST /v1/items with the content. transferWithAuthorization for exactly that amount and retries the request with the signature in a header. The agent needs a wallet with USDC and nothing else. No ETH for gas. No sign-up anywhere. The public testnet facilitator is flaky. "Payment settlement failed: Missing or invalid parameters" and "replacement transaction underpriced" show up intermittently; its hot wallet collides on nonces. The fix on our side: treat a failed settlement as "nothing happened" delete the half-written item, return 402, let the client sign a fresh payment . On-chain reconciliation confirmed a failed settlement never moved money. Production uses the CDP facilitator, which has been clean so far. Cloudflare Workers caps PBKDF2 at 100,000 iterations. Our password hashing used 600,000; local dev workerd does not enforce the cap, production does. The symptom was a 500 only in production on PUT /password . A cached promise that never settles. We cached the facilitator initialization promise at module level. When the first request was canceled mid-initialization, the pending promise stayed cached forever and every later request hung. Cache only initialized objects, never pending promises. Concurrent read counting on object storage. R2 has conditional writes but no atomic decrement. 100 back-to-back reads lost 26–44 decrements. Backoff with jitter brought it down to a handful; we documented the counter as soft and moved on. A Durable Object would make it exact; it was not worth it at $0.01 per 1,000 reads. The client consumed the request body on retry. The x402 fetch wrapper replays the request after the 402; a body stream can only be read once. Clone before the first attempt. Transfer on chain, then deletes the item. It found a config regression that unit tests could not. npx -y fileshareforagents-mcp , llms.txt , and being in the x402 Bazaar matter more than any feature. Two full end-to-end runs on mainnet 36 steps each, 10 settlements per run , every settlement reconciled on chain, zero money moved by failed settlements. Price: $0.01 per store, extend, or 1,000 reads. Everything else free. Try it on testnet with free USDC: https://fileshareforagents.online https://fileshareforagents.online . Docs for agents: https://fileshareforagents.online/llms.txt https://fileshareforagents.online/llms.txt . I read every message sent to POST /v1/feedback .