feat(nut-18, nut-26): add preferred_mints to payment requests #355

2026-03-26T14:50:14Z

a1denvalu3 commented

2026-03-26 14:50:14 +00:00

(Migrated from github.com)

Summary

Introduces preferred_mints field (pm in JSON, 0x09 in TLV) to payment requests in NUT-18 and NUT-26.
This allows the originator of the request to specify mints they support.
Paying wallets can optionally use these preferred mints for faster and cheaper transactions without bridging through the lightning network.

## Summary - Introduces `preferred_mints` field (`pm` in JSON, `0x09` in TLV) to payment requests in NUT-18 and NUT-26. - This allows the originator of the request to specify mints they support. - Paying wallets can optionally use these preferred mints for faster and cheaper transactions without bridging through the lightning network.

thesimplekid (Migrated from github.com) reviewed

2026-03-26 15:00:04 +00:00

18.md

					
				@ -36,7 +38,9 @@ Here, the fields are

				- `a`: The amount of the requested payment

Should we be more clear on when to use mints vs preferred mints. If mints is defined then only tokens from those mints will be accepted and receive wallets SHOULD not redeem proofs of a mint not in the list. While if preferred mints is defined any mints tokens will be accepted and they will be melted.

robwoodgate (Migrated from github.com) reviewed

2026-03-26 15:02:15 +00:00

18.md

					
				@ -36,7 +38,9 @@ Here, the fields are

				- `a`: The amount of the requested payment

I was just writing the same comment. it's not clear to me when to use m vs pm

I was just writing the same comment. it's not clear to me when to use `m` vs `pm`

robwoodgate (Migrated from github.com) reviewed

2026-03-26 15:58:42 +00:00

18.md

Maybe better to put the onus on the sender? And is it only a SHOULD, or should it be a MUST?
What happens if the sender sends proofs from a different mint?

- `m`: A set of mints from which the payment is requested. If this field is defined, the sender SHOULD only send proofs from these mints.

Maybe better to put the onus on the sender? And is it only a SHOULD, or should it be a MUST? What happens if the sender sends proofs from a different mint? ```suggestion - `m`: A set of mints from which the payment is requested. If this field is defined, the sender SHOULD only send proofs from these mints. ```

realmeylisdev commented

2026-04-24 14:35:27 +00:00

(Migrated from github.com)

Hi — this is useful, thanks. Following my comment on #357 earlier today, I'm engaging from a wallet-implementer angle (Flutter bindings in cdk-flutter).

One small gap in the current text: is the pm array ordered?

NUT-18's t (Transport) field is explicitly spec'd as "can be multiple, sorted by preference". The proposed pm says "preferred mints the receiver supports" but doesn't state whether the array order conveys ranking. Since "preferred" implies a relative preference, senders will inevitably start treating the array as a priority list — and without a canonical answer in the spec, implementations will diverge (alphabetical, HashSet iteration order, insertion order, etc.).

Suggested small wording, modeled on t:

pm: A set of preferred mints the receiver supports, sorted by preference. If this field is defined, the receiver will accept proofs from any mint but prefers these mints for faster and cheaper transactions. …

This gives the sender a deterministic selection heuristic when the wallet has balance at multiple mints in the list.

Orthogonal to the m vs pm clarification @thesimplekid and @robwoodgate are discussing above — happy to submit this as a small editorial follow-up PR if it's a useful direction.

Hi — this is useful, thanks. Following my comment on #357 earlier today, I'm engaging from a wallet-implementer angle (Flutter bindings in `cdk-flutter`). One small gap in the current text: **is the `pm` array ordered?** NUT-18's `t` (Transport) field is explicitly spec'd as "can be multiple, **sorted by preference**". The proposed `pm` says "preferred mints the receiver supports" but doesn't state whether the array order conveys ranking. Since "preferred" implies a relative preference, senders will inevitably start treating the array as a priority list — and without a canonical answer in the spec, implementations will diverge (alphabetical, HashSet iteration order, insertion order, etc.). Suggested small wording, modeled on `t`: > `pm`: A set of preferred mints the receiver supports, **sorted by preference**. If this field is defined, the receiver will accept proofs from any mint but prefers these mints for faster and cheaper transactions. … This gives the sender a deterministic selection heuristic when the wallet has balance at multiple mints in the list. Orthogonal to the `m` vs `pm` clarification @thesimplekid and @robwoodgate are discussing above — happy to submit this as a small editorial follow-up PR if it's a useful direction.

robwoodgate commented

2026-05-27 15:45:27 +00:00

(Migrated from github.com)

I have cherry-picked the commits from this PR into https://github.com/cashubtc/nuts/pull/381, which also adds an "extra fee" field for non preferred mint payments.