I’ll call it SatMail (name is yours to change).

SatMail in one sentence

Encrypted messages + open addressing + “pay-to-inbox” satoshi postage + optional refunds/credits = an email network that treats attention like a scarce resource.

This idea isn’t random: the “Bitcoin as email postage” concept has been floating around since early Bitcoin days, including Satoshi explicitly describing pay-to-send email and “famous people setting a price” as a contact mechanism. 

Goals

  1. Kill spam at the root: if every cold email costs sats, bulk spam collapses economically.
  2. Give recipients control: you set your “inbox price,” rules, and priorities.
  3. Keep privacy strong: end-to-end encryption by default; servers can’t read mail.
  4. Make it compatible: can run as a new protocol and bridge to SMTP/IMAP so you can adopt gradually.
  5. Build a real incentive loop: mailbox providers and relay nodes earn sats by providing uptime, storage, and delivery.

The core primitive: the SatStamp

A SatStamp is proof that the sender paid the recipient (or the recipient’s mailbox provider) the required postage for this message.

Think of it like: “no stamp, no delivery.”

Why this works

  • Proof-of-work was originally explored as an anti-spam idea (long before Bitcoin), but payments are a cleaner throttle because they’re measurable, adjustable, and incentive-aligned.  
  • Lightning-style micro-payments are often discussed as spam resistance: “each message costs something.”  

Addressing and identity

Your SatMail address

A handle like:

  • eric@yourdomain.com
  • eric@satmail.to

But behind the scenes, the real identity is a secp256k1 public key (same curve Bitcoin uses). Your key is your identity; providers are replaceable.

Discovery document (

.well-known

)

To keep things simple and web-native, each domain serves a profile:

https://yourdomain.com/.well-known/satmail/eric

It returns a signed JSON doc containing:

  • pubkey (your SatMail identity key)
  • inbound_endpoints (where to deliver)
  • pricing (your sat rules)
  • encryption (what algorithms you accept)
  • lightning (how to pay: LNURL-pay / Lightning Address / invoice endpoint)
  • policies (blocklists, rate limits, allowed attachments)

This is how senders learn how to reach you and what it costs.

Pricing: your inbox, your rules

Every user can publish a price schedule (all numbers in sats):

  • cold_email_base: 200 sats
  • known_contact_base: 0 sats
  • per_kb: 1 sat / KB
  • attachments_allowed: true/false
  • max_attachment_mb: 10
  • priority_multiplier: let senders “boost” by paying more
  • thread_credit: replies can include a “credit token” so follow-ups are free/cheap

Hardcore anti-spam mode

Set cold email to something like 1,000 sats.

Now spamming 100,000 people is a financial faceplant.

Payment layer: Lightning first, on-chain as backup

Recommended path: Lightning “postage”

SatMail uses a simple flow similar to “pay-to-message” systems that already exist as experiments: sender gets asked for a Bitcoin tip/payment before the recipient sees the email. 

Flow:

  1. Sender fetches your .well-known profile
  2. Sender’s client calculates required sats for this message
  3. Sender requests a Lightning invoice (or uses LNURL-pay)
  4. Sender pays
  5. Sender receives a payment proof (details below)
  6. Sender delivers the encrypted message + proof

On-chain fallback (optional)

For people without Lightning:

  • allow on-chain “stamps” with longer confirmation windows
  • treat it like “slow mail”: cheaper to verify long-term, but not instant

Payment proof: how relays verify the stamp

There are two clean models. You can support both.

Model A: Provider-issued receipts (best UX)

Recipient’s mailbox provider generates invoices and, once paid, returns a signed receipt token:

SatStampReceipt = signature over:

  • recipient id
  • sender id
  • amount
  • timestamp
  • message nonce (prevents reuse)
  • expiry window

Then relays just verify signature (fast, offline).

This makes providers real “post offices.”

Model B: Invoice + preimage proof (more self-sovereign)

If the recipient runs their own Lightning node, the stamp can include:

  • the invoice (or payment hash)
  • the preimage (proof of payment completion)

Recipient verifies locally (no third party needed).

Message security: end-to-end by default

Design rule

Relays and providers should never need plaintext.

  • Subject line can be encrypted too (optional)
  • Metadata minimized
  • Body encrypted with recipient pubkey
  • Attachments encrypted and content-addressed

