a zap request with a comment loses its description_hash

[davotoula]

Observed: 2026-08-30, reproducible on demand at the time of writing.

Reported by: the operator of a self-hosted NWC wallet service that verifies, before storing it, that a client-supplied zap request actually belongs to the invoice its node paid.

Summary

The callback mints a correct NIP-57 zap invoice when the zap request's content is empty, and an ordinary comment invoice with no description_hash at all when content is non-empty. The zap request is otherwise identical: same signer, same p, amount, relays and lnurl tags, same amount parameter.

Since NIP-57 binds a zap receipt to its invoice through description_hash = sha256(zap request JSON), an invoice without that field cannot carry a verifiable zap. The commitment is simply absent.

Reproduction

Two requests differing only in the content field of the zap request.

PK=...   # the address owner
LN=lnurl...
CB=https://getalby.com/lnurlp/.../callback

# A — comment-free zap request (content: "")
ZR=$(nak event -k 9734 -c "" -t p=$PK -t amount=28000 -t relays=wss://nos.lol -t lnurl=$LN --sec <key>)
curl -s "$CB?amount=28000&nostr=$(urlencode "$ZR")"

# B — identical, except content: "Nice test"
ZR=$(nak event -k 9734 -c "Nice test" -t p=$PK -t amount=21000 -t relays=wss://nos.lol -t lnurl=$LN --sec <key>)
curl -s "$CB?amount=21000&nostr=$(urlencode "$ZR")"

Decode each returned pr with lncli decodepayreq or any bolt11 decoder:

A — content ""            description:      ''
                          description_hash: 01d653fcf76be1f0ed0ebb5fdac84e38dfd17a22f4c099eb13ae0f339d28282f
                          sha256(zap request bytes sent):
                                            01d653fcf76be1f0ed0ebb5fdac84e38dfd17a22f4c099eb13ae0f339d28282f
                          -> CORRECT: commits to the exact zap request

B — content "Nice test"   description:      'Nice test'
                          description_hash: (absent)
                          -> the comment was lifted out of the zap request and used as the
                             invoice memo, and no commitment was made

Note that no comment query parameter was sent in either case. The text came only from the zap request's own content, so the fallback is triggered by parsing the zap request, not by the LUD-12 comment parameter.

The endpoint advertises zap support in both cases:

allowsNostr: true
nostrPubkey: ...
commentAllowed: 255

Expected

Per NIP-57, when a valid nostr parameter is supplied, the invoice's description_hash must be the SHA-256 of that zap request JSON, whether or not the request carries content. A comment in a zap request is normal: it is how a zap's message is conveyed, and it ends up in the zap receipt's content.

Impact

Zaps carrying a message cannot produce a verifiable zap receipt for addresses on this service. Anything that checks the binding must reject them; anything that does not check is accepting an unbound claim.

It is silent. The payment succeeds, the invoice looks normal, and only a verifier notices.

Zaps without a message are unaffected, which makes the failure look intermittent and user-specific. In our case it presented as "the default zap works, but a zap with a comment shows no sender".

How it was found

Five real payments from a phone wallet to Alby-hosted addresses, all with comments, were refused by our node because the invoice had nothing to bind the zap request to. Isolating the variable took the two curl calls above: it is the comment, not the pairing, the client, or the amount.

[davotoula]

Follow-up: I've isolated the trigger, and it is not the LUD-12 comment query parameter — it is the zap request's own content.

Method: one signed kind 9734 zap request, serialised once and reused byte-for-byte across rows A–C, so the only variable is the query parameter. Row D uses a second request identical except for empty content. Same address, same amount (21,000 msat) throughout. Hashes are taken over the decoded JSON, not the percent-encoded query value.

Row	zap request content	comment=	resulting invoice
A	non-empty	parameter absent	description = the zap request's content, no description_hash
B	same bytes	non-empty	same
C	same bytes	empty	same
D	empty	empty	description_hash = SHA-256 of the exact zap request — correct

Three things follow.

Row A is the important one. No comment parameter was sent at all, and the invoice still came back with no commitment, carrying the zap request's content as its description. So the callback is lifting the message out of the zap request itself and routing to the comment-invoice path on that basis.

There is no client-side workaround. A client cannot avoid this by omitting comment=, because row A already omits it. Any zap request carrying a message is unbindable against invoices from this endpoint, by any client, by any means.

It is not a LUD-06 fallback. In none of the failing rows did the invoice carry a description_hash matching the SHA-256 of the endpoint's own metadata string, which is what an ordinary LNURL-pay invoice would commit to. The commitment is absent rather than wrong.

Row D is included to show the compliant path still works: a zap request with empty content produces an invoice committing to its exact bytes, even with an empty comment= present. So zaps without a message are unaffected, which is why this presents as intermittent — the default zap works and only a zap with a message loses its sender.

[Tyagiquamar]

I'd like to take this if it's still available. I checked current master and zaps with non-empty content still appear to route to a comment invoice without description_hash. I plan to add a focused NIP-57 regression first and keep the change scoped to the LNURL callback path. Is anyone already working on this?

[rolznz]

I think this is a problem with the zaps spec that it relies on the description_hash, since it's not always available (for multiple wallet backends if I remember correctly).

[Tyagiquamar]

Thanks, that makes sense regarding backend limitations.

From the current NIP-57 wording though, my understanding is that once the endpoint advertises Nostr zap support and accepts a valid nostr parameter, the returned invoice is expected to commit to the zap request via description_hash, regardless of whether the zap request has non-empty content.

The part that seemed unexpected here is that the same backend does produce the description-hash invoice when content is empty, but silently switches to a normal description invoice when content is non-empty.

If some backends cannot support description-hash invoices, would the preferred behavior here be to reject/disable zap support for those backends rather than return an invoice that can no longer be verified as the requested zap? Happy to work on whichever behavior you think makes sense for Hub.

[davotoula]

Agreed the spec leans entirely on description_hash, and that a backend which cannot mint one cannot do zaps. But that is not what this issue shows: row D is the same backend returning a correct description-hash invoice when content is empty, so the capability is there, and the switch to a plain comment invoice happens on the content field, not on the backend. Two behaviours would each be fine: always commit to the zap request when a valid nostr param is present, and let the comment ride in the receipt as NIP-57 intends; or, for a backend that truly cannot, stop advertising allowsNostr so clients fall back to a plain payment. Returning an invoice that advertises a zap and cannot be bound to one is the case worth removing. Tyagiquamar's scoped fix on the callback path sounds right to me.