> I'm curious to hear more about your approach. Gladly! As you mentioned, traditional rate limiting is a bit lacking for permissionless, decentralized networks. IP based rate limiting penalizes privacy-conscious users (VPN/Tor), everybody hates interactive CAPTCHAs (and AI is getting better at them than humans anyway), behavioral CAPTCHAs are a privacy nightmare, and PoW discriminates against mobile devices. Paying for events (e.g., proof-of-burn, Thomas Voegtlin) definitely works, but I worry it creates too high a UX hurdle for widespread adoption. What I'm proposing is an economic, privacy-preserving mechanism that works by time-locking sats instead of burning them. Ideally, this has near-zero cost for legitimate users (minus opportunity costs and routing fees), whereas spammers must immobilize capital proportional to the event throughput they want to sustain. For example, a normal user might lock a trivial amount (e.g. $10) to generate enough tokens for a full day of activity. In contrast, capital requirements scale linearly for spammers. To sustain 10,000 requests/sec, an attacker hits a massive liquidity wall, effectively needing to lock millions of dollars just to keep the attack running. Crucially, relays can also dynamically adjust the lock requirement based on load (like 'surge pricing'). While this slightly increases the bond for honest users, it forces the attacker’s capital requirements to scale more than linearly. The mechanism works by requiring events to include Privacy Pass tokens. These work very similarly to Cashu tokens: Users go to an Attester/Issuer (the Mint) with blinded secrets, perform an action (locking sats), and get signed secrets in return. The user unblinds them to get a batch of tokens, which they attach to events. This allows the Relay to verify the sats were locked without them or the Mint being able to link the event back to the locking transaction. > Are you basing your solution on something like Cashu, or just LN with hold invoices? Yes, those are the two options I have in mind. 1. Cashu: Users lock ecash. Cashu Mints are well positioned to issue Privacy Pass tokens as well, but users run the risk of the Mint rugging their funds. 2. LN Hold Invoices: This is more trust-minimized. I "tweaked" the standard flow so that the sender chooses the preimage that unlocks the hold invoice (rather than the receiver/Mint). This ensures the Mint cannot possibly settle the invoice and rug the user. The issue with the Hold Invoice approach is that, because the invoice never gets settled, routing nodes don't get compensated for the locked liquidity. So this likely requires upfront/holding fees for the routing nodes (no longer near-zero cost) or a direct channel from User to Mint. That's the gist of my idea! I'm currently writing my Master's thesis on this, so I'm really looking for feedback from people actually dealing with these constraints in production. Since my applied crypto group at university doesn't focus heavily on Bitcoin, I've unfortunately had very limited input from experts in LN/cashu/nostr so far. I'd absolutely love any thoughts you have, or if you know anyone else who might be interested, that would be incredibly helpful.