NIP-A3 Adds payto: Payment Targets to the NIPs Repository

The event

NIP-A3 defines kind:10133 and marks it replaceable. That follows from NIP-01, where any kind n with 10000 <= n < 20000 is replaceable: for each combination of pubkey and kind a relay must store only the latest event, and may discard older versions. A user therefore has one payment target list at a time, and publishing a new one supersedes the previous.

The content field is empty. Everything lives in tags:

["payto", "<type>", "<authority>", "<optional_extra_1>", "<optional_extra_2>", ...]

The first element is the literal string payto. The second is the payment type, such as bitcoin or lightning. The third is the authority, an address or a username, whose format depends on the payment system. Anything after that is reserved for future RFC-8905 features.

The forward compatibility rule is written out: clients must understand elements 0 through 2, and may ignore any additional elements.

Validation

type is restricted to lowercase letters, digits and hyphens. Types are case insensitive, and the specification says to normalize to lowercase. authority must be URL-safe, with special characters URL-encoded. Beyond that, clients may apply payment-system-specific validation for the types they recognize.

On the writing side the specification tells clients to accept types they do not know. Step 3 of its client implementation list says to optionally warn the user when a type is unrecognized, but to allow submission anyway. The example event in the specification carries a tag with the type unknowntype alongside bitcoin and nano.

Rendering

For each payto tag, a client should assemble the URI payto://<type>/<authority> and render it as a button or a link. That URI form is the point of the NIP. RFC-8905 already standardizes payto: as a URI scheme for payment target invocations, so NIP-A3 does not invent a new one; it carries the pieces needed to build one.

Recognized types render with an icon and a stylization. NIP-A3 ships a table of eight recommended types, each with a long name, a short name, a symbol and a reference link to the payment system's own brand material. The eight are bitcoin, cashme for Cash App, ethereum, lightning, monero, nano, revolut and venmo.

Unrecognized types are either ignored or given generic stylization, at the client's choice. When a profile lists several targets, a client may render the first, render all of them, or offer a dropdown selector. The specification does not pick one.

Relation to zaps

The implementation notes address the overlap with NIP-57. Lightning payments already have a path through nostr: the lud16 field in kind 0 profile metadata, decoded as an lnurl pay request. NIP-A3 says clients may use a payto tag of type lightning as an alternative to lud16 or as a complement to it, with a lightning address or an LNURL in the authority field.

The worked example shows both together: a kind 0 event carrying lud16, and a kind 10133 event carrying a lightning target with the same address plus a bitcoin target. Neither replaces the other. Nothing in the diff deprecates lud16 or changes NIP-57.

For implementers

Relays need nothing new. Kind 10133 sits inside the replaceable range they already handle, and payto is an ordinary tag.

For clients the reading side is small: subscribe to kind 10133 for the pubkeys on screen, parse the tags, build the URIs, render the result. The writing side needs a form with a type field and an authority field, the two validation rules above, and a replaceable publish.

NIP-A3 is marked optional and carries an author:atxmj line. It has no draft marker. Nothing forces a client to implement it, which the NIPs README says of the list as a whole.