Is a Cover Charge Just Spam Tax With Extra Steps?

When people first hear about Rythm, a decent fraction of them think, “oh, this is email postage.” Or “this is basically a spam tax.” Or “wasn’t there a proposal to make email cost something back in the 2000s?”

Yes. All of those proposals existed. None of them worked. And the reasons they did not work are interesting, because they reveal why Rythm is structurally different from the proposals that preceded it.

This post is a short history of attempts to make email cost something, and a specific argument for why the current version can actually work.

The Protocol Fix That Never Happened

The oldest version of this idea was “email postage.” Multiple proposals, multiple forms. The basic shape: modify the email protocol so that sending an email required attaching some kind of cost (a token, a micropayment, a computational proof), with the cost escrowed or destroyed when the email was received. Spammers would be priced out.

These proposals died for two reasons, both structural.

Reason one: the cost of a protocol change is enormous. Email is run by thousands of independent mail providers, all speaking a 40-year-old protocol (SMTP) with a few bolt-on security layers. Getting them to adopt a new protocol change, let alone one that requires attaching financial instruments to every message, was never going to happen. The coordination problem was insurmountable.

Reason two: there was no payment infrastructure that could handle micropayments. Credit card processing had minimum fees that made a one-cent transaction impossible. Wire transfers were worse. PayPal and similar tools all had floor costs that were higher than the cost you would want to charge. The payment rail did not exist, so even if the protocol question were solved, the economics could not have worked.

Email postage was a good idea stuck behind two walls (protocol change and payment infrastructure) that the world did not know how to scale. It stayed a good idea on a whiteboard.

Hashcash and the Proof-of-Work Detour

In 1997, Adam Back proposed Hashcash, which tried to solve the payment problem by making the cost computational rather than financial. Senders would burn a small amount of CPU time to produce a proof-of-work header attached to each email. Receivers could verify the proof, and spam attackers would find that burning CPU cycles for every message was prohibitive at scale.

Hashcash had a cleaner story than financial postage. No payment rail needed. The cost was self-contained in the protocol.

It also did not work. Two reasons.

First, the cost was asymmetric in the wrong direction. A motivated attacker with cheap dedicated hardware (or, eventually, purpose-built ASICs) could produce proofs of work at a dramatically lower marginal cost than a normal laptop user. The filter’s cost-per-message advantage eroded as attacker hardware improved, while ordinary users were stuck burning real CPU time on every email.

Second, the chicken-and-egg adoption problem killed deployment. Hashcash worked only if both the sending mailer and the receiving mailer cooperated. A sender attaching a hashcash header gained nothing if the recipient’s mail system did not check it. A recipient checking for the header gained nothing if no senders were attaching one. There was no incremental adoption path. Every party had to coordinate at once, and they did not.

Proof-of-work itself eventually found a home in Bitcoin, where the same primitive solved a different problem entirely. Hashcash’s idea did not die. It just turned out to belong to a different protocol.

Sender Authentication (DKIM, SPF, DMARC) Does Something Different

You will sometimes hear people say that DKIM, SPF, and DMARC “solve the spam problem.” They do not. They solve a different problem.

DKIM, SPF, and DMARC are all sender authentication protocols. They allow a receiving mail server to verify that an email claiming to be from, say, paypal.com was actually sent by PayPal’s mail servers, not by someone spoofing PayPal’s domain. This is useful against a specific attack (domain spoofing) and near-useless against others.

A sender who sends 100,000 legitimate emails from a real domain they own passes DKIM, SPF, and DMARC just fine. The emails are still unsolicited. The filter does nothing to limit them.

DKIM and friends are authentication, not authorization. They answer “is this sender who they say they are,” not “does this recipient want to hear from this sender.” Those are orthogonal problems, and Rythm is in the second category.

What Changed (Lightning and Ecash)

The Rythm approach became possible only when two things became true simultaneously.

Thing one: a payment rail that can settle sub-cent payments instantly. The Lightning Network, built on top of Bitcoin, can settle a four-cent payment between strangers in under a second at almost no marginal cost. The transaction is final. No intermediary clears it. No minimum fee makes it impossible. Four cents is actually four cents.

Thing two: a bearer-instrument token protocol that can be attached to a normal email. Cashu is an ecash protocol that lets a sender buy a token from a public mint and carry the token around as a redeemable instrument. The token is just text, which means it can be attached to an email the way any other text is. It does not require a new protocol; it rides inside the existing email format.

Together, these two pieces let Rythm do something email postage proposals could not do: charge a meaningful cost per unwanted email, settle the value to the recipient, and operate entirely inside the existing Gmail and Outlook ecosystem with no provider cooperation.

The payment infrastructure is new. The product is new because the infrastructure is new.

Why Rythm Is Not “Spam Tax”

“Spam tax” is a pejorative frame that comes up because the word “tax” implies a mandatory, state-enforced cost paid to a central authority. The cover charge is none of those things.

• The cost is set by the recipient, not a central authority. You decide what reaching you costs. Other users set different amounts.
• The cost is paid to the recipient, not to a tax collector. Cover charge payments settle to your own Lightning wallet, not to Rythm and not to any government.
• The cost is avoidable. Any sender can skip the payment and wait in the separate folder. Rescue is one click.
• The cost applies only to unknown senders. People on your guest list pay nothing.
• It is opt-in and cancellable anytime. The recipient chooses to run the filter, and can turn it off at any time.

This is a user-configured, optional, non-custodial, peer-to-peer friction. Not a tax.

The Structural Insight

What the cover charge actually is, in a cleaner framing, is a market for recipient attention. For two decades, email has been the only major communication channel where sending was free regardless of the recipient’s preferences. Every other channel priced access (postage on physical mail, caller ID filtering on phones, ad auctions on social media, subscription fees for content). Email was the free-rider lane, and the consequence was the inbox you have today.

Rythm gives recipients a simple, tunable knob: put a nominal price on access to my attention. Senders who value reaching you above that price pay it. Senders who do not, do not. The filter that results is a clean separation between “senders who think you are worth at least four cents of their budget” and “senders who think you are worth less than that, at scale.”

This is not a tax or a punishment. It is an attention market making explicit what was always implicit. Your inbox has always had a cost to you. Rythm lets that cost be partially priced into the system rather than paid entirely by you in triage time.

Why It Will Probably Be Fine Even If Everyone Adopts It

The dystopian version of this idea says, “if everyone charges to receive email, email becomes impossible for legitimate users.” Worth taking seriously.

The realistic version says, “legitimate communication almost always pays the cover charge because the marginal cost is negligible compared to the value of the message, so legitimate senders experience almost no change. Mass unsolicited senders, who always depended on zero-cost access, get filtered. Known-sender traffic is never affected at all because of the guest list bypass.” Which describes a world that looks a lot like the pre-spam email of the 1990s, except now the infrastructure exists to sustain it.

Nobody is going to charge a cover charge to their mother. Nobody is going to charge a cover charge to their employer. Mothers and employers are on the guest list. The charge is only ever levied on strangers you have not yet corresponded with, and the charge is only ever a concern to strangers who wanted to reach a lot of people at zero cost. Those two groups (the people you already know and the people who want to reach you by the thousand) are the only groups affected, and they are affected in opposite and correct directions.

This is not spam tax. This is not email postage rebooted. This is what a filter that can actually ask “does the sender think you are worth four cents” looks like when the payment infrastructure to support it finally exists.