Wallets, Zaps and Value Flow: Reading Money Standards Before You Click
A deep guide to Nostr Wallet Connect, Lightning zaps, Cashu wallets, Nutzaps, marketplaces, data vending machines, goals, payment requests and value-for-value.
Why this part of the NIP map matters
Money changes the standard. A bad timeline bug is annoying. A bad wallet permission, zap receipt, Cashu proof, payment request or marketplace listing can cost someone real value. That is why value-related NIPs need a slower reading habit than ordinary social features.
Nostr made Lightning payments socially visible through zaps, but zaps are only one part of the value layer. Wallet Connect lets apps request wallet actions without becoming wallets. Cashu standards bring ecash and mint risk into the room. Marketplaces and classified listings describe offers. Data vending machines describe work requests and results. Goals, payments and peer-to-peer orders turn social identity into economic context.
The point is not to make every money standard sound exciting. The point is to help you slow down before value moves. Zaps, wallet connections, ecash tokens, marketplace events and data-vending jobs are all different kinds of trust boundary.
The practical question is always the same: who controls the funds, what exactly was requested, what proof exists, which relay or service carried the event, and how do you revoke or recover when the app disappears?
The mental model
Zaps are social payment receipts. They prove something about a Lightning invoice and a signed zap request, but they do not prove every social meaning a feed may attach to them.
Nostr Wallet Connect is a permission system. It is powerful because an app can ask a wallet to act; it is risky when budgets, scopes and revocation are vague.
Cashu changes custody and recovery questions. A token can behave like bearer value, so backups, mint trust and proof handling matter.
Marketplaces start with listings, not trust. An offer is not escrow, dispute resolution or reputation by itself.
Value standards should be tested with tiny amounts, visible receipts and a clear exit path before you build a business process around them.
Read this topic with one hand on the protocol and one hand on the product. The protocol tells you the shared format. The product tells you what a person actually sees, approves, loses, recovers or can take elsewhere. Both are necessary. One without the other creates either abstract standards talk or a pretty interface with no durable proof underneath.
Use the source links as proof, not as decoration. A useful NIP explanation gives you the mental model first, then sends you to the official markdown when exact fields, status notes, examples or implementation details matter.
Money makes the trust boundary immediate
A note can be embarrassing if it goes wrong. A wallet action can cost money. That is why NIP-47, NIP-57, Cashu, marketplace events and data-vending flows need slower reading than a social feature. When value moves, the first question is custody. Who controls the funds before the click, during the click and after the click? A beautiful payment surface can still hide a custodial service, a fragile node, a confusing spending budget or a recovery path nobody tested.
Zaps are often described as tips, but the standard is more interesting than the word tip. A zap carries a social payment signal: a signed request, a Lightning invoice, a receipt and a visible relationship between a payer, recipient, event and amount. That makes money part of the conversation. It also creates interpretation risk. A receipt proves a payment flow happened. It does not automatically prove endorsement, identity, absence of refund, absence of fraud or the social meaning a feed may attach to it.
Nostr Wallet Connect changes the trust room again. Instead of every app becoming a wallet, an app can request permissions from a wallet service through a connection string. That can be excellent product design when budgets, methods, relay choices and revocation are clear. It can be dangerous when an app receives broad authority and you forget the connection exists. The good interface makes the spending limit feel as visible as the pay button.
Cashu and ecash-style flows add bearer-token logic to the map. A token can be useful for small payments, privacy patterns and offline-ish transfers, but custody and mint trust have to be explained. If a mint disappears, if proofs are lost, if backups fail or if a token is pasted into the wrong place, the protocol story becomes personal very quickly. Ecash is not a magic privacy wand. It is a different set of tradeoffs.
Receipts, budgets and recovery are product features
A serious wallet page should not stop at whether a product supports zaps. It should explain receipts, invoices, callbacks, failure states and what you see when a payment fails. Does the zap request match the event? Does the receipt arrive through relays the client actually reads? Does the app distinguish paid, pending and failed states? Can you inspect what happened without trusting a screenshot?
Budgets are the humane side of programmable payments. NWC is powerful because a product can ask to pay invoices without taking the whole wallet. But a budget that is hidden in settings is not enough. You need to see which app has permission, which methods are allowed, which relay carries the request, how much can be spent and how to revoke the connection quickly. Permission design is the wallet's moderation layer.
Recovery is where many wallet products get quiet. Can you restore from seed words, a Lightning node backup, a Cashu token backup, an account login, a remote service or nothing at all? Are receipts recoverable? Are pending tokens recoverable? Can you move from one wallet product to another without losing the social value attached to payments? Nostr makes payment signals public, but money itself still lives in systems with their own rules.
The best wallet writing also separates product categories. A browser extension, an NWC service, a Lightning wallet, a Cashu wallet, a node manager, a merchant checkout tool and a creator monetization surface may all sit under the wallet umbrella. They do not have the same risk. The hub should help you choose the category before the brand.
What to inspect before you connect a wallet
Before you connect a wallet to a Nostr app, ask what the app can do without asking again. Can it pay any invoice, only invoices below a budget, only invoices matching a method, only invoices through a relay path, or only invoices you approve one by one? That difference should be visible before the first payment request.
Then check what proof stays behind. A zap receipt, a payment request, a Cashu token, an NWC command and a marketplace order are different records. Some are public social signals. Some are wallet-side history. Some are bearer instruments. Some are relay events that may disappear. If you cannot tell which proof exists, you cannot audit the payment later.
Finally, rehearse revocation. Disconnect the app, lower a budget, rotate a connection, restore the wallet and test with a tiny amount before relying on the flow for a creator business, marketplace or automated tool. The best Nostr money products make this boring. That is a compliment.
The money layer changes social behavior
Zaps changed Nostr culture because money became part of public conversation. A useful reply could earn sats. A live stream could receive a visible reward. A creator could test value-for-value without asking a platform for permission. That energy is real, but it also means payment signals become social signals. A wallet page should explain both sides.
Public payments can encourage generosity, but they can also distort attention. Large zaps may look like endorsement. Repeated tiny zaps may look like spam. A receipt may become reputation. A leaderboard may become pressure. The protocol can carry the signal; the product decides how loudly it displays it.
Wallet permissions also change how apps are designed. Once an app can request payments safely, commerce, subscriptions, bounties, data jobs and creator tools become easier to imagine. The danger is that convenience makes you approve permissions you do not understand. Good NWC design slows the moment down just enough.
The best Nostr money pages therefore explain the loop: identity signs the request, wallet policy approves or rejects it, Lightning or ecash moves value, relays carry receipts or commands, and clients decide how visible the result becomes. If any part of that loop is hidden, the feature may still work, but you do not really understand the money path.
Small amounts are the safety ritual
The most useful wallet habit is almost boring: test with tiny amounts first. Send one small zap. Revoke one NWC connection. Restore one wallet. Export one receipt trail. Try one Cashu token you can afford to lose. This habit turns abstract custody warnings into muscle memory before real money, reputation or business process depends on the tool.
That ritual also reveals product honesty. A wallet that makes revocation hard, hides budgets, blurs custody, loses receipts or cannot explain recovery is telling you something. Listen before the amounts get larger.
The NIP pages in this topic
Nostr Wallet Connect
NIP-47 is Nostr Wallet Connect: a permissioned bridge between apps and wallets. It needs budgets, scopes and revocation to stay safe.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, NIP-47 info event because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-44, NIP-57.
Lightning Zaps
NIP-57 is the zap standard: Lightning value becomes a signed social receipt attached to a person, note or addressable object.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 9734, zap request, zap receipt, zap, nostrPubkey, relays because these are the terms that usually surface as product behavior. Nearby standards: NIP-23, NIP-01.
Nostr Marketplace (for resilient marketplaces
Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch id, tags, content, lnurl, naddr because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-19.
Cashu Wallet
A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 17375, kind 7375, kind 7376, kind 5, kind 10019, kind:17375 because these are the terms that usually surface as product behavior. Nearby standards: NIP-61, NIP-44, NIP-09, NIP-65, NIP-40.
Nutzaps
A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 10019, kind 9321, kind 7376, event-id-1, kind:10019, kind:9321 because these are the terms that usually surface as product behavior. Nearby standards: NIP-60, NIP-65.
Peer-to-peer Order events
Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there's not enough assets available for trading. If we combine all these individual solutions into one big.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch signet, liquid, name, expiration, <tag>, [tag] because these are the terms that usually surface as product behavior. Nearby standards: NIP-40.
Zap Goals
This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 9041, kind:9041, .content, amount, relays, closed_at because these are the terms that usually surface as product behavior.
Cashu and Fedimint Discoverability
This NIP describes kind:38173, kind:38172 and kind:38000: a way to discover ecash mints, their capabilities, and people who recommend them.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 38173, kind 38172, kind 38000, kind 0, kind:38173, kind:38172 because these are the terms that usually surface as product behavior. Nearby standards: NIP-01.
Data Vending Machines
This NIP defines the interaction between customers and Service Providers for performing on-demand computation. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5 because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-89.
Classified Listings
This NIP defines kind:30402: an addressable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. Watch kind 30402, kind 30403, kind:30402, kind:30403, .content, .pubkey because these are the terms that usually surface as product behavior. Nearby standards: NIP-15, NIP-23, NIP-58.
Deep reading: where the details become product behavior
NIP-47: Nostr Wallet Connect
NIP-47 is Nostr Wallet Connect: a permissioned bridge between apps and wallets. It needs budgets, scopes and revocation to stay safe.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 23194, kind 23195, kind 23197, kind 23196, kind 9734, NIP-47 info event, NIP-47 request, NIP-47 notification event. It also touches NIP-04, NIP-44, NIP-57, so do not read it as an island.
The source structure points you toward Rationale, Terms, Theory of Operation, Events. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-57: Lightning Zaps
NIP-57 is the zap standard: Lightning value becomes a signed social receipt attached to a person, note or addressable object.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 9734, zap request, zap receipt, zap, nostrPubkey, relays, content. It also touches NIP-23, NIP-01, so do not read it as an island.
The source structure points you toward Protocol flow, Reference and examples, Appendix A: Zap Request Event, Appendix B: Zap Request HTTP Request. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-15: Nostr Marketplace (for resilient marketplaces
Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around id, tags, content, lnurl, naddr. It also touches NIP-04, NIP-19, so do not read it as an island.
The source structure points you toward Terms, Nostr Marketplace Clients, Merchant admin, Marketplace. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-60: Cashu Wallet
A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 17375, kind 7375, kind 7376, kind 5, kind 10019, kind:17375, kind:7375, kind:7376. It also touches NIP-61, NIP-44, NIP-09, NIP-65, NIP-40, so do not read it as an island.
The source structure points you toward High-level flow, Wallet Event, Token Event, Spending History Event. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-61: Nutzaps
A Nutzap is a P2PK Cashu token in which the payment itself is the receipt.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 10019, kind 9321, kind 7376, event-id-1, kind:10019, kind:9321, relay, pubkey. It also touches NIP-60, NIP-65, so do not read it as an island.
The source structure points you toward High-level flow, Alice nutzaps Bob, Bob receives the nutzap, Nutzap informational event. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-69: Peer-to-peer Order events
Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there's not enough assets available for trading. If we combine all these individual solutions into one big.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around signet, liquid, name, expiration, <tag>, [tag]. It also touches NIP-40, so do not read it as an island.
The source structure points you toward Abstract, The event, Tags, Implementations. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-75: Zap Goals
This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 9041, kind:9041, .content, amount, relays, closed_at, zap.
The source structure points you toward Nostr Event, Client behavior, Use cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-87: Cashu and Fedimint Discoverability
This NIP describes kind:38173, kind:38172 and kind:38000: a way to discover ecash mints, their capabilities, and people who recommend them.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 38173, kind 38172, kind 38000, kind 0, kind:38173, kind:38172, kind:38000. It also touches NIP-01, so do not read it as an island.
The source structure points you toward Rationale, Parties involved, Events, Recommendation event. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-90: Data Vending Machines
This NIP defines the interaction between customers and Service Providers for performing on-demand computation.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 5001, kind 6001, kind 5000, kind 6000, kind 7000, kind 5, kind:5001, kind:6001. It also touches NIP-04, NIP-89, so do not read it as an island.
The source structure points you toward Kinds, Rationale, Actors, Job request (kind:5000-5999). That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-99: Classified Listings
This NIP defines kind:30402: an addressable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
Ask who controls funds, which permission or receipt is being signed, what can be revoked and what proof remains after the payment path breaks. In the official file, slow down around kind 30402, kind 30403, kind:30402, kind:30403, .content, .pubkey, [ "price", "<number>", "<currency>", "<frequency>" ], "<frequency>". It also touches NIP-15, NIP-23, NIP-58, so do not read it as an island.
The source structure points you toward Draft / Inactive Listings, Content, Author, Metadata. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
What to check before you trust a product claim
Start with the most concrete promise. Does the feature claim portable identity, encrypted messaging, relay discovery, zaps, wallet permissions, long-form publishing, moderation, search or application data? Name the promise before you open the source. Otherwise every NIP starts to look like background reading.
Open the official markdown next. Look for required fields, event kinds, tags, relay messages, status warnings and examples. Do not stop at the title. Many Nostr mistakes happen because a product advertises a NIP number while ignoring the boring edge case that actually protects the user.
Then test another implementation. If the event, payment, list, message, article, badge or relay behavior only works inside one product, the feature may still be useful, but it is not yet a strong portability claim. The second implementation is where the standard stops being a slogan.
Finally, check the risk class. Keys, private messages, money, storage, moderation and identity need more caution than a playful app format. A product can be young and promising, but the page should not ask you to trust it like a mature standard when the source trail is thin.
How this area usually fails
The first failure is overclaiming. A client says it supports a NIP, but it supports only the easiest happy path. That may be enough for a demo and not enough for real use.
The second failure is hidden custody. The app feels convenient because it quietly holds the key, routes the wallet, chooses relays or stores media in a way that makes leaving hard. Nostr is most interesting when those boundaries are visible.
The third failure is stale source material. A guide, blog post or old archive page may describe a version of the ecosystem that changed. The official repository and active implementations matter because Nostr standards are living documents.
The fourth failure is social flattening. Reports, badges, zaps, follows, labels and community events are not neutral numbers. They are signed social signals. You need to know who produced them, who displays them and what the product does with them.
The fifth failure is pretending the protocol solves product judgment. A NIP can define a format. It cannot force a client to explain it well, moderate fairly, store files forever or make a wallet prompt humane. Good pages keep that distinction clear.
Where to go next
The common thread is that a NIP is not a magic wand. It gives independent software a shared object, permission, message, tag, filter or social signal. The product still has to explain what it does with that shared shape.
If you are new to the topic, read the cards first and open only the NIP that matches your immediate question. If you are building, read the official markdown and test against more than one implementation. If you are evaluating a product, ask which parts travel with your key and which parts stay inside the product.
That is the difference between a useful NIP atlas and a numbered archive. The archive tells you that a document exists. The Wissenslexikon tells you why the document changes the way Nostr feels in your hands.
When a NIP touches keys, money, private messages, moderation or storage, slow down. Those are not decorative protocol topics. They decide who can sign, who can pay, who can read, who can hide, who can recover and who can leave.
The best Nostr product writing stays close to those consequences. It does not bury you in acronym soup, and it does not pretend every standard is equally mature. It tells you what you can do next, what you should verify, and where trust enters the room.
Direct sources
Use these sources to verify the text, not as decoration. The official repository is the canonical source; mirrors, guides and project pages help you see how the standard is explained or implemented elsewhere.