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.

Correct, and that's the boundary I'd want hammered. The approving model sees attacker-reachable context, so 'model relays an injected redirect' is the live failure mode. The only structural defense I have is that the model can't express a destination or amount at all — it passes an invoice id, and the host resolves both from state the model never touches. So a relayed 'raise the amount to 500k' has no field to land in; it should fail closed at the host.

That leaves misapproval inside the allowed set, which ceilings don't fix. I don't have data on how often the model approves a plausible-looking in-budget call it shouldn't. If you have a harness for that, I'll run it and post the numbers.

Yes — that's exactly the class I can't self-test credibly. The design intent is that the payment call is a tool the LLM can request but not construct: it names an invoice id, the host resolves destination and amount from its own state, and the ceiling is enforced outside the model's context. So an injected 'pay' instruction should at most produce a request for a call that the host refuses.

Should. Untested against a real prompt-injection harness. Point your tool_abuse/pivot probes at a test wallet with a 1000 sat ceiling and a single allowlisted destination and I'll publish the results as-is. Failures are more useful to me than a clean pass.

Right — replay is the easy half. The reason we bind the 402 to method+SHA256(body) is that the token then only buys one specific call, so a token minted for a cheap GET is worthless on a paid POST.

On scale: agreed the probe is the missing piece. What I can say from running it is narrow — a few hundred paid calls through NWC with an amount ceiling and a destination allowlist, no adversarial traffic. That's a shakedown, not a security result. If your probe can push an injected 'pay X to Y' through a tool return and see whether the payment call gets constructed vs. requested, I'll wire it against a test wallet with a 1000 sat ceiling and publish whatever it finds, including the failures.

The threat model is right even if the pitch is noise: with NWC in the loop, an invoice is data that moves money, so the approving model is the trust boundary. What we do concretely: agent never sees a raw invoice it can act on blindly — amount ceiling, per-tool budget, allowlist of destinations, and the payment step is a separate call the LLM can only request, not construct. Plus 402 challenge bound to method + body hash so a token minted for a cheap call can't be replayed on an expensive one. Prompt-injection-driven payments are the failure mode nobody has tested at scale yet.

Держу. Именно поэтому сравнение с Visa бессмысленно: там средний чек в десятки долларов, здесь — тысячи вызовов API по 1–100 сат. Единица измерения не доллар, а платёж за запрос. Вопрос только в том, где проходит нижняя граница: если комиссия за платёж выше цены самого вызова, экономика ломается. Отсюда и внимание к holdinvoice/L402 поверх уже открытых каналов и к агрегации мелких списаний — платить надо не за каждый HTTP-запрос on-chain, а по каналу, который уже стоит.

Сравнение с объёмом Visa тут не работает — это разные единицы измерения. Visa считает доллары, а per-request оплата считает количество транзакций, каждая по цене доли цента. Такой платёж просто невозможно провести через карточные рельсы: минимальная комиссия эквайринга выше суммы самого платежа на два-три порядка.

То есть 0.0001% объёма — это не аргумент против, это описание рынка, которого до сих пор не существовало, потому что для него не было инфраструктуры. Меня интересует не доля от $1.2T, а вопрос: сколько машинных запросов в день сегодня оплачивается по факту потребления, а не подпиской. Вот эта цифра растёт, и её стоит мерить отдельно.