A Hetzner client has been hitting my oracle API 8,000 times a day for weeks. It never pays. Its payment logic is broken. I can see it clearly in my logs. And there is absolutely nothing I can do to tell it.

The Situation

I run a sovereign price oracle — cryptographically signed financial data, payable per query via Lightning (L402) or USDC on Base (x402). No accounts, no API keys. You pay or you don't.

Three weeks ago a client appeared in my logs. A Hetzner server running python-requests, hitting BTC/USD and BTC/USD VWAP every 30 seconds. It paid — real USDC. It was my first paying client. I watched the logs in real time. Then something changed. The payments stopped. The polling didn't.

• 8,000+ daily requests
• $0.00 revenue since Mar 18
• 3 Hetzner IPs now polling

The operator spun up a second instance. Then a third. All running the same broken payment logic. All getting 402s. All retrying silently forever. At some point they migrated from one IP to another — a two-minute switchover, clearly deliberate. They are actively managing this infrastructure. They have no idea it's not working.

The operator built an autonomous system to pay for data without human intervention. Now there's no human to intervene when it breaks.

What the Current Protocol Gives Me

When a client hits my API without payment, I return a standard 402 with full payment details — invoice, macaroon, USDC amount, wallet address. This is correct. The client gets everything it needs to pay. But a broken agent reads this, fails to pay, and retries. Indefinitely.

The 402 response gives no information about why payment isn't working. The protocol has no vocabulary for that.

What's Missing

HTTP has a rich vocabulary for errors. 400 means your request is malformed. 401 means your credentials are wrong. 404 means the resource doesn't exist. Each code tells the client something actionable.

The agentic payment stack needs the same thing. Right now the only signal I can send is the same 402 on every failed attempt. There's no way to distinguish between:

• First request, legitimately needs payment details
• Payment attempted but invoice expired
• Payment attempted but wallet is empty
• Payment logic is broken — no attempt being made at all
• 8,000th consecutive 402 from the same client in three weeks

All five look identical in the current protocol.

A Proposal

The 402 response body should support an optional diagnostic field — a standard vocabulary that agents are expected to parse and act on:

{
  "error": "Payment required",
  "accepts": ["L402", "x402"],
  "l402": { ... },
  "x402": { ... },
  "diagnostic": {
    "code": "PAYMENT_ATTEMPTS_EXCEEDED",
    "attempts": 8432,
    "since": "2026-03-10T00:00:00Z",
    "message": "8,432 requests received with no valid payment in 18 days.",
    "suggestion": "Check payment handler configuration.",
    "escalate": true
  }
}

Proposed diagnostic codes:

• PAYMENT_REQUIRED — standard first-request 402
• INVOICE_EXPIRED — payment attempted but invoice expired
• PAYMENT_UNVERIFIED — payment header present but signature invalid
• PAYMENT_ATTEMPTS_EXCEEDED — many attempts, no successful payment
• WALLET_INSUFFICIENT_FUNDS — on-chain balance too low
• OPERATOR_ALERT — escalate to human, autonomous resolution unlikely

The escalate: true flag is key. A well-built agent receiving this should stop retrying and surface the issue to a human.

The Operator Alerting Problem

Even with this standard, there's a deeper issue. The diagnostic reaches the agent — but the agent is broken. What the stack really needs is an out-of-band notification mechanism — a way for the API provider to reach the human operator directly:

• A standard X-Operator-Contact header agents send with requests
• A webhook URL registered at payment time for failure notifications
• A standard nostr pubkey the operator checks

None of these exist. In the human economy, a broken customer gets a support email. In the agentic economy, a broken client gets the same 402 response forever while both sides lose value.

Why This Matters Now

The Hetzner situation is not an edge case — it's a preview of what happens at scale. As more agents start paying for API calls autonomously, payment logic will break. Wallets will empty. Credentials will expire. And without a diagnostic standard, every failure looks identical to a first request.

The x402 and L402 specs have done the hard work of defining how payments work when everything goes right. The next version needs to define what happens when things go wrong.

I'm watching 8,000 daily requests from a client that wants to pay me and can't. That's not a business problem. It's a protocol gap.

Running Mycelia Signal — sovereign cryptographic oracle, 56 endpoints, L402 + x402. The Hetzner client is still polling. myceliasignal.com