Cashu
Cashu is not a wallet app in the narrow sense. It is a protocol and implementation ecosystem for private, instant bearer ecash that Nostr clients can use for wallet state, mint discovery and token-based zaps.
Cashu is infrastructure, not one wallet
Cashu should be read as a protocol family and implementation ecosystem, not as a single consumer app. Cashu.me is a wallet. Cashu Redeem is a redeem flow. Nutshell is a Python mint and wallet implementation. cashu-ts is a TypeScript library. CDK is a Rust development kit. Cashu itself is the underlying Chaumian ecash protocol and the practical world of mints, wallets, token formats, libraries, NUT specifications and Nostr payment experiments that sit around it.
That distinction matters for a reader because Cashu changes the payment model. A Lightning wallet usually asks you to think about invoices, channels, routes or a custodian. A Cashu wallet asks you to think about mints, bearer tokens, proofs, swaps, melts, keysets and recovery. The user experience can feel much simpler than the machinery underneath. You may paste a token, scan a QR code, receive a nutzap or restore a wallet from relay data, but the real question is always which mint signed the tokens and whether you trust that mint with redeemable value.
Cashu belongs in the Lightning backend part of the Nostr map because most current mint and melt flows use Lightning invoices, and because Nostr clients want small payments that are fast enough to feel like social actions. It is also more than Lightning plumbing. The newer CDK release line adds on-chain payment support, payment backends, storage layers, Nostr restore options and FFI bindings. Treat Cashu as payment infrastructure with privacy ambitions and custodial risk, not as a cute side feature inside a Nostr client.
The mint and wallet split is the core
Cashu has two core actors: a mint and a wallet. The wallet creates blinded messages and later holds unblinded proofs. The mint signs blinded messages, verifies proofs when they are spent, and keeps enough spent-secret state to prevent double-spending. The Cashu website summarizes the product promise as digital bearer tokens stored on the user's device. That is the cash-like part: whoever holds a valid token can hand it to someone else.
The mint is not a bank account system in the normal sense. A mint does not need a named account database to make a token redeemable. The mint signs tokens, invalidates spent secrets and holds the underlying backing value. That can improve privacy because the mint is not naturally tracking an account ledger for every user. It also creates a hard trust boundary because the backing value is at the mint. If the mint fails, censors, lies or disappears, the user's proof may no longer be redeemable.
This is why Cashu articles must avoid sloppy self-custody language. A user may hold tokens locally, but the mint is still the issuer and redemption point. The right mental model is closer to cash issued by a trusted vault than to a private key that controls UTXOs directly. The wallet controls bearer proofs; the mint controls whether those proofs can be exchanged back into bitcoin, Lightning payments or another supported payment method.
Blind signatures are the privacy engine
The privacy claim rests on blind signatures. NUT-00 defines the basic cryptographic model around blinded messages, blind signatures and proofs on secp256k1. In plain language, a wallet asks the mint to sign something without the mint seeing the final secret that will later be redeemed. When the wallet unblinds the signature, it receives a proof that can be shown later. The mint can verify that the proof was signed by its key, but should not be able to directly link the issuance event to a later redemption.
That is a strong design property, but it is not invisibility dust. A mint can still see its own network traffic, timing, amount patterns, payment-method data, Lightning invoices, IP addresses if Tor is not used, and any clear authentication requirements it imposes. The Cashu FAQ is careful here: the protocol has a blinding mechanism that breaks a direct link, and it works without accounts in theory, but there are practical considerations around how privacy survives real-world use.
For Nostr, the privacy edge is attractive because social payments are often public by default. Normal zaps can tie an event, a sender, a recipient and a Lightning invoice into a visible social moment. Cashu can make other payment shapes possible, including P2PK-locked tokens and wallet state that follows the user across clients. The reader should still ask what is public on Nostr, what is visible to the mint, what is visible to relays and what is stored in a local wallet.
Minting, swapping and melting are the money path
The mandatory NUTs describe three operations that every serious Cashu integration has to understand. Minting turns an external payment into ecash. Swapping invalidates old proofs and issues new proofs, often to split or combine amounts. Melting turns ecash back into an external payment, such as a Lightning invoice. These words are not branding; they are the verbs that explain how value moves through the system.
NUT-04 defines minting as a two-step process. The wallet requests a mint quote, the mint returns a quote and payment request, the user pays the request, and the wallet asks the mint to issue blind signatures for the requested outputs. NUT-05 defines the opposite flow for melting. The wallet requests a melt quote for a payment request, then spends proofs to the mint so the mint can pay the external destination. NUT-23 gives the common BOLT11 Lightning invoice method for those mint and melt flows.
NUT-03 is the quiet workhorse. Swaps let a wallet create the denominations it needs, receive tokens safely, invalidate old proofs and get fresh proofs. If Alice has proofs worth one set of amounts and wants to send Carol a different amount, the wallet may need to swap first. This is why Cashu wallet quality matters: coin selection, fee reserves, keyset handling, token parsing, duplicate-proof rejection and interrupted swaps are not edge cases. They are how users avoid losing track of money.
NUTs are the interoperability surface
Cashu's specifications are called NUTs: Notation, Usage and Terminology. The `cashubtc/nuts` repository and rendered NUT documentation are the shared contract between wallets, mints and libraries. Mandatory NUTs currently cover cryptography and models, mint public keys, keysets and fees, swaps, minting, melting and mint information. Optional NUTs add state checks, overpaid Lightning fees, signature restore, spending conditions, P2PK, DLEQ proofs, deterministic secrets, WebSockets, payment requests and authentication patterns.
A user does not need to memorize every NUT number, but a builder does need to know which ones are implemented. NUT-06, for example, is the mint information endpoint that tells a wallet how to interact with a mint, what methods it supports, what contacts or terms it publishes and which NUT capabilities it advertises. NUT-12 lets a recipient verify offline that a mint used the same private key for a public key and a signature through DLEQ proofs. NUT-13 speaks to deterministic secrets and recovery from seed-like material.
The danger is treating a Cashu logo as a compatibility promise. One wallet may support current token formats, DLEQ and Nostr wallet state. Another may only understand older token versions. One mint may support P2PK and WebSocket subscriptions. Another may not. For a Nostr app, the implementation matrix matters because a broken ecash payment may look like a social notification problem while actually being a mint capability or token-format problem.
Where Nostr enters Cashu
Cashu does not need Nostr to exist. Mints and wallets can exchange tokens without Nostr relays. The Nostr link appears where wallet state, social payments and mint discovery benefit from a shared event network. The three important documents are NIP-60 for Cashu wallets, NIP-61 for nutzaps and NIP-87 for Cashu and Fedimint discoverability. Together they explain why Cashu appears in Nostr ecosystem maps as more than a random wallet feature.
NIP-60 defines operations for a Cashu-based wallet whose information is stored on relays so it can be available across applications. The high-level flow uses a replaceable wallet event, encrypted token events and optional spending history. That can make a user's ecash wallet portable across Nostr clients, but it also means the client has to handle encryption, relay selection, restoration, token state and proof secrecy correctly. Relay storage is useful only if secrets remain secret.
NIP-87 adds discovery. It describes events for mint operators to announce mints and capabilities, users to recommend mints and seekers to query those recommendations. This is a natural Nostr use case: mints are social trust objects as much as technical endpoints. You want to know which mints a community uses, which units they support, whether they are reachable, and who is recommending them. Discovery does not solve trust, but it gives trust a public trail.
Nutzaps are not ordinary zaps
NIP-61 defines nutzaps, and this is where Cashu becomes a social payment object. A nutzap is a P2PK Cashu token in which the payment itself acts as the receipt. Instead of the Lightning zap flow where a client requests an invoice and a service publishes a zap receipt, a sender can create or swap a Cashu token locked to the recipient's advertised P2PK key and publish it as a Nostr event.
The flow is specific. Alice fetches the recipient's `kind:10019` informational event to learn which relays, mints and P2PK pubkey the recipient uses. She mints or swaps a token at an accepted mint, locks it to the recipient's P2PK key, and publishes a `kind:9321` nutzap event. The recipient's client later fetches events from the advertised relays and swaps the token into its wallet. If a client sends to an unlisted mint or ignores the advertised pubkey, it may burn value or create a token the recipient cannot redeem.
That makes nutzaps more self-contained than ordinary zaps, but also less forgiving. The receiving setup matters. The mint list matters. The P2PK key must not be the user's main Nostr identity key. The client must track redemption history and avoid replay confusion. A product should not describe nutzaps as just zaps with a different logo. They are bearer-token payments carried by Nostr events, with a different receipt model and a different failure surface.
Mint trust is the largest risk
Cashu privacy can be excellent while custody risk remains obvious. A mint can steal the backing funds. It can go offline. It can stop honoring proofs. It can rotate keysets badly. It can censor melts. It can publish a poor mint info endpoint. It can create operational failure through database loss, Lightning backend failure, exhausted liquidity, incompatible upgrades or bad authentication settings. None of those problems disappear because the protocol uses blind signatures.
The right question is not whether Cashu is safe in the abstract. It is which mint, which wallet, which unit, which keyset, which token format and which recovery path are in use. For small social payments, a mint risk may be acceptable. For meaningful balances, the user should diversify, withdraw, choose reputable operators and understand that local possession of a token is not the same as owning on-chain bitcoin. Mints are issuers and redemption points.
Nostr can help with mint reputation, but it can also amplify herd behavior. If one popular client defaults to one mint, a lot of users can inherit the same failure point. If one influencer recommends a mint, trust may become social rather than operational. NIP-87 can make recommendations visible, but recommendations still need evidence: uptime, operator identity or policy, fees, units, NUT support, liquidity, limits, terms and incident history.
Authentication cuts against privacy
Cashu's newer NUTs show that mints are becoming more operationally sophisticated. NUT-21 defines clear authentication through OAuth 2.0 or OpenID Connect for protected mint endpoints. NUT-22 defines blind authentication tokens so a mint can restrict usage to an authorized set while preserving privacy inside that set. These are serious building blocks for managed mints, communities, merchants and services that do not want an unlimited public faucet.
The privacy warning is direct. Clear authentication contains user information and breaks privacy when used broadly. A mint operator may need clear auth for abuse control, invite-only access, regional compliance or paid membership. A user should still understand that this changes the Cashu story. A mint can be private at the blind-signature layer and still collect identifying information at an access-control layer.
For Nostr apps, this matters because a client may make the mint feel like part of the social app. If the app hides authentication, terms, limits and data flow, the user cannot judge the tradeoff. A good Cashu integration says when a mint is open, when it is authenticated, when it uses blind auth, which endpoints are protected and whether the user's Nostr identity is being linked to mint access.
The developer stack is active and uneven
The public repositories show a living ecosystem. When checked on June 13, 2026, `cashubtc/nuts` had recent commits in June 2026, including NUT cleanup around malformed NUT-11 behavior and quote ID recommendations. `cashubtc/cashu-ts` had active June 12 commits and latest GitHub release `v4.5.1` from May 23, 2026. `cashubtc/nutshell` had release `0.20.1` from May 31, 2026 and June commits around wallet proof listing and backend work.
The TypeScript path matters for web and Nostr clients. The npm registry showed `@cashu/cashu-ts` at `4.5.1`, MIT licensed, with wallet features for connecting to a mint, requesting mint quotes, minting, sending, receiving, melting, checking proof state and BOLT11/BOLT12 payment methods. The package's own README warns that the project works with real sats and is still early enough that reckless use is a bad idea. That warning belongs in product thinking, not only in developer docs.
The Rust CDK path matters for mints, mobile bindings and serious wallet infrastructure. The GitHub API showed `cashubtc/cdk` at release `v0.17.0`, published June 12, 2026, with repository activity the same day. crates.io showed both `cdk` and `cashu` at `0.17.0`, updated June 12, 2026. This is good activity, but active infrastructure can also move quickly. A production app should pin versions, read migrations and test recovery before exposing users to balances.
CDK is becoming the implementation center
Cashu Development Kit is now one of the clearest implementation centers because it wraps protocol logic, wallet and mint building blocks, storage, HTTP server work and payment backends in Rust. The CDK documentation describes it as a complete and standalone implementation of the Cashu protocol for Bitcoin-backed ecash. OpenSats describes it as a Rust library for wallets and mints with storage backends including SQLite, PostgreSQL and Redb, an Axum-based mint HTTP server, and Lightning backends for CLN, LND, LNbits and LDK Node.
The `v0.17.0` release is especially relevant. It added NUT-30 on-chain payment support, a BDK-backed on-chain payment backend, multiple payment backends per currency unit, Redis Cluster cache support, seed-file startup, stronger payment request routing, P2PK signing key support, token-based melt preparation, configurable Nostr restore options and broader saga recovery work. It also warned mint operators to back up databases before upgrading because the release includes a mint database migration.
This is where the backend category becomes real. Cashu is not just a wallet UI feature. A mint operator may run `cdk-mintd`, connect CLN or LND, use a database, manage keysets, expose mint info, handle WebSocket subscriptions, add on-chain support and apply migrations. A Nostr client may use CDK bindings indirectly through Swift, Kotlin, Dart, Go or other wrappers. Every one of those layers can be the source of a user-visible payment failure.
Nostr apps inherit Cashu's operational details
A Nostr client that adds Cashu does not only add a send button. It inherits mint selection, proof storage, token parsing, P2PK lock handling, DLEQ verification, NIP-60 relay backup, NIP-61 nutzap processing, NIP-87 mint discovery, Lightning mint and melt flows, and recovery behavior. That is a lot of hidden state for a feature that may look like a small tip or badge on screen.
Nutsack is a useful example of the direction of travel. Its repository describes a modern iOS Cashu wallet with NIP-60 backup, NIP-61 nutzaps, contact integration, multi-relay support and mint discovery. Sovereign Engineering's demo archive also points to Nutzaps as a Nostr-native effort spanning NIP-60 and NIP-61. These examples show that Cashu is not theoretical in Nostr. Builders are actively trying to make ecash feel like a normal social payment primitive.
The integration bar should be high. If a client stores wallet state on relays, it must explain what is encrypted and what remains metadata. If it fetches nutzaps, it must show redemption state. If it recommends a mint, it should show why. If it lets the user hold multiple mints, it should make balances and failure boundaries clear. A beautiful social payment can still strand funds if the mint or wallet state is treated as an implementation detail no one has to see.
What to test before using Cashu
Begin with tiny amounts and a specific mint. Check the mint info endpoint, supported NUTs, supported units, payment methods, fees, contact fields, terms URL, Tor or onion availability and recent operator communication. Mint a small amount. Send a token to another wallet. Receive it back. Melt to a Lightning invoice. Try a failed invoice. Try an expired quote. Try a duplicate token. If the wallet claims DLEQ support, confirm whether it verifies signatures and how it reports failure.
For Nostr, test NIP-60 and NIP-61 deliberately. Create wallet state on the relays you intend to use, then restore from another client or device. Send a nutzap to yourself using an advertised `kind:10019` event. Confirm that the P2PK key is separate from your main Nostr key. Redeem the nutzap, then check how the client records redemption history and prevents double counting. Use relays you can inspect, not only defaults you never reviewed.
For builders, read release notes before upgrading. CDK `v0.17.0` included a mint database migration warning. That is exactly the kind of detail that turns a library update into an operational incident if ignored. Pin versions, back up databases, test migrations, simulate interrupted mint and melt flows, verify cache behavior, rotate keysets carefully, test websocket cleanup and keep support logs useful without leaking payment secrets.
Who should care about Cashu
Cashu is most useful for readers who care about small private payments, Nostr-native wallet state, social tipping, redeemable vouchers, paywalls, merchant experiments, offline-ish token passing and Lightning-adjacent UX that does not expose every transfer as a Lightning route. It is also useful for builders who want ecash semantics without inventing blind signatures, proof management and mint APIs from scratch.
It is less useful for someone who wants pure self-custody with no issuer risk. Cashu improves the user experience around small value, but it introduces mint trust. The best use cases are honest about that. A wallet can say: this is good for spending money, social payments, vouchers and privacy-preserving small balances; withdraw meaningful value and diversify mints. That is a healthier message than pretending Cashu is either magic privacy or unacceptable custody.
For Nostr specifically, Cashu may become one of the payment layers that makes social money feel ordinary. NIP-60 can make ecash wallet state portable. NIP-61 can make nutzaps a native event type. NIP-87 can make mint trust visible. But the same lesson remains: protocol elegance is only the start. The user has to know which mint they trust, where proofs live, what relays store, how recovery works and how to exit back to bitcoin when the experiment stops feeling small.
Sources worth opening
Open the Cashu website and NUT specifications first, then read NIP-60, NIP-61 and NIP-87 beside the implementation repositories. Cashu is payment infrastructure, so the useful reading path is protocol model, mint trust, wallet state, Nostr event flow, implementation status and operational risk.
- Cashu official website
- Cashu documentation
- Cashu FAQ
- Cashu wallets documentation
- Cashu libraries documentation
- Cashu NUT specifications
- cashubtc/nuts repository
- NUT-00 cryptography and models
- NUT-03 swapping tokens
- NUT-04 minting tokens
- NUT-05 melting tokens
- NUT-06 mint information
- NUT-11 Pay-to-Pubkey
- NUT-12 DLEQ proofs
- NUT-13 deterministic secrets
- NUT-17 WebSocket subscriptions
- NUT-18 payment requests
- NUT-20 signature on mint quote
- NUT-21 clear authentication
- NUT-22 blind authentication
- NUT-23 BOLT11
- NIP-60 Cashu wallets
- NIP-61 Nutzaps
- NIP-87 Cashu and Fedimint discoverability
- Cashu GitHub organization
- Cashu Development Kit repository
- Cashu Development Kit documentation
- CDK release v0.17.0
- cdk crate on crates.io
- cashu crate on crates.io
- OpenSats CDK project page
- cashubtc/cashu-ts repository
- cashu-ts release v4.5.1
- cashu-ts npm package
- cashu-crypto npm package
- cashubtc/nutshell repository
- Nutshell release 0.20.1
- cdk-swift repository
- cdk-kotlin repository
- cdk-python repository
- BTCNutServer repository
- Nutsack iOS Cashu wallet
- Sovereign Engineering demo projects
- Nostrbook kind 17375 Cashu Wallet
- Nostrbook kinds index
- Bitcoin Design guide to Cashu
- Nodana CDK mintd template
- Awesome Cashu resources
