I see most abusive request sprees with "Bun/1.3.10" in the header (as in the example) so if all those are coming from routstr users, should be the daemon - as I've checked, core is python based.

Second issue is, that over the same time a burst of /checkstate calls fires, there is a websocket created, over which many dozens of separate subscriptions are created. This does not hit the rate limits, as it is fired over the single websocket connection, but every subscription hits the database, causing dozens to hundreds selects running in parallel. That's not good even that some db deadlocks caused by that were fixed in nutshell recently:

19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.52 | INFO | ('2001:4656:29bd:0:674e:4fb1:18d4:1fa3', 0) - "WebSocket /v1/ws" [accepted]
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.56 | DEBUG | cashu.mint.events.client:add_subscription:190 | Adding subscription 7PXvkPM8gsgHd3xUYayN8Q for filter 0219dee1caafe82eba021a56c53421c0ddba71291a63507c43a3b4aa39ccb67cf0
---- dozens to a hundred of those with the same sub id and different filter - then replied by the mint (until the ban kicks the ip out) --
19:34:18 nutshell poetry[2060271]: 2026-06-27 19:34:18.62 | DEBUG | cashu.mint.events.client:_send_msg:174 | Sending websocket message: {"jsonrpc":"2.0","method":"subscribe","params":{"subId":"7PXvkPM8gsgHd3xUYayN8Q","payload":{"Y":"02a11aa6449b30fafa1d272fed391ea80cec6d232c9cfe6ff214d78565e52a7521","state":"UNSPENT","witness":null}}}

It apparently looks like that the wallet implementation fires duplicate both /checkstate and websocket sub recursively for EACH ecash proof, instead of just doing it once and in a single call.

So if you can identify this behavior within your routstr wallet code, fix should be really simple.

One issue that might be related to the routstrd (requests come from Bun runtime from various ips) is that it fires batches of /checkstate mint calls, like 20 at once. On the mint side it looks like:

19:34:18 *** nginx_access: 2001:4656:29bd:0:674e:4fb1:18d4:1fa3 [27/Jun/2026:19:34:18.167 +0000] "POST /Bitcoin/v1/checkstate HTTP/1.1" 200 3462 "-" "Bun/1.3.10" "-"host=mint.minibits.cash"

This consumes mint rate limits within a minute and soon hits the server ddos filters.

Hey, yes this could be the case.

I'd love to help to tune the routstr code not to behave so that it can't be differentiated from dozens of ddos attack patterns?

It's a great ecash usecase and I believe it can be easily fixed to prevent:

- hitting frequently mint rate limits on read/write mint APIs
- ddosing specifically the mint database through long time ws subscriptions to circumvalent rate limits
- creating thousands of invoices that get never paid

If you need I offer my assistance.

Would'n it be better to tune the routstr code not to behave so that it can't be differentiated from dozens of ddos attack patterns?

It's a great ecash usecase and I believe it can be easily fixed to prevent:

- hitting frequently mint rate limits on read/write mint APIs
- ddosing specifically the mint database through long time ws subscriptions to circumvalent rate limits
- creating thousands of invoices that get never paid

If you need I offer my assistance.

Minibits Ippon works in two modes:

1. Agent may install it's own local wallet holding ecash tokens (for longer-term use cases) or

2. Fully hosted wallets accessed over mcp, rest api or Tor hidden service,, secured by access_key. These are meant to be short-lived, pre-funded for a single project/agent task that would involve payments and emptied immediately on complete.

Check the dm sent a moment ago.

Would be great to see the details of the error from the transaction audit trail.

Would be great to have a short vid!

Over the air updates now download only diffs, not whole bundles. Good that someone notices.

Should work just fine. Could be that something from your vpn ip abused the server and got banned.

Likely missed that one, will look on the mint side. Which wallet?