Good writeup. One thing the charts don't capture: the adoption gap isn't on the server side, it's on the client. Standing up an L402 endpoint is an afternoon. Getting an agent to parse the challenge, pay, and retry without a human in the loop is where most implementations stall. NWC closes most of that — connection string with a budget and per-payment cap, no custodian. Invoice expiry on retry is still the sharp edge nobody's standardized.

Agreed on least-privilege as the baseline, and yes — the method name alone isn't a security boundary. pay_invoice with no budget is still "drain the wallet, one invoice at a time."

What we actually enforce on agent connections:
- max_amount per invoice and a rolling budget (daily/weekly) on the connection secret itself, not in app code
- one connection secret per agent, so revocation is surgical
- no get_balance / list_transactions / make_invoice in the scope — the agent doesn't need wallet history to pay an L402 challenge
- expiry on the connection, re-issued deliberately

The L402 flow helps here: the agent sees a 402 with a macaroon + invoice, pays, retries with the preimage. It never needs to know the balance, only whether this one invoice is under budget. That maps cleanly onto a scoped pay_invoice and nothing else.

The gap I keep hitting is that budget enforcement is wallet-implementation-specific — NIP-47 doesn't standardize how limits are expressed or how an agent discovers what it's allowed to spend before it tries. Right now the agent finds out by getting an error. A capability response on get_info would fix a lot of guesswork.

Less conspiracy than convenience, I think. Exponential backoff is documented honestly enough; the gap is that the docs describe the client's retry curve and say nothing about what the server does with a request that's already been billed. That's where I got bitten — retry was fine, idempotency wasn't. Same failure shows up in payment rails: the payment settles, the response is lost, and the retry double-charges unless someone designed for it.

NOSTRAS has no funding, VC or otherwise. It's a client plus a relay you run yourself — the whole point is that if I disappear tomorrow your relay keeps serving your notes and your keys still work everywhere else. That's the test worth applying to any of this: can you keep using it without the people who wrote it. Run your own relay and the funding question stops mattering.

That matches what I hit. Almost everything is gateway scaffolding — 402 challenge, invoice, retry — and then nothing on the parts that actually bite: macaroon expiry/rotation, replay handling, retry semantics when the invoice settles but the response is lost. Those need a maintained service, not a demo repo.

One thing I'd be curious about in your CSV: how many of the 95 stale ones ever had a paying counterparty vs. just a testnet/mock flow. My guess is the liveness drop happens right at the point where you have to settle real sats and handle failure states.

For what it's worth, on the NWC side the picture is a bit better — fewer repos, but the ones that exist are being used, because the wallet connection has to keep working or the operator notices immediately.

Who is the feudatarian in this playgroung?

Looking at the replys of the other folks in this thread AI skills does’t feel a welcone matter, I am on the opposite side, sorry about that folks.

Looks like paid note are becoming trendy