Timechain Wiki

Cashu

11 min read

Cashu is a single-mint chaumian-ecash protocol on top of Bitcoin and Lightning, designed by calle (Andreas Sumper) with a simpler trust profile than Fedimint. Where Fedimint distributes trust across a federation of guardians, Cashu is operated by a single mint that issues blinded ecash tokens backed by Bitcoin held in the mint's Lightning-connected wallet. The single-mint architecture accepts strong custodial trust at the mint in exchange for substantial UX simplification: instant payments within the mint, strong recipient privacy via the chaumian construction, nostr-zap integration, and minimal protocol complexity. Cashu has emerged as the dominant ecash architecture in the Nostr ecosystem and has small but real deployment in remittance and content-creator use cases. Users accept that the mint operator could in principle abscond with the backing Bitcoin; the principal mitigation is small mint sizes and social-trust dynamics.

Why this note matters

Cashu represents the simplest deployable ecash architecture on Bitcoin and Lightning. Where Fedimint’s federation adds operational complexity (BFT consensus, threshold signing, multi-guardian coordination), Cashu’s single-mint architecture removes that complexity entirely. The cost is concentrated custodial trust: users must trust the single mint operator’s honesty and operational continuity.

The deliberate-simplicity design choice matters for the broader Bitcoin Layer-2 trust spectrum. Cashu is a structural intermediate between Lightning self-sovereignty (no custodial trust) and pure custodial wallets (full custodial trust). The chaumian privacy properties and Lightning-Bitcoin denomination preserve some Bitcoin-architecture properties while introducing single-operator trust at the mint layer.

The single-mint architecture

A Cashu mint is operated by a single entity (an individual, a small team, or an organization) running mint infrastructure. The mint:

  • Issues blinded ecash tokens in exchange for Bitcoin received via Lightning. Each ecash token is a blinded signature that the mint produces but does not see the unblinded form.
  • Verifies and redeems ecash tokens when presented for redemption, paying out Bitcoin via Lightning to the redeemer’s destination.
  • Maintains the mint’s Bitcoin balance in Lightning-connected wallet infrastructure (the mint’s hot Lightning node).
  • Operates the mint’s public-facing API that wallets connect to for deposits, transfers, and redemptions.

The mint is single-keyed. Unlike Fedimint’s threshold-signed federation, a Cashu mint typically uses a single signing key (or a single multi-sig set under common control). This is the simplification that makes Cashu operationally lighter than Fedimint.

The trust model:

  • The mint could in principle steal user funds. If the mint operator absconds with the backing Bitcoin, users with outstanding ecash tokens lose those funds. There is no cryptographic protection against malicious mint exit (no protocol-level mechanism analogous to Lightning’s force-close or Fedimint’s threshold signing).
  • The mint could refuse to redeem. Operational refusal or technical failure of the mint produces user-side loss-of-access.
  • The chaumian privacy guarantee depends on the mint’s honest behavior. A compromised or coerced mint could log interactions and reconstruct the transfer graph.

The mitigation is small mint sizes. Cashu mints are deliberately small. A small mint operator who absconds harms a small community of users — bounded blast radius. A small mint operator under social-trust dynamics is operationally accountable in ways that large institutional custodians are not.

De-risking research (as of mid-2026). The protocol’s designer has described an active research trajectory for reducing the custodial trust without full federation, in escalating stages: (1) trusted-execution-environment (TEE) mints — the mint runs inside a hardware enclave the operator provably cannot access, with remote attestation letting clients verify exactly which mint software is running before depositing; this removes operator theft and covert inflation (and gives the operator plausible deniability against coercion), and works today as a proof of concept with on-chain backing, though running Lightning inside an enclave remains hard. (2) Unilateral exit via exclusion proofs — commit the mint’s spent-token set as a sparse-Merkle-tree root on-chain, so a holder can prove a token is unspent and withdraw directly from reserves even if the mint is offline; this requires OP_CAT-class script capabilities (or Ark-style systems where such proofs are cheap) and is explicitly incomplete design work. (3) Timelock-plus-quorum recovery — reserves held in a script where a third-party quorum gains control after an extended timelock, covering the mint-shutdown case. Stage 1 is working but unrolled-out; stages 2–3 are research. None of this changes the current operational reality: today’s Cashu custody model remains single-operator trust.

The chaumian privacy properties

