Chapter A3 - Payments
A3
Nostr Implementation Possibility - Hex № A3

payto: Payment Targets

One tag format that declares a user's payment addresses on any network or platform, from Bitcoin to Venmo.

1 Overview

People accept payments in many places. One user has a Bitcoin address, a Lightning address, and a PayPal account. Before this NIP, each network needed its own ad-hoc field or kind. This NIP standardizes how payment addresses are declared across any network or platform.

The mechanism is one tag: payto. Each payto tag names a payment type and an address on that type. A user lists these tags in a kind 10133 event. A client reads the tags and renders each address as a button or link.

The tag maps directly to the payto URI scheme of RFC-8905. A client that does not recognize a type can still render a generic payto:// link. Unknown types degrade, they do not break.

Hint!

Looking for native Nostr zaps over Lightning? That is a different chapter: NIP-57. This NIP is the address book. NIP-57 is the cash register.

2 The payto Tag

A payment target is one payto tag with exactly this structure:

Wire format - payto tag
["payto", <type>, <address>]
Tag element reference
PositionElementRule
1nameAlways the literal string "payto".
2typeThe payment type, for example "bitcoin" or "lightning". Always lowercase.
3addressThe address on that type. It can be an on-chain address, a username, or any platform identifier.

The NIP itself does not validate addresses. Clients may perform additional network- or platform-specific validation for recognized types. For example, a client may check a bitcoin address checksum before it renders a link.

3 The Payment List Event - Kind 10133

A user publishes the payto tags in an event of kind 10133. The content is empty. Each tag declares one payment target. One event can hold many targets on many networks.

Kind 10133 sits in the replaceable range of NIP-01 (10000-19999). A relay keeps only the latest payment list per pubkey. Publish a new event to update the whole list.

Tech Note

The source text never defines kind 10133 in a dedicated section. The kind appears only inside the example event and in one rendering sentence. The replaceable behavior above is implied by the NIP-01 kind range, not stated in this NIP. Also, the type list below is titled "Commonly Used Tags" in the source, but it lists types, not tag names.

4 Rendering Payment Links

For each payto tag in kind 10133 events, clients can render the payment address as a button or link. Build the link URI in two steps:

  1. If a specific URI scheme exists for the type, clients may use it. Examples: bitcoin:<address> or ethereum:<address>.
  2. Otherwise, fall back to the payto URI scheme defined by RFC-8905: payto://<type>/<address>.
payto tag [type, address] Client check scheme for type? Native URI bitcoin:addr payto URI payto://type/addr known fallback
Fig. A3-1 — Link builder. Known types get a native scheme. Every other type gets the RFC-8905 fallback.

5 Registered Payment Types

These types are in common use today. New widely deployed formats can be added to this list later. Remember: every type string is lowercase.

Commonly used types
TypePayment target
bip352Bitcoin silent payments.
bip353Bitcoin DNS addresses.
bitcoinBitcoin on-chain address.
cashmeCash App $-prefixed cashtag.
ethereumEthereum address.
lightningLightning address.
litecoinLitecoin address.
moneroMonero address.
nanoNano address.
paypalPayPal account.
revolutRevolut account.
solanaSolana address.
venmoVenmo account.
zcashZcash address.
Warning!

Do not drop tags with unknown types. A type outside this list is still valid. Render it with the payto:// fallback so the user can still copy or open it.

6 Worked Example

The event below declares three payment targets: a known type with a native scheme, a known type without one, and an unknown type. The content stays empty.

Payment list - kind 10133
{
  "pubkey": "afc93622eb4d79c0fb75e56e0c14553f7214b0a466abeba14cb38968c6755e6a",
  "kind": 10133,
  "content": "",
  "tags": [
    ["payto", "bitcoin", "bc1qxq66e0t8d7ugdecwnmv58e90tpry23nc84pg9k"],
    ["payto", "nano", "nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c"],
    ["payto", "unknowntype", "l7tbta5b9xze6ckkfc99uohzxd009b0r"]
  ],
  ...
}

A client turns those three tags into three links. The bitcoin type has its own URI scheme. The other two use the RFC-8905 fallback:

Rendered URIs
-- native scheme --
bitcoin:bc1qxq66e0t8d7ugdecwnmv58e90tpry23nc84pg9k
-- RFC-8905 fallback --
payto://nano/nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c
payto://unknowntype/l7tbta5b9xze6ckkfc99uohzxd009b0r

7 Version History

This NIP is young. It landed in one PR and got a full rewrite one day later:

  • 20262026-08-27fiatjaf rewrote the whole NIP. The spec was condensed to the single payto tag format, the kind 10133 example, and the RFC-8905 rendering rule.
  • Origin2026-08-26ATXMJ opened the original proposal: "payto: Payment Targets (RFC-8905)" (PR #2119).

Original Proposal - Credits

AuthorATXMJ
First commit2026-08-26 — “NIP-A3 payto: Payment Targets (RFC-8905)” (PR #2119)
Statusdraft optional
SourceA3.md on GitHub - full change history

8 See Also

  • NIP-01 — the event and tag model, and the replaceable kind range that covers 10133.
  • NIP-57 — Lightning zaps: actually sending sats inside Nostr, not just listing addresses.
  • NIP-05 — DNS-based identifiers; a sibling idea of the bip353 DNS payment type.
  • RFC-8905 — the payto URI scheme this NIP falls back to.