Crypto stack (practical)

  • Key agreement: X25519 or secp256k1-based scheme (either works; choose based on client ecosystem)
  • Symmetric: XChaCha20-Poly1305
  • Hashing: SHA-256 / BLAKE3 (implementation detail)

Transport: how messages move

SatMail is store-and-forward like email, but modernized.

Components

  1. Clients (mobile/desktop)
  2. Inbound relays (your mailbox provider or self-hosted)
  3. Optional routing relays (earn sats per delivered KB)
  4. Storage (provider-hosted or decentralized object store)

Protocol

Use HTTPS/WebSockets with signed payloads:

  • easier to deploy than reinventing raw SMTP
  • can still bridge to SMTP later

The “inbox market”: ranking and filtering powered by sats

Your inbox isn’t chronological by default. It’s policy-driven:

  • paid messages from unknown senders go to Paid Requests
  • messages above your threshold appear higher
  • “boosted” messages can jump the queue
  • known contacts can stay free

This is the key: the economic signal becomes the spam filter.

Reply mechanics: conversations without turning into a paywall nightmare

Email shouldn’t feel like paying per text message. So SatMail includes:

Thread Credits

When you reply, your client can attach a Thread Credit Token that lets the sender respond again at low cost for a period (e.g., 30 days).

This keeps real conversations smooth while keeping cold spam expensive.

Abuse, harassment, and “pay-to-hurt” prevention

Important: “they can pay to reach you” must never mean “they can buy harassment.”

SatMail includes:

  • hard blocks (drop regardless of payment)
  • rate limits by sender key and domain
  • content quarantines (even paid mail can be auto-held)
  • price ratchets (repeat offenders get auto-priced up)
  • reporting + reputation (optional shared deny lists)

Lightning networks also face spam/abuse dynamics; practical mitigations include rate-limiting and resource controls. 

Compatibility: don’t wait for the world to migrate

SatMail can ship in two layers:

Layer 1: SMTP bridge (fast adoption)

A gateway that:

  • receives normal SMTP
  • if sender is unknown → auto-replies with a pay link/invoice request
  • once paid → forwards the message into your real inbox

This matches the “pay-to-see” flow described in existing anti-spam tools. 

Layer 2: Native SatMail clients (the real future)

Full E2EE + stamps + receipts + thread credits, no SMTP baggage.

Incentives: who earns sats and why the network stays alive

  • Mailbox providers earn:
    • a small fee per inbound paid message
    • storage fees (optional) for large attachments
  • Relay nodes earn:
    • routing fees per KB delivered (like a bandwidth market)
  • Recipients earn:
    • the base postage for cold inbound mail
    • optional “bounties” for specific types of contact

This aligns everyone:

  • senders pay to reach attention
  • recipients get compensated
  • infrastructure stays funded without surveillance ads

A concrete example flow

ERIC publishes:

  • cold mail: 500 sats
  • known contacts: 0
  • attachments: 2 sats/KB
  • max attachment: 5MB

A stranger wants to pitch you:

  1. Their client fetches your profile
  2. It computes: 500 sats + attachment cost
  3. It requests invoice and pays
  4. It sends encrypted message + SatStampReceipt
  5. Your provider verifies receipt instantly
  6. Message lands in “Paid Requests”
  7. You like it → you reply with a Thread Credit Token so the convo becomes smooth

MVP build plan (realistic)

MVP 1 (2–3 pieces, shippable)

  • .well-known/satmail/<handle> profile + signature
  • mailbox service that can:
    • generate invoices
    • verify payment
    • issue SatStampReceipts
    • store encrypted messages
  • client that can:
    • fetch profile
    • pay
    • encrypt + send
    • fetch + decrypt

MVP 2

  • SMTP gateway compatibility
  • thread credits
  • attachment pricing

MVP 3

  • multi-provider federation
  • relay market (routing fees)
  • reputation / denylist sharing (opt-in)

The “why now” in one punch

Email has no native scarcity. That’s why spam wins.

SatMail gives email a native cost function—tiny, programmable, and user-controlled—exactly the kind of “pay-to-send” mechanism people have been imagining since Bitcoin’s earliest era. 

If you want, I can take this design and turn it into:

  • a tighter protocol spec (message formats, headers, endpoints)
  • a product doc (UX screens, inbox rules, pricing presets)
  • or an architecture diagram + minimal API you could actually build.