Cashu inherits the same chaumian-ecash privacy properties as Fedimint:

  1. Deposit. Alice sends Lightning to the mint; the mint issues Alice blinded ecash tokens. The mint sees Alice’s Lightning identity but does not see the unblinded ecash.
  2. Private transfer. Alice gives Bob her ecash tokens. The transfer is off-protocol from the mint’s perspective.
  3. Redemption. Bob redeems with the mint; the mint verifies and pays out via Lightning to Bob’s destination. The mint sees Bob’s Lightning identity.
  4. Unlinkability. The mint cannot link Alice’s deposit to Bob’s redemption — the blinding ensures the unblinded tokens Bob redeems are cryptographically unlinkable to the blinded tokens the mint signed for Alice.

The privacy guarantee is strong within the mint’s operational scope. Outside the mint (i.e., when ecash is exchanged for Lightning on either end), the privacy property reverts to the Lightning-level privacy (onion-routed; hop-level encryption; but LSP-visible at endpoints).

The privacy-vs-trust tradeoff. Cashu’s privacy is comparable to Fedimint’s — both use the same chaumian construction. The trust profile is more concentrated: Fedimint distributes the operational-trust across guardians, Cashu concentrates it in a single operator. The privacy boundary is worth stating precisely: blinding hides who holds and spends which token (and hides balances and the payment graph from the mint); it does nothing to protect the aggregate reserve from operator theft. Privacy and custody protection are separate properties.

The cryptographic construction, precisely. Cashu’s original scheme is not Chaum’s RSA blind signature but a secp256k1 blind Diffie-Hellman scheme devised by David Wagner in 1996 — created specifically because Chaum had patented RSA blind signatures. Strictly, Wagner’s construction is a blind MAC rather than a blind signature: tokens are verifiable only with the mint’s private key, so third parties cannot verify them, and Cashu compensates with DLEQ (discrete-log-equality) proofs. In mid-2026 the project built and announced a migration to pairing-based BLS signatures — making tokens publicly verifiable, which substantially simplifies third-party-assisted exit and recovery constructions — deployed as a new keyset version so that wallets upgrade transparently.

Nostr-zap integration

Cashu has emerged as the dominant ecash architecture in the Nostr ecosystem. The Nostr-zap-via-Cashu pattern:

  1. A Nostr user wants to send a zap (Lightning-tip) to a content creator.
  2. The sender’s wallet holds Cashu ecash from a mutually-recognized mint.
  3. The sender transfers ecash to the creator via a Nostr direct-message or a zap-specific protocol.
  4. The creator can redeem the ecash via the mint for Lightning at their convenience.

The pattern’s appeal:

  • Instant transfer. Ecash transfer is off-protocol from the mint; the creator receives ecash immediately without waiting for Lightning payment confirmation.
  • Strong recipient privacy. The mint cannot link the sender to the recipient; only the mint sees the deposit and the redemption.
  • Offline-creator capability. The creator can accept ecash without their Lightning node being online; redemption can happen later.
  • Cashu wallet UX simplicity. Cashu wallets (Minibits, Macadamia, eNuts, Nutstash) are simpler than Lightning wallets — no channels, no inbound-liquidity, no routing concerns.

The Nostr-and-Bitcoin ecosystem alignment has produced substantial Cashu deployment. By 2026, multiple Nostr-aligned Cashu mints operate with thousands to tens of thousands of users each.

The deliberate-simplicity design

calle’s design choice for Cashu was deliberate: single-mint custody is simpler than federation and explicitly suited to certain use cases. The design rationale:

  • Operational reality. Most small-scale Bitcoin-aligned communities are operationally capable of running a single-operator service but not a multi-guardian federation. The single-mint architecture meets users where they are.
  • Trust-where-you-are. A single mint operated by a Nostr-aligned community for that community’s use is trust-bearing within an existing trust relationship. The mint operator is not a remote custodian but an accountable community member.
  • Recoverability of in-flight ecash. Users typically hold ecash for short periods (seconds to days) — long enough to redeem when convenient but not long enough to accumulate substantial mint-failure risk.
  • Composition with self-custody. Cashu ecash is naturally a small-balance, frequent-transaction layer that sits alongside (not replaces) self-sovereign Bitcoin holding. Users hold most of their Bitcoin in self-custody and use Cashu for the small-and-frequent flow.

The design discipline is principled. Cashu is not trying to be a custodial bank or a federation; it is trying to be a chaumian-ecash mint with the trust profile that follows.

Mint ecosystem and wallet implementations

