What is ecash?
Ecash is digital cash that uses cryptographic signatures rather than account balances. The idea predates Bitcoin by more than two decades. David Chaum proposed it in 1983, founded DigiCash in 1989, and built the first commercial implementation in the early 1990s.
In an account-based system, the bank tracks who owns what. Alice has $100. Bob has $50. To pay, Alice tells the bank to deduct $10 from her balance and add $10 to Bob's. The bank knows every transaction.
In an ecash system, the bank issues tokens that represent value. Alice has a token worth $10. To pay, Alice gives the token to Bob. The bank does not see the transfer; only the eventual redemption. Tokens are bearer instruments: whoever holds them owns them.
How Cashu mints work.
A Cashu mint is a server that holds Lightning sats and issues blinded-signature tokens against them. The flow has three steps: mint, transfer, melt.
Mint: Alice pays a Lightning invoice to the Cashu mint. The mint receives, say, 1,000 sats over Lightning, and issues Alice 1,000 sats worth of Cashu tokens. The tokens are signed by the mint but blinded so the mint cannot link the signature to Alice's identity.
Transfer: Alice sends the token to Bob. The transfer can happen over any channel: email, chat, a physical USB drive, a printed QR code. The token is bytes; the transport does not matter.
Melt: Bob redeems the token at the same mint. The mint verifies the signature, marks the token as spent (in its internal database of spent-token hashes), and pays Bob a Lightning invoice for 1,000 sats. Bob now has 1,000 sats in his Lightning wallet.
Why bearer tokens are the right primitive.
For email payments specifically, bearer tokens solve a problem that account-based systems cannot. If Alice wants to send Bob a payment along with an email, an account-based system requires Alice and Bob to both have accounts at the same provider, both to authenticate, and the provider to mediate the transfer.
A bearer token can simply be embedded in the body of the email. Bob's software reads the token, redeems it, and the value lands in Bob's wallet. There is no account. There is no login. There is no callback. The payment is just data, the same way the email body is just data.
This is structurally different from a Stripe-style payment link, where a click takes the recipient to a hosted page that handles the transaction. With Cashu, the value is in the message itself. Rythm reads the message, finds the token, redeems it, and the cover-charge settles to your wallet, all in memory, all in milliseconds.
Privacy properties.
Cashu uses Chaumian blinded signatures. The mechanism: when Alice asks the mint for a token, she sends a blinded message. The mint signs it without seeing the underlying content. Alice unblinds the signature locally and ends up with a valid token signed by the mint, without the mint having seen the token.
The practical consequence: when Bob redeems the token, the mint can verify the signature is authentic but cannot link the redemption to Alice's original purchase. The mint sees that some token was issued, and that some token was redeemed, but cannot connect the two.
This is meaningfully stronger privacy than on-chain Bitcoin. On-chain, every transaction is recorded on a public ledger tied to addresses. With sufficient analysis, on-chain payments can be deanonymized. Cashu transactions are not recorded on a public ledger at all; the mint sees only its own issue-and-redeem flow, and that flow is unlinkable.
Multi-mint architecture.
Cashu mints are independent. Anyone can run one. Tokens issued by one mint are not directly fungible with tokens from another mint, but they can be swapped through Lightning: redeem a token at mint A to get sats, then mint a new token at mint B with those sats.
Multi-mint architecture is a feature, not a bug. It avoids the single-issuer problem of older ecash designs (DigiCash failed in part because there was only one issuer). If a mint goes offline, becomes untrustworthy, or shuts down, users with tokens at that mint can be at risk; but users with tokens distributed across multiple mints can route around the problem.
Rythm supports any standards-compliant Cashu mint. The system uses public mints by default and falls back to alternatives if the primary is unreachable. Users can also self-host a mint if they want to operate the issuer themselves.
Why Rythm uses Cashu under the hood.
Cover-charge payments need three properties. First, they need to be embeddable in email bodies (because that is the channel the bouncer reads). Second, they need to settle peer-to-peer with no custodian (because Rythm is non-custodial by design). Third, they need to be private enough that paying to reach someone does not become a public record of who paid whom.
Cashu is the only protocol that combines all three. Bearer tokens embed naturally in email. Lightning settlement is peer-to-peer. Blinded signatures keep the payment private from the mint. No other widely-deployed payment system has this combination.
The user experience is invisible. Senders attach a Cashu token to their email (handled by the cover-charge flow). Rythm reads the email, finds the token, verifies the signature, and melts it to your Lightning wallet, all in memory. The token is never stored. The email content is never stored. Rythm exists in the message-processing path for milliseconds and then forgets.
Where Cashu fits in the broader payment landscape.
Cashu is not a general-purpose payment system. It is a specialized layer for payments that benefit from bearer-instrument semantics: tiny payments, payments embedded in messages, payments where privacy matters, payments where account creation would be friction.
For most consumer payments, account-based systems (cards, bank transfers, payment apps) are still the right fit. Chargebacks, recurring billing, and dispute resolution all assume account identity. Cashu does not provide those things and does not try to.
The use cases where Cashu shines are exactly the use cases that account-based systems handle poorly: pay-per-message communication, machine-to-machine micropayments, point-of-sale-style anonymous purchases, and tipping flows where the cost of account creation exceeds the payment value. Email cover charges are squarely in that bucket, which is why the protocol fits the product so naturally.