Cashu and Fedimint Discoverability

1 Overview

An ecash mint is a server that issues bearer tokens backed by bitcoin. Two mint families matter here. A Cashu mint is a single server that users reach over HTTPS. A Fedimint federation is a group of servers that users join with an invite code. Before a wallet can hold ecash, it must pick a mint. Picking a mint is a trust decision.

This NIP turns that decision into Nostr events. It defines three kinds. A mint operator publishes kind:38172 (Cashu) or kind:38173 (Fedimint) to announce the mint and its capabilities. A user publishes kind:38000 to recommend a mint. Another user queries those recommendations, filters them by their follow list, and connects to a mint their friends trust.

The design mirrors NIP-89, which does the same for application handlers. Nostr's open, queryable event graph is the discovery index. No app store, no registry, no central list of mints.

2 Parties and Flow

Three actors take part in the workflow:

• Mint operator — announces the mint and its capabilities. Publishes kind:38173 or kind:38172 with connection details.
• User A — recommends an ecash mint. Publishes kind:38000.
• User B — seeks a recommendation. Queries for kind:38000, then, based on the results, queries for kind:38173/kind:38172.

3 The Recommendation Event

A user recommends a mint with a kind:38000 event. It is a parameterized-replaceable event: the user can edit the recommendation without creating a new event.

{
  "kind": 38000,
  "pubkey": <recommender-user-pubkey>,
  "tags": [
    ["k", "38173"],
    ["d", <d-identifier>],
    ["u", <recommended-fedimint-invite-code>],
    ["a", "38173:fedimint-pubkey:<d-identifier>", "wss://relay1"]
  ],
  "content": "I trust this mint with my life"
}

The content holds an optional review in free text.

4 Mint Announcements

Cashu mints — kind 38172

A Cashu mint should publish a kind:38172 event. It announces the mint's capabilities and how to connect. The rules:

• The u tag should be the URL of the Cashu mint.
• The event should list the nuts (Cashu protocol features) the mint supports.
• The d tag should be the mint's pubkey, as returned by the mint's /v1/info endpoint. Users can then query by pubkey and find the announcement.
• An n tag should state the network: mainnet, testnet, signet, or regtest.

{
  "kind": 38172,
  "pubkey": <application-pubkey>,
  "content": <optional-kind:0-style-metadata>,
  "tags": [
    ["d", <cashu mint pubkey>],
    ["u", "https://cashu.example.com"],
    ["nuts", "1,2,3,4,5,6,7"],
    ["n", "mainnet"]
  ]
}

Fedimints — kind 38173

A Fedimint should publish a kind:38173 event. The rules:

• List every known Fedimint invite code, one per u tag.
• List the modules the federation supports in a modules tag, for example lightning,wallet,mint.
• The d tag should be the federation id. Users can then query by federation id and find the announcement.
• An n tag should state the network: mainnet, testnet, signet, or regtest.

{
  "kind": 38173,
  "pubkey": <application-pubkey>,
  "content": <optional-kind:0-style-metadata>,
  "tags": [
    ["d", <federation-id>],
    ["u", "fed11abc.."],
    ["u", "fed11xyz.."],
    ["modules", "lightning,wallet,mint"],
    ["n", "signet"]
  ]
}

In both kinds, content is an optional stringified JSON object in the style of the NIP-01 kind-0 metadata. Use it when the pubkey that signs the announcement is not a normal user. If content is empty, clients should display the mint from the pubkey's own kind:0 event: name, picture, web, LUD16, and so on.

5 Worked Example

User A recommends some mints

User A uses a Cashu mint and a Fedimint. Their client publishes one recommendation that covers both, as in the source spec:

{
  "kind": 38000,
  "tags": [
    ["u", "fed11abc..", "fedimint"],
    ["u", "https://cashu.example.com", "cashu"],
    ["a", "38173:fedimint-pubkey:<d-identifier>", "wss://relay1", "fedimint"],
    ["a", "38172:cashu-mint-pubkey:<d-identifier>", "wss://relay2", "cashu"]
  ],
  ...
}

User B finds a mint

User B wants an ecash wallet and needs a mint. Their wallet client queries for kind:38000 recommendations, scoped to people User B follows:

-- query recommendations from the user's social graph --
→ ["REQ", "mints", {"kinds":[38000], "authors":[<user>, <users-contact-list>],
     "#k":["38173"]}]
← ["EVENT", "mints", {"kind":38000, "pubkey":"<user A>", "tags":[["k","38173"],
     ["d","<federation-id>"], …], "content":"I trust this mint with my life", …}]
← ["EOSE", "mints"]

-- fetch the announcement the recommendation points at --
→ ["REQ", "ann", {"kinds":[38173], "authors":["<fedimint-pubkey>"],
     "#d":["<federation-id>"]}]
← ["EVENT", "ann", {"kind":38173, "tags":[["d","<federation-id>"],
     ["u","fed11abc.."], ["modules","lightning,wallet,mint"], ["n","mainnet"]], …}]
← ["EOSE", "ann"]
-- User B joins the federation with invite code fed11abc.. --

User B follows User A, sees the kind:38000 event, and connects to the corresponding mint.

Alternative query, bypassing kind 38000

A client may skip recommendations and query announcements directly:

→ ["REQ", "direct", {"kinds":[38173], "authors":[...]}]

6 Version History

NIP-87 is young and has a short history. Notable changes, newest first:

• 20262026-06Renamed to "Cashu and Fedimint Discoverability" in fiatjaf's repo-wide title cleanup.
• 20252025-08Typo fixes.
• Origin2025-07benthecarman published the NIP as "Ecash Mint Discoverability" (PR #1110).

7 See Also

• NIP-01 — addressable events, the d tag, kind-0 metadata, and REQ filters used here.
• NIP-89 — recommended application handlers; the discovery pattern this NIP mirrors.
• NIP-60 — Cashu wallets on Nostr; where the discovered mint gets used.
• NIP-61 — nutzaps; P2PK Cashu payments between Nostr users.