As of 2026, the Cashu ecosystem includes:

  • Mint implementations. The reference Cashu mint implementation (github.com/cashubtc/cashu) is operated by various mint operators. Multiple alternative implementations exist (cashu-rs in Rust; nutshell in Python; others).
  • Wallet implementations. Minibits, Macadamia, eNuts, and Nutstash are the principal Cashu-compatible wallets. Each supports interacting with multiple mints simultaneously, allowing users to hold ecash from various mints.
  • Mint operators. A few hundred to a thousand-plus mint operators run public Cashu mints. The total backing-Bitcoin in Cashu mints is small relative to Lightning or Liquid but growing.
  • Nostr integration. Damus, Amethyst, Primal, and other Nostr clients integrate Cashu wallets for zap and direct-payment use cases.

The federation-of-mints pattern. Some Cashu deployments effectively create informal “federations of mints” by having a community accept ecash from multiple operator-mints. This produces a meta-architecture with somewhat better distributed-trust properties than a single-mint deployment, though it remains operationally simpler than Fedimint’s BFT-coordinated federation.

Tradeoffs and design choices

Single-mint custody vs federation trust. The principal design trade. Cashu prioritizes simplicity over trust-distribution; Fedimint prioritizes trust-distribution over simplicity. Both architectures have legitimate niches; users choose based on the trust-distribution preference and the operational-complexity preference.

Small-balance frequent-transaction use vs large-balance long-term storage. Cashu is structurally appropriate for the small-and-frequent flow; long-term large-balance storage should remain in self-sovereign Bitcoin. The composition with self-custody is the principal-disposition recommendation.

No-force-close vs Lightning’s unilateral exit. Cashu has no cryptographic mechanism for unilateral exit if the mint becomes unresponsive. Lightning’s force-close is a structural exit-guarantee; Cashu’s exit-guarantee is “redeem before the mint fails.” This is a meaningful structural difference. Unilateral exit is an active research direction (on-chain mint-state commitments with sparse-Merkle exclusion proofs — see the de-risking research above), but as of 2026 it is design exploration, not a protocol feature.

Privacy-without-distribution-of-trust vs Tor / mixing alternatives. Cashu’s privacy is structurally strong but operationally trust-bearing on the mint. Alternative privacy architectures (Tor-routed Lightning, on-chain Coinjoin, statechain coin-swap) have different privacy-trust profiles. The right architecture depends on the specific threat model.

Nostr-aligned community-trust dynamics. Cashu’s deployment in Nostr communities works because the mint operators are community-accountable. Cashu without the community-accountability dynamic would be a different design proposition — closer to pure custodial wallets without the privacy property.

Substantive analytical critique of single-operator custodial trust lives in Custody concentration risks; the broader Layer-2 trust-spectrum is in Self-custody configuration ladder and the operational discipline of choosing between architectures is in Threat modeling for self-custody.

Open questions for further development

  • What is the long-run mint-operator-failure rate? As Cashu’s deployment grows, the empirical rate of mint failures and the resulting user losses will become observable.
  • How does Cashu scale beyond Nostr-aligned communities? The community-trust dynamic is structurally important; whether Cashu can scale beyond contexts where that dynamic holds is unsettled.
  • What is the appropriate regulatory framing? Cashu mints are structurally custodial but small-scale; how regulatory authorities classify them is jurisdiction-specific and evolving.
  • Can mint-federation patterns (multi-mint composition) achieve trust-distribution without federation complexity? This is the active design conversation in the Cashu community.
  • How does Cashu interact with Fedimint as Layer-2 architectures coexist? Many use cases could be served by either; some users may run both. The ecosystem stratification is in progress.

Canonical sources for this note

Foundational design

  • calle (Andreas Sumper), Cashu protocol specification: github.com/cashubtc/nuts (the “NUTs” — Notation, Usage, and Terminology specifications)
  • Cashu documentation: cashu.space
  • Various conference presentations and blog posts by calle
  • calle in dialogue on ecash mints (No Solutions, recorded at the Oslo Freedom Forum, mid-2026) — primary source for the blind-MAC/DLEQ distinction, TEE-mint research, and the BLS keyset migration
  • David Wagner’s 1996 secp256k1 blind Diffie-Hellman scheme — the actual construction underlying original Cashu

Cryptographic primitives

  • David Chaum, “Blind Signatures for Untraceable Payments” (1983) — the chaumian-ecash construction
  • BIP340 (Schnorr signatures) — used in some Cashu variants

discussion references

Graph View

Backlinks