NIP-87: Cashu and Fedimint Discoverability
Mint discovery is a trust problem, not a search box
Cashu and Fedimint mints are powerful because they can make small payments private and smooth. They are also trust-bearing infrastructure. A user needs to know which mint exists, which network it serves, what capabilities it supports and whose recommendation they believe.
NIP-87 uses Nostr for that discovery layer. Mint operators can publish mint information events. Users can publish recommendation events. Another user can query recommendations, follow the a tag to the mint information event and decide whether that social trust is enough.
The standard fits Nostr well because it does not claim mint discovery is neutral. It makes recommendations signed, relay-discoverable and updateable.
Three event kinds for recommendations and mint announcements
Recommendation events use kind 38000. The k tag says whether the recommendation points to a Cashu or Fedimint mint, u can hold URLs or invite codes, and a tags point to the mint information event.
Cashu mints publish kind 38172 events. They needs to include a URL, supported NUTs and a network tag such as mainnet, testnet, signet or regtest. Fedimint mints publish kind 38173 events and can include invite codes and capability metadata.
Because recommendations are parameterized replaceable events, a user can change their recommendation later instead of leaving stale mint advice behind.
benthecarman brought ecash discovery into the NIP set
benthecarman added NIP-87 in July 2025 through PR #1110. The file was later cleaned up and renamed for clarity in June 2026. Release notes from Amethyst in 2026 mention NIP-87 event types, which is a useful signal that client-side support is moving beyond paper.
NIP-87 also sits beside NIP-60 and NIP-61. NIP-60 describes relay-backed Cashu wallet records, while NIP-87 answers a different question: how do users discover and recommend mints in the first place?
The answer is intentionally social. A mint is not trustworthy because it appears in a list; it is more legible because someone signed a recommendation.
Wallets needs to show the recommender, not only the mint
A wallet or discovery client needs to display the mint's URL, network, supported features, age, relay hints and who recommended it. If several trusted contacts recommend the same mint, that is useful. If only an unknown pubkey recommends it, that needs to look different.
Mint operators needs to keep their information events current. A stale NUT list or dead URL can mislead wallets and cause failed user flows.
NIP-87 does not replace due diligence. It gives wallets a portable way to ask, who in your graph recommends this mint?
Recommendations can become reputation theater
A signed recommendation does not guarantee solvency, custody quality or privacy. It only says a key made a claim. Wallet UIs needs to avoid turning recommendations into a false safety badge.
Mint URLs and invite codes can also be sensitive. Clients need to think carefully before making a user's mint preferences too visible.
Read NIP-87 in the wild
NIP-87 helps discover Cashu and Fedimint services. It connects wallet-adjacent infrastructure to the Nostr discovery layer so users and apps can find value systems more easily.
Discovery is not endorsement. A listed mint or federation still carries custody, availability and trust risk. Show what was discovered and what still needs independent judgment.
What changes when you actually use it
For you, NIP-87: Cashu and Fedimint Discoverability 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 38173, kind 38172, kind 38000, kind 0, draft, kind:38173 decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-87: Cashu and Fedimint Discoverability 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 Rationale, Parties involved, Events, Recommendation event, Mint Information, Example, User A recommends some mints, User B finds a mint. Inspect kind 38173, kind 38172, kind 38000, kind 0, draft, kind:38173, kind:38172, kind:38000 because these are the pieces most likely to surface as product behavior. Read it beside NIP-01 before treating it as isolated.
NIP-87: Cashu and Fedimint Discoverability 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-87: Cashu and Fedimint Discoverability 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-87: Cashu and Fedimint Discoverability 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-87: Cashu and Fedimint Discoverability 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-01 before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-87: Cashu and Fedimint Discoverability 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-87: Cashu and Fedimint Discoverability 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-01 before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-87: Cashu and Fedimint Discoverability with the money state, not the animation. Identify whether kind 38173, kind 38172, kind 38000, kind 0, draft, kind:38173 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: nips.nostr.com NIP-87, Net::Nostr::MintDiscovery, NIP-60 Cashu Wallets, Amethyst release note. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-87 source is the anchor for exact wording, and NIP-87 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-87, Net::Nostr::MintDiscovery, NIP-60 Cashu Wallets. 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-87: Cashu and Fedimint Discoverability: first the human promise, then kind 38173, kind 38172, kind 38000, kind 0, draft, kind:38173, then the implementation record, then the real-world failure case. That order keeps NIP-87 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 38173,kind 38172,kind 38000,kind 0,draftin the official file and check where the UI exposes the same concept. - Read NIP-01 as context before treating NIP-87 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-87: Cashu and Fedimint Discoverability in that order: Official NIP-87 source for the current wording; NIP-87 commit history for the change record; nips.nostr.com NIP-87, Net::Nostr::MintDiscovery, NIP-60 Cashu Wallets 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.
