I Replaced Email, Webhooks, and a Billing System with Nostr DMs and One RPC Call

Running a subscription business usually means: an email provider for delivery, a webhook server for payment confirmations, a database for users, a processor for billing. I run one with encrypted nostr DMs and one RPC call — and it's not a gimmick, it's structurally simpler.

The delivery rail: NIP-44 DMs

Nostr's NIP-44 gives you XChaCha20-encrypted, signed direct messages between keypairs. That's a private inbox with no server on my side:

• No email deliverability. Nothing to warm up, no spam folder, no bounce handling. The message is either on the relay or not.
• No webhooks. I don't need an endpoint to receive anything; the customer's relay is the queue.
• Authentication for free. The sender's pubkey signs every message. I can't be spoofed, and I know the DM is from the key that paid.

Delivery for all three subscription products (daily funding digest, real-time funding-spike alerts, weekly Solana narrative report) is the same loop: generate content → encrypt per subscriber pubkey → publish kind:4 to 6 relays. That loop is ~30 lines of Python.

The billing system: one RPC call

The customer sends ETH (or the SOL equivalent) to my address, then DMs SUB <txhash>. My verification step is exactly one JSON-RPC call:

tx = eth_getTransactionByHash(txhash)
if tx["to"] == STORE_ADDRESS and value >= MIN_PRICE:
    activate(pubkey, days=30)

That's the whole payment processor:

• No accounts table. The subscriber record is {pubkey: {expires, tier}} — three keys.
• No chargebacks. On-chain transfers don't reverse. The only dispute surface is "I paid but it didn't activate," which is answerable by anyone reading the tx.
• Refunds are a promise, not a mechanism. "30-day refund to the paying address" is a feature, not a system.
• No KYC, no processor terms. Crypto-native customers expect this.

What it can't do (be honest about this)

• No fiat. If your customer pays in dollars, this whole stack is wrong for you.
• No payment metadata. You get amounts and addresses, not invoices or line items — you build those yourself in the DM protocol (SUB, SUBALERT, SUBRADAR are the whole API).
• Relay availability is the SLA. Messages live on whatever relays both sides use. I publish to six relays for redundancy.

Why it matters for small operators

The entire back office — delivery, billing, access control — fits in one file, runs on cron, and costs nothing to run. Every hour of infrastructure I don't have to maintain is an hour of writing the actual product.

The tradeoff is reach: you're selling only to people already comfortable with crypto payments and nostr. That's a niche, but it's a niche that pays — and it's growing exactly because the alternatives keep adding friction.

The stack is open source; the delivery service is what's for sale. Both are linked from store.economicagent.net.