NIP-60: Cashu Wallets
Ecash needs wallet state that can move between clients
Cashu is bearer ecash. A Nostr client can use it, but the wallet state has to live somewhere. If every app keeps its own local store, a user loses portability. If one custodial app owns the state, the user loses the open-client benefit.
NIP-60 stores the user's Cashu wallet information as encrypted Nostr events. The wallet event names mints and a separate P2PK wallet private key. Token events store unspent proofs. Spending history events give an optional transaction log. The result is not a mint and not a Lightning wallet. It is a portable state layer for a Cashu wallet.
That distinction matters. NIP-60 does not define receiving someone else's payment. NIP-61 Nutzaps handle that side. NIP-60 keeps the wallet's own state synchronized.
Wallet metadata, proofs and state transitions
Kind 17375 is the replaceable wallet event. It contains encrypted wallet settings: mints and a wallet-only private key used to unlock P2PK ecash. The official source stresses that this key is not the user's Nostr private key and must not be associated with it.
Kind 7375 token events store encrypted unspent proofs for a mint and unit. They may include del references to token events destroyed during a state transition. When proofs are spent, the old token event needs to be deleted with NIP-09 and, when change remains, a new token event needs to be created.
Kind 7376 spending history is optional and informational. It records in/out direction, amount, unit and created or destroyed token references. That history helps users understand wallet movement, but it is not the source of spend authority.
Cashu wallet state arrived with Nutzaps
Pablo Fernandez added the visible Cashu wallet and Nutzaps work in October 2024. Early 2025 edits refined state transitions, addressable terminology and simplified NIP-60/61 together. In October 2025, Rob Woodgate added the base unit tag to NutZap-related events, which also matters for wallet accounting.
The history shows that NIP-60 and NIP-61 is best read together. One stores the wallet state. The other describes how someone sends a Cashu payment as a Nostr event.
Cashu itself is an active ecosystem outside Nostr, so NIP-60's quality depends on how well Nostr clients respect Cashu proof semantics, mint choice and backup behavior.
A NIP-60 wallet is only as safe as its state transitions
Implementers need to be strict about proof state. Spending a proof must remove or roll over the old token event. Change must be represented in a new token event. Deletion events need the correct k tag so clients can follow transitions.
Nutsack presents itself as a modern Cashu wallet for iOS implementing NIP-60 and NIP-61. The awesome-cashu inventory notes wallet work around NIP-60/61 support. rust-nostr exposes a NIP-60 module. Those sources show that the standard is not theoretical.
The user-facing version needs to be simple: choose trusted mints, back up wallet state, see balance, redeem Nutzaps and move between clients. The hidden part is the proof ledger, and it has to be exact.
Ecash portability can make loss portable too
Cashu proofs are bearer instruments. Bad synchronization, duplicate spending, broken deletion handling or lost encrypted state can lose funds. NIP-60 clients need careful local and relay-state reconciliation.
There is also privacy risk. Wallet state is encrypted, but relay timing, mint choices and event patterns can still reveal habits. Clients need to avoid making balances or transaction history visible unless the user chooses it.
Read NIP-60 in the wild
NIP-60 describes Cashu wallet state on Nostr. That means ecash proofs, mints and wallet metadata enter the same portable identity world as notes and profiles.
This is real money risk. Ecash is bearer value, so backup, encryption, mint trust, double-spend handling and recovery language need to be explicit before a balance looks friendly.
What changes when you actually use it
For you, NIP-60: Cashu Wallet is felt at the moment value moves or appears to move. The interface may show a zap, offer, wallet connection, token, invoice or result, but the source terms kind 17375, kind 7375, kind 7376, kind 5, kind 10019, draft decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-60: Cashu Wallet means separating money truth from social display. Budgets, invoices, mints, wallet services, receipts and settlement need their own status language. A delightful payment animation is harmless only after custody, limits and revocation are legible.
What the official file makes concrete
The official file is organized around High-level flow, Wallet Event, Token Event, Spending History Event, Flow, Fetch wallet and token list, Fetch proofs, Spending token. Inspect kind 17375, kind 7375, kind 7376, kind 5, kind 10019, draft, kind:17375, kind:7375 because these are the pieces most likely to surface as product behavior. Read it beside NIP-61, NIP-44, NIP-09, NIP-65, NIP-40 before treating it as isolated.
NIP-60: Cashu Wallet needs sharper warnings than a normal social feature. Custody, invoices, receipts, budgets, mints and settlement determine whether money really moved.
Where it breaks
The failure mode in NIP-60: Cashu Wallet is believing the social signal more than the payment proof. A zap can be visible while settlement is incomplete, a wallet connection can outlive trust, a mint can fail, and a listing can look professional without escrow or reputation.
Where this appears outside the markdown
In the ecosystem, NIP-60: Cashu Wallet sits near wallets, Lightning, Cashu, offers, receipts, jobs, goals or marketplaces. These features are exciting because value becomes visible inside social context, but they are also unforgiving. A page about value has to separate the social object from the financial fact before the design turns trust into decoration.
The nearby-standard trap
The nearby-standard trap in NIP-60: Cashu Wallet is calling every money-adjacent event a payment. Zaps, wallet connections, Cashu proofs, nutzaps, offers, orders, goals and data jobs each prove different things. Read NIP-61, NIP-44, NIP-09, NIP-65, NIP-40 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-60: Cashu Wallet names the money state. It separates request, invoice, payment, receipt, token, mint, budget, listing, order and settlement. That is how a delightful wallet or marketplace surface stays honest.
What this page does not promise
NIP-60: Cashu Wallet does not turn a social signal into settled money by itself. A zap, wallet connection, listing, token, receipt or job request can be displayed beautifully while custody, settlement, refund, invoice expiry or mint risk remain unresolved. Read NIP-61, NIP-44, NIP-09, NIP-65, NIP-40 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-60: Cashu Wallet with the money state, not the animation. Identify whether kind 17375, kind 7375, kind 7376, kind 5, kind 10019, draft represent a request, permission, invoice, token, receipt or listing. Then read the nearby standards and source links so custody, settlement, budget and proof are not collapsed into one cheerful payment label.
Where the standard earns trust
The source links give you places to test the interpretation in public: Cashu, Awesome Cashu, Nutsack, rust-nostr NIP-60 module. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-60 source is the anchor for exact wording, and NIP-60 commit history shows how that wording moved over time. The strongest secondary clues here are Cashu, Awesome Cashu, Nutsack. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-60: Cashu Wallet: first the human promise, then kind 17375, kind 7375, kind 7376, kind 5, kind 10019, draft, then the implementation record, then the real-world failure case. That order keeps NIP-60 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What is being proven: a request, invoice, payment, receipt, token, listing, wallet permission, mint promise or job result?
- Who can spend, revoke, refund, censor or lose the funds if the service disappears?
- Does the product separate social visibility from financial settlement before you trust the flow?
What to verify before you rely on it
- Find
kind 17375,kind 7375,kind 7376,kind 5,kind 10019in the official file and check where the UI exposes the same concept. - Read NIP-61, NIP-44, NIP-09, NIP-65, NIP-40 as context before treating NIP-60 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-60: Cashu Wallet in that order: Official NIP-60 source for the current wording; NIP-60 commit history for the change record; Cashu, Awesome Cashu, Nutsack for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
