Cashu is an open ecash protocol that issues bearer-instrument tokens against deposits at a Cashu mint. The mint receives a Lightning payment from a sender, issues a token to the sender, and later redeems the token for an equivalent Lightning payment to whoever holds it. The token is a string of text that can be carried in any medium, including the body of an email.

How does Cashu enable email payments?

A sender buys a Cashu token from a public mint, attaches the token to the body of an email, and sends the email. The recipient (or software acting on their behalf) parses the token from the email, verifies it with the mint, and melts it to a Lightning payment that settles to the recipient's wallet. The flow is peer-to-peer; no intermediary processes the payment.

What are the privacy properties of Cashu?

Cashu uses blinded signatures. The mint signs tokens without seeing which token corresponds to which signer, so the mint cannot link redemptions back to specific senders. Privacy is meaningfully stronger than Lightning Network alone, which is itself meaningfully stronger than on-chain Bitcoin.

What are the limits of Cashu?

Three. First, mints are trusted entities; a malicious or compromised mint can refuse to redeem tokens. Second, mints have liquidity limits; very large transactions are not the protocol's strong point. Third, the bearer-instrument property means lost or stolen tokens are unrecoverable. Each limit is mitigated in practice through multi-mint architectures and small-amount use cases.

How does Rythm use Cashu?

Rythm parses incoming email for Cashu tokens. When a token is found and the sender is not on the recipient's guest list, Rythm verifies the token against the issuing mint, melts it to a Lightning payment, and routes the payment to the recipient's LNURL. Rythm operates on tokens in memory and never stores them. The recipient's payment lands in their own Lightning wallet.

The Cashu Protocol Explained for Email

Cashu is the ecash protocol that enables instant micropayments inside an email body. Here is the technical explanation oriented for email use cases.

Cashu is the ecash protocol that enables instant micropayments inside an email body. The protocol is open, the specification is public, and the design choices are oriented around a specific set of properties: bearer-instrument tokens, blinded-signature privacy, and Lightning-based settlement. This post is the technical explanation oriented for email use cases.

The intended audience is technically-minded readers from the Bitcoin and Lightning communities, software engineers evaluating the architecture, or anyone who wants to understand how Rythm actually works at the protocol layer. We use technical terminology where it is the most precise option.

What Cashu Is

Cashu is an open ecash protocol. The protocol defines:

A standard for ecash mints (the entities that issue and redeem tokens).
A standard for tokens (the bearer instruments that represent value).
A standard for the operations on tokens (mint, melt, swap, check, info).
A standard for the cryptographic primitives that secure the protocol (blind signatures over BDHKE, currently using secp256k1).

The protocol is implemented in multiple compatible mint implementations (Nutshell, cdk, others) and multiple compatible wallet implementations (Cashu.me, Boltz, Minibits, Macadamia, others). The interoperability between implementations is real and has been validated through cross-implementation testing.

The relevant context for email use cases: the token is a string of text that can be carried in any medium. Including the body of an email.

How Cashu Tokens Work

The mechanics:

Mint operation. A user (or software acting on their behalf) sends a Lightning payment to a Cashu mint. The mint receives the payment and issues a token to the user. The token is a serialized string containing cryptographic proofs of value backed by the mint.

Melt operation. A holder of a Cashu token presents it to the issuing mint along with a Lightning invoice. The mint verifies the token, confirms it has not been previously redeemed, and pays the Lightning invoice. The token is consumed by the operation.

Swap operation. A holder of a Cashu token can exchange it for one or more new tokens at the same mint. Useful for splitting tokens (turning one large token into multiple smaller ones), combining tokens, or refreshing the cryptographic proofs.

Check operation. A holder can verify that a token is valid and has not been previously redeemed without consuming it. Useful for validating tokens before further action.

Info operation. Each mint publishes its capabilities (supported NUTs, fee structure, contact information, terms of service). Wallets and integrators query info to understand mint compatibility.

The token format is bearer-instrument: whoever holds the token can redeem it. This is structurally similar to physical cash or to traditional ecash protocols. The bearer property is what makes the email use case work, because the email is the medium that carries the bearer instrument.

The Privacy Property

Cashu’s signature scheme uses blinded signatures over Boneh-Diffie-Hellman key exchange (BDHKE). The mechanism:

Blinding. When a user buys a token, the wallet generates random secret material and blinds the proof before sending to the mint. The mint signs the blinded proof.

Unblinding. The wallet unblinds the signed proof to produce a usable token. The mint cannot link the unblinded token back to the original blinded signature.

Redemption. When the token is later redeemed, the mint verifies the unblinded signature is valid but cannot identify which previously-issued blinded signature it corresponds to. The link from issuance to redemption is cryptographically broken.

The privacy property: the mint sees who buys tokens and who redeems tokens, but cannot link buyers to redeemers. Senders and recipients are unlinked at the mint layer.

