What is a bearer token?

A bearer token is a payment instrument where possession equals ownership. Whoever holds the token can redeem it. There is no separate account, no signature requirement, no identity check. The token itself is the proof of value. Physical cash is the canonical bearer instrument; Cashu ecash is a digital one.

Why is the bearer property useful for email payments?

Email is itself a bearer-instrument medium. Whoever holds an email can read it; there is no separate authentication once delivered. Embedding a bearer token in the email matches the medium's properties: the token is delivered the same way the email is delivered, with the same custody model. Non-bearer alternatives require additional infrastructure that does not match email's design.

What are the trade-offs of bearer tokens?

Three trade-offs. First, bearer tokens are unrecoverable if lost (no account to retrieve from). Second, the holder is the spender; tokens have no built-in identity check. Third, double-spend prevention requires the issuing mint or equivalent. The first two are mitigated by keeping bearer tokens small and atomic. The third is the structural reason mints exist in the Cashu protocol.

Why not use account-based payments for email?

Account-based payments require both parties to have accounts at the same payment system, with all the friction that implies (signup, KYC, balance management). Bearer tokens require no such coordination; the sender attaches a token and the recipient redeems it through whatever wallet they prefer. The friction reduction is meaningful for the casual-payment use case.

Are bearer tokens secure?

Securely if used appropriately. The bearer property means lost tokens are unrecoverable; the security is the security of the medium carrying the token. For email payments, the token is small enough that loss in transit (rare but possible) is a small loss. The cryptographic properties of the token itself are strong; the bearer property is operational, not cryptographic.

Why Bearer Tokens Work for Email Payments

Bearer tokens are the right primitive for email payments because email is fundamentally a bearer-instrument medium. Here is the technical argument.

Bearer tokens are the right primitive for email payments because email is fundamentally a bearer-instrument medium. The structural alignment between token and medium produces a payment experience that matches what email already is: a delivery channel where possession of the message equals access to it. This post is the technical argument for why bearer tokens are the appropriate choice and what the trade-offs are.

What Bearer Means

A bearer instrument is one where possession equals ownership. Whoever holds the instrument can redeem its value. There is no separate registry of who owns it; the instrument itself is the proof.

Physical cash is the canonical bearer instrument. A $20 bill in your hand is yours; whoever finds it on the ground can spend it. There is no account, no signature, no identity check. The bill is the value.

Bearer instruments are not the only kind. Account-based instruments are the alternative: value is held in an account associated with an identity, and transfers require authenticating the identity. Most digital payments (credit cards, bank transfers, payment apps) are account-based.

Both designs have legitimate uses. The question is which is appropriate for which use case.

Why Email Is a Bearer Medium

Email’s structure has bearer properties built in:

Possession is control. Whoever has the email can read it. There is no per-message authentication; the email arrives in your inbox and you read it. The medium does not check whether you are the intended recipient before showing you the content.

Forwarding is permitted. You can forward an email to anyone. The forward carries the original content. The medium does not constrain who has access after delivery.

Storage is local. Email is stored on the recipient’s mail server (and potentially the recipient’s local devices). The medium does not require ongoing authentication to access stored mail.

Delivery is final. Once an email is delivered, it is delivered. There is no recall, no reversal. The medium does not preserve sender control after delivery.

These properties mean email functions like a bearer instrument for content. Embedding a bearer-instrument payment in an email is structurally aligned with how email works. A non-bearer payment in an email would require infrastructure (account systems, identity checks, ongoing authentication) that does not match email’s design.

What Account-Based Email Payments Would Require

Consider an alternative where email payments were account-based. The sender would have an account at some payment system; the recipient would have an account at the same (or interoperable) system. The email would carry a payment reference that the recipient redeems through their account.

The infrastructure required:

Both parties have accounts. Signup, KYC, account management at the payment system.

The accounts interoperate. Either both at the same system, or at systems that can clear payments between them.

The recipient authenticates to redeem. Login to the payment system, verification, balance management.

The payment system has visibility. The system sees which sender paid which recipient and can track patterns.

For casual email payments (cover charges, micropayments, small instances of value transfer), this infrastructure is too heavy. The friction kills the use case.

A bearer token requires none of this. The sender attaches the token; the recipient melts it through their preferred wallet. No accounts to coordinate, no KYC to onboard, no system in the middle to authenticate.

How Cashu Implements Bearer Tokens

Cashu is the digital ecash protocol that produces bearer tokens. The implementation:

Mint operation. A user (or software) deposits Lightning sats at a Cashu mint. The mint issues a token: a string of text containing cryptographic proofs of value. The token is the bearer instrument.

Storage. The token can be stored anywhere: in a wallet, in an email, in a text file. The medium is irrelevant to the protocol.

Redemption (melt). Whoever holds the 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 invoice. The token is consumed.

Double-spend prevention. The mint maintains a record of redeemed tokens. A token cannot be redeemed twice; the second attempt is rejected. This is the structural reason mints exist in the Cashu protocol; the bearer property requires a mechanism to prevent double-spend.

Privacy through blinding. Cashu uses blinded signatures so the mint cannot link issuance to redemption. The bearer property is preserved without sacrificing privacy.

We covered the protocol in detail at the cashu protocol explained for email use cases.

What Bearer Tokens Trade Off

Bearer instruments have specific trade-offs that account-based alternatives do not have:

Loss is permanent. A lost bearer token cannot be recovered. There is no account to query, no support team to call, no proof of ownership beyond the token itself. For email payments, this is mitigated by keeping tokens small (a four-cent loss is recoverable; a $4,000 loss would not be).

Theft is final. A stolen bearer token can be redeemed by the thief. There is no built-in recovery. Mitigated by keeping tokens small and treating them as cash.

No identity check at redemption. The redeeming party does not have to prove who they are. For most use cases, this is fine; the recipient is whoever the email was sent to.

Mint dependency for double-spend prevention. The mint must be available to verify redemption. If the mint is offline, redemption cannot happen. Mitigated by using reputable mints with high availability.

These trade-offs are acceptable for the email payment use case because the amounts are small and the goal is friction reduction. For larger or more sensitive payments, account-based or hybrid systems may be more appropriate.

Why Bearer Plus Lightning Is the Right Combination

The full design of email payments uses bearer tokens at the email layer and Lightning at the settlement layer:

Bearer at the email layer. Tokens are bearer instruments embedded in email bodies. The bearer property matches email’s medium properties.

Lightning at the settlement layer. When the token is melted, the underlying Lightning payment settles to the recipient’s wallet. Lightning’s instant, low-cost settlement matches the per-payment scale.

The combination produces:

Friction-free payment delivery (bearer in email).
Instant settlement to the recipient’s wallet (Lightning).
Cryptographic privacy (Cashu blinded signatures).
Peer-to-peer (no intermediary in the payment path).
Small per-payment overhead (sub-cent fees).

Each layer is necessary; neither alone is sufficient. The composed design is what makes email payments work.

A Specific Honest Note

Bearer tokens are the right primitive for email payments because email is a bearer-instrument medium. The structural alignment produces a payment experience that matches the medium. Account-based alternatives would require infrastructure that does not fit email’s design.

The trade-offs of bearer instruments (loss is permanent, theft is final) are acceptable for the small-payment use case because the amounts involved are small. For larger or more sensitive payments, different designs are appropriate.

Rythm uses Cashu bearer tokens specifically because the design aligns with email. The cover charge is a bearer instrument that travels with the email; the recipient redeems it through their wallet. The peer-to-peer flow and friction reduction are direct consequences of the design choice.

Why Bearer Tokens Are the Right Primitive for Email Payments