CraysCashu.me
Cashu.me is the most direct way many people meet Cashu: a web wallet for ecash, mints, small Lightning payments, Nostr Wallet Connect and the practical question of how private bearer money should behave inside Nostr apps.
A web wallet for ecash, not just a Cashu demo
Cashu.me looks simple from the outside: open the wallet, add a mint, receive ecash, send ecash, pay or create a Lightning invoice. That simplicity is why it matters. Cashu can otherwise feel like a protocol for people who already know blind signatures, mints, NUTs, token formats and Lightning settlement. Cashu.me turns those moving parts into a wallet surface that a normal person can touch.
The project is open source, lives under the cashubtc GitHub organization and describes itself as a Cashu wallet PWA. The live site redirects to wallet.cashu.me, publishes a web-app manifest, exposes web+cashu and web+lightning protocol handlers, and can be installed as a standalone web app. The repository is active, TypeScript and Vue heavy, and was still receiving updates on June 10, 2026.
For a Nostr reader, the important point is that Cashu.me is not only a wallet that happens to know about Nostr. Its current codebase contains dedicated stores for Nostr Wallet Connect, Nostr relays, Nostr payment requests, Nostr mint backups, NIP-60 wallet-state creation, npubcash and P2PK-locked tokens. Some of those features are mature user-facing flows, some are still early, but the direction is clear: Cashu.me is one of the places where ecash, Lightning and Nostr are being wired together.
The money model starts with mints
Cashu.me is a Cashu wallet, so the first serious question is not which Nostr relay it uses. The first question is which mint you trust. A Cashu mint accepts Bitcoin over a supported payment rail, issues blind-signed ecash tokens and later redeems those tokens. The wallet holds proofs locally. The mint does not run a normal per-user bank ledger, but it still controls whether tokens can be redeemed.
That gives Cashu its appeal and its risk. A wallet can move tokens around with less direct account tracking than a custodial database, and tokens can be handed from one person or app to another like bearer instruments. At the same time, a mint can fail, censor redemptions, lose funds, disappear, rotate keys badly or become unreliable. Cashu.me helps manage mints, but it cannot turn an untrustworthy mint into a safe one.
The wallet reflects this by making mint choice a real part of the interface. The onboarding and mint setup code lets a user add mint URLs manually, discover mints, restore previously used mints from Nostr backup data and inspect mint details. Recent release work added mint recommendations, mint review flows, mint icons, mint audit information, keyset handling and more careful mint selection. Those details are not decoration. In Cashu, mint choice is wallet security.
How receiving works in practice
When you receive through a Cashu mint, the wallet asks the mint for a quote, pays or waits for a payment to the mint, and then requests signed ecash proofs. In the BOLT11 path, that means a Lightning invoice. In Cashu terms, this is the minting side of the protocol. NUT-04 describes token minting in general, and NUT-23 describes the BOLT11-specific payment method.
Cashu.me implements this as a wallet flow rather than exposing the protocol as raw JSON. The code has a walletBolt11 store for BOLT11 mint quotes, a walletBolt12 path for BOLT12 offers where supported, and an on-chain mint path where a mint exposes that rail. It also has websocket handling for mint quote settlement so the wallet can react when a mint reports that a quote was paid, rather than relying only on clumsy refresh behavior.
This matters for readers because ecash wallets can otherwise feel mystical. In Cashu.me, receiving is still a payment into a mint followed by token issuance. The wallet user sees a receive screen and a balance. Underneath, the wallet tracks quotes, keysets, units, proof storage and settlement state. A failed receive can be a Lightning problem, a mint problem, a quote problem, a keyset problem or a browser storage problem.
How sending and paying differ
Cashu.me can send ecash tokens directly, and it can also melt ecash to pay a Lightning invoice. Those are related but not identical actions. Sending a Cashu token means handing bearer ecash to another wallet or person. Paying a Lightning invoice means asking the mint to redeem proofs and forward value over Lightning to the invoice destination.
The melt side is defined by NUT-05, with BOLT11 details in NUT-23. Cashu.me's code has payment dialogs, melt quote information, invoice detail views and store logic for invoice decoding, fee reserves, proof selection and change handling. That is the messy part users rarely want to see, but it is exactly where wallet reliability lives. The wallet needs to choose enough proofs, account for fees, handle change, mark pending state and avoid double-spending or double-paying.
A user should therefore read a Cashu.me balance as a balance inside one or more mint contexts, not as a single bank-like number with universal settlement guarantees. Tokens can be sent as ecash, melted to Lightning, swapped between mints or paid through newer request formats. Every path has its own failure mode. The good wallet behavior is not pretending those paths are the same; it is guiding the user through them without hiding the custody model.
Nostr Wallet Connect is the app-control surface
Cashu.me gained broader Nostr relevance when it added Nostr Wallet Connect. NWC lets another app request wallet actions through Nostr relays without taking custody of the wallet's private key or ecash proofs. The user creates a connection, the app receives a connection string, and encrypted request-response events carry commands such as paying an invoice or asking for a balance.
In the current Cashu.me NWC store, the supported method list includes pay_invoice, make_invoice, get_balance, list_transactions and lookup_invoice, with get_info handled as well. The wallet advertises methods through a NIP-47 info event, listens for request events, decrypts commands, runs the matching wallet action and publishes encrypted responses.
The important user-facing detail is the allowance. Cashu.me's settings text says NWC payments are made from the active mint and active Bitcoin balance. The store starts a connection with an allowance value and subtracts paid amount plus fee reserve after a payment. This is the right mental model: an NWC string is not just a login code. It is a payment permission. A small allowance, a trusted app and a clear revocation path matter more than the thrill of making zaps feel automatic.
NWC is useful, but current compatibility needs checking
Cashu.me's NWC support is real enough to use in compatible flows, but it should not be treated as finished forever. The GitHub issue tracker currently includes an open issue titled "Update NWC support to current NIP-47 encryption behavior", opened on May 1, 2026. That is the kind of detail a wallet user or app builder should notice before relying on NWC for serious spending.
The code path visible today uses NIP-04 encryption for NWC requests and responses. NIP-47 has evolved around encryption details and compatibility expectations, and different NWC wallets and clients can be at different points in that evolution. The practical result is simple: test with the exact app you plan to use. Do not assume that every NWC-compatible Nostr client will behave identically with every wallet.
This is especially important because Cashu.me is a browser/PWA wallet. If the wallet is not open, initialized, listening on the configured relays and connected to the right active mint, the app-side experience may not match a hosted always-on wallet service. That does not make Cashu.me bad. It means its best NWC use starts with small allowances, active testing and a clear understanding of whether the wallet is acting as a live signer or a background service.
Payment requests make Nostr a receive path
Cashu.me also contains a payment-request store that can create requests with a Nostr transport. The code builds payment request data with amount, memo, unit, mint hints and a target derived from the wallet's Nostr signer profile. The settings text describes payment requests as a way to receive payments via Nostr and says the wallet subscribes to configured relays when the feature is enabled.
This is a different shape from NWC. With NWC, another app controls a wallet within a permissioned connection. With Nostr payment requests, the wallet can advertise or receive payment intent through relays. The receiving side still has to care about mints, units and compatibility, but the discovery and message path can move over Nostr rather than through a single hosted account system.
For readers, this shows why Cashu.me is not simply a private ecash wallet with a Nostr checkbox. It is experimenting with several ways money can move around Nostr: remote wallet control, relay-carried payment requests, mint backup events, P2PK-locked tokens and NIP-60 wallet-state ideas. The common thread is that Nostr provides addressing, relays and signed events while Cashu provides bearer ecash.
Nostr mint backup is practical, not glamorous
One of the most practical Nostr features in Cashu.me is mint-list backup. The wallet can derive a deterministic Nostr key from the wallet mnemonic using a cashu-mint-backup domain separator, encrypt the current mint list with NIP-44, publish it as a kind 30078 event and later search configured relays to discover previously used mints.
That may sound small compared with zaps and NWC, but it solves a real problem. In a Cashu wallet, the list of mints is part of recovery context. If a user restores a seed but forgets which mints held value, the recovery experience gets worse. A Nostr-backed mint list can help the wallet remember where to look without publishing a plain list of mints to the world.
The feature still deserves careful reading. It backs up mint URLs, not a magic guarantee that all proofs will be spendable. It depends on configured relays, encrypted event availability, the wallet seed, the implementation and the mints still existing. It is a recovery aid, not a substitute for understanding where funds live.
NIP-60 is present, but not the whole wallet story
NIP-60 defines Cashu wallets whose information is stored on Nostr relays so a wallet can be accessible across applications. The NIP describes encrypted wallet events, token events, spending history and relay-based wallet state. It is one of the reasons Cashu is interesting for Nostr: ecash can become portable across clients instead of being trapped in one app's local database.
Cashu.me contains a nip60 store that imports NDKCashuWallet from NDK wallet tooling, derives a wallet signer and creates a NIP-60-style wallet object from the user's mints, unit and relay list. That is a meaningful signal, but it should be read accurately. The public wallet experience is broader than NIP-60, and not every Cashu.me balance should be assumed to behave as a fully interoperable NIP-60 wallet across clients.
The safer reading is that Cashu.me is moving toward the Nostr-native Cashu direction while still carrying normal wallet work: proof storage, mint discovery, payment dialogs, invoices, NWC, on-chain/BOLT12 support, PWA installability and recovery flows. NIP-60 is part of the horizon. It is not the only thing Cashu.me is.
NIP-61 and P2PK explain why ecash zaps are different
NIP-61 defines Nutzaps: Cashu tokens locked to a public key and sent as Nostr events. In that model, the payment itself is the receipt. A sender discovers the receiver's mint and pubkey preferences, mints or swaps a P2PK-locked token and publishes a token event that the receiver can redeem.
Cashu.me is relevant here because the codebase has P2PK support, automatic npub conversion for P2PK work in recent release history and an open issue about accepting P2PK tokens with attached signatures even for unknown pubkeys. That tells you the wallet is dealing with the hard edge where Cashu tokens, public keys and Nostr event flows meet.
For a user, the distinction matters. A Lightning zap through NIP-57 usually produces an invoice and a zap receipt around a Lightning payment. A Nutzap is ecash sent through Nostr in a way that can be redeemed by the receiver. Both are value transfer, but they are not the same rail. Cashu.me sits close to the second model because it already understands tokens, mints and Nostr keys.
Storage moved beyond plain localStorage proofs
Browser wallets have a sharp storage problem. If ecash proofs live carelessly in localStorage, a malicious script, browser extension, profile compromise or user mistake can become a money-loss event. Cashu.me's current codebase shows that the team has worked on this area, including a transition to Dexie proof storage and migration logic that moves older cashu.proofs localStorage data into an IndexedDB-backed table.
Dexie does not magically make a browser wallet invulnerable. It is still local browser storage, still tied to the device/browser profile and still sensitive. But it is a better fit for structured wallet state than dumping everything into one localStorage key. The wallet tracks proofs by fields such as secret, id, C, amount, reserved and quote, which matches the need to manage proof state rather than just show a balance.
This is one of the places where Cashu.me should be judged like a real wallet, not a toy. Proof selection, migration, recovery, pending tokens, keyset rotation, quote checking and double-spend prevention are wallet engineering problems. The 0.2 release notes include many fixes around proof handling, keysets, pending states, payment attempts and migrations. Those are not glamorous, but they are exactly the work that keeps small ecash wallets from feeling fragile.
The current wallet is wider than BOLT11
Cashu started in many people's minds as Lightning-backed ecash, but Cashu.me's current codebase reaches beyond a single BOLT11 receive-and-pay flow. It has BOLT11 stores, BOLT12 stores, on-chain quote stores, websocket quote subscriptions, payment request support, NFC and NDEF work, token v4 support, keyset v2 support, BIP321 invoice handling and protocol handlers for Cashu and Lightning links in its manifest.
That breadth should be understood carefully. A wallet can support a code path only when the mint, browser, app and payment method also support it. A BOLT12 or on-chain path is not universal just because the code exists. Mint capabilities, NUT support and active unit support decide what can actually happen in a given wallet session.
Still, the direction matters. Cashu.me is not standing still as a small demo wallet. It is tracking the moving Cashu protocol, mint capabilities and browser/mobile behavior. The release notes for version 0.2 include Cashu TS upgrades up to v4, NUT-20 locking for mint quotes, NUT-26 payment requests in BIP321 URIs, CBOR token v4 support, keyset management, websocket support, BOLT12 and on-chain-related work. The wallet is trying to keep up with a fast protocol.
The PWA surface matters for everyday use
Cashu.me is built with Quasar and Vue, uses Pinia stores, depends on @cashu/cashu-ts, @nostr-dev-kit/ndk, nostr-tools, Dexie and Capacitor packages, and ships as a PWA. The manifest identifies it as Cashu.me, describes it as a Cashu ecash wallet for the web, sets standalone display, portrait orientation and mobile-friendly icons.
That matters because the easiest wallet to try is often the one that opens in a browser. A user can visit wallet.cashu.me, install it to a phone home screen, scan or paste tokens, add mints and experiment without an app-store gate. The same convenience is also a risk: browser profiles, mobile Safari behavior, extension exposure, service worker state and device backups all affect money safety.
Cashu.me's release history shows ongoing work around iOS PWA prompts, Capacitor Android and iOS builds, status bar behavior, mobile layout, on-screen keyboard handling, NFC scanning and install-like behavior. Those are the details that decide whether a protocol wallet feels usable on a real phone. A wallet that only works well on a developer laptop is not enough for Cashu's everyday promise.
Multi-mint use is powerful and easy to misunderstand
Cashu.me supports multiple mints, and the 0.2 release notes include multi-mint swap work, mint selection redesign and active mint balance checks. Multi-mint support is one of Cashu's most important practical features because it lets a user avoid putting all ecash value behind one mint. It also makes the wallet harder to reason about.
A balance spread across mints is not the same as a bank balance spread across accounts with the same guarantor. Each mint has its own keys, units, fees, liquidity, uptime and redemption risk. A token from one mint is not automatically useful at another mint unless it is swapped or melted and re-minted through a payment path. Cashu.me can help perform those movements, but the trust boundary still changes mint by mint.
This is why mint details, audit information, recommendations and reviews matter. They are not social decoration. They are the wallet's way of reminding the user that the mint layer is real. A good Cashu.me setup starts with small amounts, several known mints if needed, careful unit checks and an expectation that some mints may behave worse than others.
What to check before using it with a Nostr app
Before using Cashu.me with a Nostr client through NWC, create a tiny test balance and check the active mint. NWC payments in Cashu.me are made from the active mint and require the active unit to be sats. If the wrong mint is active, the app experience can be confusing even when the wallet is working correctly.
Then check the relays. Cashu.me uses configured Nostr relays for operations such as payment requests, Nostr Wallet Connect and backups. If an NWC client cannot reach the same relay path, the problem may look like a wallet failure when it is really a relay or subscription issue. Add relays deliberately and remember that a relay is part of the payment-control workflow.
Finally check compatibility and limits. Use a small NWC allowance, pay one small invoice, make one invoice, list transactions and then disconnect or disable the connection. If the client depends on newer NIP-47 encryption behavior, test that before funding the wallet. If the wallet must work while the browser is closed, understand whether your device and PWA environment actually keep the needed listener alive.
What to check before trusting a mint
A mint deserves the same kind of attention you would give any custodian, even though Cashu's privacy model is different from a normal account system. Look for operator reputation, uptime, NUT support, units, fees, Lightning liquidity, contact information, published audits or community reports, keyset rotation behavior and a sensible policy around outages.
Use Cashu.me's mint details and external sources together. A mint can have a nice icon and still be a bad place for meaningful funds. A mint can be technically interesting and still be experimental. A mint can be fine for small private tokens and wrong for business-critical payments. Cashu's design reduces some metadata exposure; it does not remove counterparty risk.
The best practice is boring and effective: start small, split exposure if appropriate, test redemption, keep backups, understand recovery, and do not treat a web wallet as cold storage. Cashu.me is a strong tool for practical ecash use, but the safest Cashu user is the one who remembers that mints are part of the wallet, not an invisible backend.
Where Cashu.me fits in the Nostr wallet landscape
Cashu.me is not the same kind of wallet as Alby Hub, Zeus, LNbits, Coinos, Phoenix, Bitvora or a self-hosted Lightning node. It is an ecash wallet first. That makes it especially interesting for small private balances, token-style transfers, mint experiments, Nostr payment requests, NIP-60/NIP-61 work and NWC connections that spend from a Cashu balance rather than a node channel.
That also means it is not a universal answer. If you need channel control, self-custodial Lightning routing, enterprise approvals, accounting exports, always-on server reliability or a hosted API account, another wallet layer may fit better. If you want to understand how bearer ecash can become part of Nostr apps, Cashu.me is one of the most important wallets to study.
The healthiest way to approach Cashu.me is as a working wallet inside a fast-moving protocol family. It is usable, open, active and ambitious. It is also tied to mint trust, browser storage, relay behavior and evolving Nostr wallet standards. That mix is exactly why it deserves a real article instead of a one-line entry in a wallet list.
Sources worth opening
Start with the live Cashu.me wallet and GitHub repository, then read the 0.2 release notes, PWA manifest, NWC store, Nostr backup store, NIP-60 store, payment-request code, Cashu wallet documentation, NUT specifications and the Nostr NIPs that explain why Cashu.me matters to Nostr apps.
- Cashu.me live wallet
- Cashu.me public landing redirect
- Cashu.me GitHub repository
- Cashu.me README
- Cashu.me package.json
- Cashu.me PWA manifest
- Cashu.me source PWA manifest
- Cashu.me 0.2 release notes
- Cashu.me releases
- Cashu.me NWC store
- Cashu.me NWC dialog component
- Cashu.me settings component
- Cashu.me English interface strings
- Cashu.me Nostr store
- Cashu.me NIP-60 store
- Cashu.me Nostr mint backup store
- Cashu.me payment request store
- Cashu.me Dexie proof storage
- Cashu.me wallet store
- Cashu.me BOLT11 wallet store
- Cashu.me BOLT12 wallet store
- Cashu.me on-chain wallet store
- Cashu.me mint websocket store
- Cashu.me P2PK store
- Cashu.me npubcash store
- Cashu.me mint recommendations store
- Cashu.me issue 522 on NWC encryption behavior
- Cashu.me issue 511 on P2PK token signatures
- Cashu documentation: wallets
- Cashu protocol site
- Cashu NUT specifications
- NUT-04 Minting tokens
- NUT-05 Melting tokens
- NUT-10 Spending conditions
- NUT-17 Websocket subscriptions
- NUT-20 Signature on mint quote
- NUT-23 BOLT11
- NIP-47 Nostr Wallet Connect
- NIP-60 Cashu wallets
- NIP-61 Nutzaps
- Nostr Wallet Connect official site
- NWC documentation
- Umbrel Cashu.me app listing
- Plan B Academy Cashu.me tutorial
- Awesome Cashu wallet list
