Skip to content

chore: simplify nip-47 #2210

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
vitorpamplona merged 1 commit into from
Feb 11, 2026
Merged

chore: simplify nip-47 #2210

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 3 additions & 97 deletions 47.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ Fundamentally NWC is communication between a **client** and **wallet service** b

4. Once the payment is complete the **wallet service** will send an encrypted `response` (kind 23195) to the **user** over the relay(s) in the URI.

5. The **wallet service** may send encrypted notifications (kind 23197 or 23196) of wallet events (such as a received payment) to the **client**.
5. The **wallet service** may send encrypted notifications (kind 23197) of wallet events (such as a received payment) to the **client**.

## Events

Expand Down Expand Up @@ -134,8 +134,6 @@ The content of notifications is encrypted with [NIP44](44.md) (or NIP-04 for leg
}
```

_Note on backwards-compatibility:_ If a **wallet service** supports both nip44 and nip04 for legacy client apps, it should publish both notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. It is up to the **client** to decide which event to listen to based on its supported encryption and declared supported encryption schemes of the **wallet service** in the `info` event.

### Error codes
- `RATE_LIMITED`: The client is sending commands too fast. It should retry in a few seconds.
- `NOT_IMPLEMENTED`: The command is not known or is intentionally not implemented.
Expand Down Expand Up @@ -207,42 +205,6 @@ Response:
Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.

### `multi_pay_invoice`

Description: Requests payment of multiple invoices.

Request:
```jsonc
{
"method": "multi_pay_invoice",
"params": {
"invoices": [
{"id":"4da52c32a1", "invoice": "lnbc1...", "amount": 123}, // bolt11 invoice and amount in msats, amount is optional
{"id":"3da52c32a1", "invoice": "lnbc50n1...", "metadata": {} }, // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
],
}
}
```

Response:

For every invoice in the request, a separate response event is sent. To differentiate between the responses, each
response event contains a `d` tag with the id of the invoice it is responding to; if no id was given, then the
payment hash of the invoice should be used.

```jsonc
{
"result_type": "multi_pay_invoice",
"result": {
"preimage": "0123456789abcdef...", // preimage of the payment
"fees_paid": 123, // value in msats, optional
}
}
```

Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.

### `pay_keysend`

Request:
Expand Down Expand Up @@ -277,44 +239,6 @@ Response:
Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.

### `multi_pay_keysend`

Description: Requests multiple keysend payments.

Has an array of keysends, these follow the same semantics as `pay_keysend`, just done in a batch

Request:
```jsonc
{
"method": "multi_pay_keysend",
"params": {
"keysends": [
{"id": "4c5b24a351", "pubkey": "03...", "amount": 123},
{"id": "3da52c32a1", "pubkey": "02...", "amount": 567, "preimage": "abc123..", "tlv_records": [{"type": 696969, "value": "77616c5f6872444873305242454d353736"}]},
],
}
}
```

Response:

For every keysend in the request, a separate response event is sent. To differentiate between the responses, each
response event contains a `d` tag with the id of the keysend it is responding to; if no id was given, then the
pubkey should be used.

```jsonc
{
"result_type": "multi_pay_keysend",
"result": {
"preimage": "0123456789abcdef...", // preimage of the payment
"fees_paid": 123, // value in msats, optional
}
}
```

Errors:
- `PAYMENT_FAILED`: The payment failed. This may be due to a timeout, exhausting all routes, insufficient capacity or similar.

### `make_invoice`

Request:
Expand Down Expand Up @@ -671,23 +595,6 @@ The negotiation works as follows.
1. The **wallet service** includes an `encryption` tag in the `info` event. This tag contains a space-separated list of encryption schemes that the **wallet service** supports (eg. `nip44_v2 nip04`)
2. The **client application** includes an `encryption` tag in each request event. This tag contains the encryption scheme which should be used for the request. The **client application** should always prefer nip44 if supported by the **wallet service**.

### Info event

First, the **wallet service** adds an `encryption` tag to its `info` event containing a space-separated list of encryption schemes it supports. For example,
if a wallet service supports nip44, but also allows backwards-compatibility to nip04 client applications, its `encryption` tag in the `info` event might look something like:

```jsonc
{
"kind": 13194,
"tags": [
["encryption", "nip44_v2 nip04"],
// ...
],
"content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions get_info",
// ...
}
```

When a **client application** establishes a connection, it should read the info event and look for the `encryption` tag.

**Absence of this tag implies that the wallet only supports nip04.**
Expand All @@ -714,7 +621,7 @@ If the **wallet service** does not support the specified encryption scheme, it w

### Notification events

As described above in the [Notifications](#notifications) section, if a **wallet service** supports both nip04 and nip44, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. If the **wallet service** only supports nip44, it should only publish kind 23197 events.
If a **wallet service** supports both nip04 and nip44, it should publish two notification events for each notification - kind 23196 encrypted with NIP-04, and kind 23197 encrypted with NIP-44. If the **wallet service** only supports nip44, it should only publish kind 23197 events.

The **client** should check the `encryption` tag in the `info` event to determine which encryption schemes the **wallet service** supports, and listen to the appropriate notification event.

Expand Down Expand Up @@ -785,6 +692,7 @@ Here are some properties that are recognized by some NWC clients:

* Calls `settle_hold_invoice` with the original preimage to release funds, or
* Calls `cancel_hold_invoice` with payment hash to abort.

### Deep-links

Wallet applications can register deeplinks in mobile systems to make it possible to create a linking UX that doesn't require the user scanning a QR code or pasting some code.
Expand All @@ -800,5 +708,3 @@ URI parameters:

Once a connection has been created by the wallet, it should be returned to the client by opening the callback with the following parameters
* `value` -- NWC pairing code (e.g. `nostr+walletconnect://...`)