This is meaningfully stronger than Lightning alone (where both endpoints can be observed by routing nodes) and significantly stronger than on-chain Bitcoin (where the public ledger preserves the link).

How Email Use Cases Work

The flow for an email payment:

Step one: sender buys a Cashu token. The sender uses any Cashu wallet to deposit Lightning sats at a public Cashu mint. The mint issues a token. The sender now holds a bearer instrument.

Step two: sender attaches the token to the email body. The token is just a string. It can be pasted into an email, embedded in a structured format, or otherwise included in the body. The email is sent normally.

Step three: recipient (or software) detects the token. Rythm parses incoming mail for tokens. The detection is structural: tokens have a recognizable format starting with cashuA or cashuB.

Step four: recipient verifies the token. The wallet or software queries the issuing mint to confirm the token is valid and has not been previously redeemed.

Step five: recipient melts the token. The wallet or software presents the token to the mint along with a Lightning invoice for the recipient’s wallet. The mint pays the invoice.

Step six: payment settles. The Lightning payment lands in the recipient’s wallet within seconds.

The whole flow is peer-to-peer. The mint is the only intermediary, and the mint cannot link sender to recipient because of the blinded-signature property. Rythm’s role is to automate steps three through five for the recipient. We covered the broader frame at non-custodial architecture.

The Mint Layer

Cashu mints are trusted entities in the protocol, but the trust scope is bounded.

What the mint is trusted for. Issuing tokens against deposits, honoring redemption requests, maintaining the cryptographic state, publishing accurate info.

What the mint cannot do. Identify which tokens correspond to which transactions (the blinded-signature property). Modify tokens after issuance. Censor tokens it has already issued (without breaking the trust model and being identifiable as malicious).

What the mint can do. Refuse to issue new tokens. Refuse to redeem tokens (in a censorship attack). Disappear (rug pull, where the mint goes offline with deposits).

The trust model is “trust but verify.” Mints publish info that wallets and users can monitor. Reputable mints have established operators, transparent practices, and (sometimes) external auditing. Multi-mint architectures (where wallets hold tokens at multiple mints) reduce single-mint exposure.

The NUT Specifications

The Cashu protocol is specified in NUTs (Notation, Usage, Terminology). The most relevant for email use cases:

NUT-00. Token format. Defines how tokens are serialized.

NUT-04. Mint operation. Defines how to acquire tokens from a mint.

NUT-05. Melt operation. Defines how to redeem tokens for Lightning payments.

NUT-06. Mint info. Defines how mints publish their capabilities.

NUT-07. Token state check. Defines how to verify token validity without consuming.

NUT-08. Lightning fee return. Defines how unused fee budgets are returned.

The full specification is at the cashubtc/nuts repository on GitHub. Implementers reference the NUTs directly.

What Rythm Does at the Protocol Layer

Rythm’s specific role in the Cashu flow:

Token detection. Parsing incoming email body for Cashu token strings. The parser recognizes both V3 (cashuA) and V4 (cashuB) token formats.

Mint info querying. When a token is detected, Rythm queries the issuing mint’s info endpoint to confirm capabilities and validate the mint is responsive.

Token state checking. Rythm uses NUT-07 check_state to verify the token has not already been redeemed before attempting to melt.

Melt operation. Rythm presents the token to the mint along with a Lightning invoice generated for the recipient’s LNURL. The mint pays the invoice. The Lightning payment settles to the recipient’s wallet.

Safety buffer. Rythm reserves a small buffer to cover Lightning routing fees during the melt. Unused buffer flows back to Rythm as the safety margin (this is the “keep the change” revenue model). The user’s wallet receives the payment minus the buffer.

In-memory operation. Throughout the flow, the email content and the token are processed in memory and discarded. Nothing is stored persistently.

A Specific Honest Note

Cashu is an active protocol with a meaningful and growing ecosystem. The protocol is open, the specifications are public, the implementations are interoperable. For email use cases, the bearer-instrument property and the blinded-signature privacy combine to enable a structurally non-custodial peer-to-peer payment in email.

The trust model places appropriate weight on mints; multi-mint architectures and reputable mint operators are the realistic mitigations. The bearer-instrument property requires care: lost tokens are unrecoverable, which is structurally similar to lost cash.

Rythm uses Cashu specifically for the email-payment use case, with additional engineering around safety buffer, multi-mint support, and the structural inbox-layer integration. The Cashu protocol is the underlying primitive; Rythm is the email-specific automation built on top.

For the related guides, see non-custodial architecture, the two missing pieces of the internet, what is a non-custodial email service, is a cover charge just spam tax with extra steps, and Rythm is not a cryptocurrency service. For the broader frame, see what non-custodial means in 2026 and the non-custodial email stack. Rythm is $1.65 per month, cancel anytime.

The Cashu Protocol Explained for Email Use Cases