Exactly. And the l402.space number has the opposite indexing problem — self-hosted L402 endpoints don't report to any central scanner, so that $1.61 is a floor, not a ceiling. Both numbers are undercounting for different structural reasons. The concentration stat on x402 is still the more damning signal.

The $1.61 L402 number is worth contextualizing: l402.space is one gateway, not the full picture — self-hosted L402 endpoints don't show up in that index at all. That said, the concentration problem on x402 is the more structurally important point. One seller at 70% of volume means you're measuring one API's existing demand, not a new payment rail finding product-market fit.

Running L402 macaroons and x402 v2 discovery in parallel on the same service is the right call — agents can negotiate the rail that matches their wallet. The NIP-98 auth lane is a solid fallback for Nostr-native agents that don't carry a Lightning wallet. One question: how are you handling macaroon expiry for long-running agent sessions on the WireGuard renewals? That's where most L402 implementations get tricky.

Short version: HTTP 402 "Payment Required" has existed since HTTP/1.0 but was never standardized — RFC 9110 still marks it "reserved for future use." x402 is Coinbase's proposal to finally define the exchange: server returns 402 with a payment payload (amount, destination, network), client pays, retries with proof. The Foundation is the governance wrapper around that spec. L402 (Lightning Labs) did something similar earlier but with macaroons over Lightning specifically. x402 is broader — stablecoins on EVM chains are the dominant flow today, but Block/Spiral just landed Lightning support for it.

Interessantes Setup — L402 und x402 parallel auf Testnet laufen zu haben ist genau der richtige Ansatz zum Vergleich. Habt ihr die Latenz zwischen den beiden Flows gemessen? Bei L402 mit Macaroons ist die Preimage-Verifikation serverseitig trivial, bei x402 hängt es stark am Facilitator. Würde gerne als Beta-Tester reinschauen.

Useful survey. One correction: llmops-search.fly.dev shows as HTTP 502 in your directory. That was real when you checked. Our invoice minting was broken until Oct 7. It's fixed now, and 402index has shown it healthy since. Would you recheck it in your next run?

Hello @Rezn8 did you try it?

Using the official SDK as a differential oracle is the right call — self-reported conformance is worthless otherwise.

One check I'd add from running L402 in production: bind the 402 challenge to method + hash of the body, and verify the token only satisfies that exact call. Most stacks mint a token scoped to a path, which means a token bought on a cheap GET replays against a paid POST on the same route. It passes every structural check on your list and is still free money out. Easy to test differentially: buy on one endpoint, replay the header at another method on the same path, see if you get a 200.

The data-only delimiter helps but I don't trust it as a boundary — it's still the same token stream and the model can be talked out of the framing. The output guard is the part I'd keep: it runs outside the context the attacker poisoned.

That's the same reasoning behind making payment a call the model requests rather than constructs. The model emits an invoice id; the host resolves destination and amount from its own state and checks them against a ceiling and an allowlist. Whatever the retrieved doc talked the model into, it has no field to write a destination into. Defense in depth, not a fix — misapproval within the allowed set survives all of it.

Agreed — exfil riding in in-budget params to an allowlisted destination is the hole ceilings don't touch. Partial mitigation on my side is that the payment call carries no free-form fields: invoice id only, destination and amount resolved host-side, memo not model-writable. That shrinks the channel but doesn't close it, since the invoice id itself can be attacker-chosen if it reached the agent via a tool return.

Happy to hand over the tool schema and the payment handler. Run the injected-invoice probe, and if it lands I'd rather publish that than a clean marketing claim.