Hashcash was a 1997 proposal by Adam Back to use cryptographic proof-of-work as a cost mechanism for email. Senders would burn a small amount of CPU time to produce a proof, and receivers would verify the proof. Spammers, who depended on free reach, would find that burning CPU cycles for every recipient was prohibitive at scale. The cost was self-contained in the protocol, requiring no payment infrastructure.

Why did Hashcash fail?

Three structural reasons. First, the cost was asymmetric in the wrong direction; dedicated hardware (eventually ASICs) could produce proofs much faster than ordinary user laptops. Second, the chicken-and-egg adoption problem killed deployment; it only worked if both senders and receivers cooperated, and there was no incremental path. Third, the payment-rail-free design was both its strength and its weakness; without actual payment, the cost could not flow to recipients.

What is structurally different about Cashu?

Three differences. First, Cashu uses actual payment (Lightning settlement) instead of computational proof, which avoids the asymmetric-hardware problem. Second, Cashu does not require protocol-level adoption; the bearer token rides inside the existing email format with no provider cooperation needed. Third, the cost flows to the recipient instead of being burned, which aligns the incentive structure.

Did Hashcash contribute to Bitcoin?

Yes. The Hashcash proof-of-work primitive was adopted by Bitcoin as the underlying mining mechanism. Hashcash succeeded as a primitive in a different protocol but failed as the email-cost mechanism it was designed for. The structural reason is that proof-of-work works for adversarial consensus (Bitcoin) and does not work for one-to-one cost (email).

Could Hashcash work today?

Probably not. The asymmetric-hardware problem has gotten worse, not better. ASICs and GPUs produce proofs orders of magnitude faster than ordinary CPUs. The protocol-level adoption problem also remains. Cashu's design choices specifically address what Hashcash got wrong.

Why Hashcash Failed and Cashu Won't

Hashcash was the original 'cost on email' proposal in 1997. It did not work. Here is why and what makes Cashu structurally different.

Hashcash was the original “cost on email” proposal. Adam Back proposed it in 1997. It was elegant, well-conceived, and ultimately unsuccessful in its intended use case. Understanding why Hashcash failed is useful because it explains why the current generation of email-cost mechanisms is structurally different and why they have a better chance of succeeding.

This post is the realistic comparison.

What Hashcash Was

Adam Back’s original proposal:

The mechanism. A sender attaches a “Hashcash stamp” to each email. The stamp is a hash that requires a specific amount of computational work to produce. The receiver verifies the hash, which is computationally cheap, and confirms the sender did the work.

The economics. Spammers, who send millions of messages, would have to burn millions of multiples of CPU time. The aggregate cost of running the campaign would exceed the value of the campaign. Legitimate senders, who send a few messages, would barely notice the cost.

The implementation. Open-source code that anyone could run. No central infrastructure. No payment system required. The cost was entirely within the cryptographic primitive.

The design was clean. The math worked. The proof-of-concept was deployed. It did not catch on.

Why It Did Not Catch On

Three structural reasons.

Reason one: asymmetric hardware advantage. The cost of producing Hashcash proofs is not constant across hardware. A modern CPU produces proofs at one rate; a GPU produces them at a much higher rate; dedicated ASICs (which were eventually built for Bitcoin mining, which uses the same primitive) produce them at orders of magnitude higher rates. The asymmetry favored attackers.

A legitimate user’s laptop spent meaningful CPU time per email, which became a real cost to legitimate use. A spammer with a farm of GPUs or ASICs could produce proofs at near-zero marginal cost. The filter’s intended cost-per-message advantage eroded as attacker hardware improved while legitimate user hardware stayed the same.

Reason two: chicken-and-egg adoption. Hashcash worked only if both senders and receivers cooperated. A sender attaching a Hashcash stamp gained nothing if the recipient’s mail system did not check it. A recipient checking for Hashcash stamps gained nothing if no senders were attaching them. There was no incremental adoption path; everyone had to coordinate at once.

This is the same problem that killed many other protocol-level proposals. Email is run by thousands of independent providers, and getting them to coordinate on a new protocol simultaneously was structurally impossible.

Reason three: cost was burned, not transferred. Hashcash burned CPU cycles. The cost was real but did not flow anywhere productive. The recipient did not benefit from the sender’s work; the work was just consumed. This made the system feel like a tax (cost imposed without value to anyone) rather than like a market (cost imposed in exchange for the recipient’s attention).

Modern designs (Cashu, Lightning) move the cost to the recipient, which aligns incentives differently.

What Cashu Does Differently

The current generation of email-cost mechanisms addresses each of Hashcash’s structural problems.

Difference one: actual payment instead of proof-of-work. Cashu uses Lightning settlement. The cost is denominated in sats, not in CPU cycles. The asymmetric-hardware problem disappears because the cost is the same regardless of the sender’s hardware. A spammer with a GPU farm pays the same per-message cost as a legitimate sender with a laptop.

Difference two: no protocol-level adoption required. The Cashu token is just a string. It rides inside the existing email body. No provider cooperation is needed; sender and recipient can transact directly without the email infrastructure being aware of what is happening.

This is the structural innovation. Hashcash required everyone to adopt at once. Cashu requires only the two parties involved in any specific transaction.

Difference three: cost flows to the recipient. When the recipient melts a Cashu token, the resulting Lightning payment settles to their wallet. The cost imposed on the sender becomes value to the recipient. The system feels like a market for attention rather than a tax.

Each of these differences addresses a specific Hashcash failure mode.

What Hashcash Got Right

Despite failing in its intended use, Hashcash made meaningful contributions:

The proof-of-work primitive. Adopted by Bitcoin and used as the basis of consensus security. Hashcash’s primitive succeeded in a different protocol that needed adversarial consensus rather than one-to-one cost.

The structural insight. Free reach in email is the fundamental driver of spam. Imposing a cost on senders is the structural answer. The insight is correct; the implementation chose the wrong cost mechanism.

The historical demonstration. Hashcash showed that the technical concept (sender pays, recipient verifies) could be implemented and deployed. The infrastructure failure was not technical; it was operational and economic.

The current generation of email-cost mechanisms builds on Hashcash’s insight while addressing its specific failure modes.

Why Cashu Has a Better Chance

The structural alignment in 2026:

Lightning Network exists. A payment rail capable of sub-cent settlement at scale. Hashcash predated this by decades.

Cashu provides bearer instruments. Tokens that travel in email bodies. Hashcash’s primitive could not flow value; tokens can.

Adoption is incremental. Sender and recipient can transact directly without coordinating a protocol-wide rollout. Hashcash required global coordination.

The cost flows to the recipient. Aligned incentives instead of pure cost. Hashcash burned CPU cycles into nothing.

The technology is mature. Lightning has been operational since 2018; Cashu has been operational since 2022. Both have been validated through real-world deployment. Hashcash’s deployment was always limited to opt-in early adopters.

These differences do not guarantee Cashu’s success, but they remove the specific failure modes that killed Hashcash. The category is structurally enabled in a way that it was not 25 years ago.

A Specific Honest Note

Hashcash was a clever idea that failed for structural reasons specific to its design. The current generation of email-cost mechanisms addresses each of those reasons. The category has a structurally better chance of succeeding now than it did then.

The success is not guaranteed. Adoption depends on enough users finding value in the specific use cases (cover charges for unknown senders, spam reduction, attention markets). The value proposition has to compete with default email and with adjacent tools. The competition is real.

What is different now is that the structural barriers (no payment rail, protocol-level coordination, asymmetric hardware) that killed Hashcash are no longer in the way. The category is competing on user value rather than on infrastructure feasibility.