Although Nostr came from the Bitcoin community and early support came from Bitcoiners, Nostr has never had a “native” currency.
From the beginning, the protocol has treated money the same way it treats everything else: as an event, published to relays, that clients choose whether and how to render.
What’s changed recently is which kinds of payment events those are.
Zaps had hit a ceiling, and nostr looks to expand beyond its Bitcoin-only roots! The protocol is evolving, and it has to if it is to reach users outside the Bitcoin ecosystem.
The newest addition, NIP A3 “payto: Payment Targets” is a small, new spec, but it represents the widest the door has ever been opened on Nostr: not just Lightning, not just Bitcoin, but essentially any payment rail a client is willing to display, including fiat services like PayPal, Venmo, and Revolut.
To give you an idea of what this change means for the ecosystem, let’s walk through how Nostr payments actually got here.
Phase One: Zaps, and the Lightning-Only Era
Nostr’s payment story starts with zaps, standardised under NIP-57. A zap is a Lightning payment tied to a specific note or profile, structured so the payment itself gets published back to relays as a verifiable receipt you could see publicly that a real Lightning payment had happened, attached to a real event, without needing to trust the sender’s word for it.
This improved the initial user experience of spamming Lightning invoices into chats, but it was also narrow by design. Zaps required a Lightning invoice, meaning the sender’s client had to fetch an invoice from the recipient’s Lightning node (or Lightning service) before it could even construct a payment.
That requirement was the whole bottleneck.
Not everyone can run their own Lightning node. Node uptime, channel liquidity management, inbound capacity none of that is something a casual Nostr user wants to deal with just to receive zaps on a post.
So the ecosystem refined the model: rather than needing a raw node, users adopted Lightning addresses, a friendlier, email-like format (name@domain) that resolves to an invoice automatically via a well-known web endpoint (LNURL-pay under the hood). This made zapping much easier for senders, but it just moved the infrastructure problem rather than solving it; someone still has to run the server behind that address.
In practice, that meant the overwhelming majority of Nostr users defaulted to custodial Lightning address providers: Wallet of Satoshi, Coinos, and Alby chief among them.
These services let anyone get a working Lightning address in minutes, with the provider running the actual node and custody infrastructure behind the scenes. It was a pragmatic trade-off usability now, custody risk later and it’s worth noting that Alby has since shifted toward a more non-custodial model, giving users more direct control over their keys and funds rather than fully outsourcing custody as it originally did.
Phase Two: Nutzaps and Cashu
The next evolution came from a different direction entirely: ecash. NIP-60 defines a Cashu wallet represented as Nostr events, meaning your unspent Cashu tokens can be stored and synced alongside your Nostr identity rather than living only in a separate app.
Building on that, NIP-61 nutzaps lets people zap using Cashu ecash tokens instead of a Lightning payment. Because Cashu tokens are bearer instruments issued by a mint, a nutzap can be sent directly as a token attached to the event itself, without needing an invoice round-trip. NIP-87 rounds this out by letting Cashu mints and Fedimints announce themselves on Nostr, so wallets and clients can discover which mints exist and route accordingly.
Nutzaps solved a genuinely different problem than Lightning addresses did they reduced the interactive back-and-forth of invoice generation, and they opened the door to a payment method with different privacy and custody characteristics (mint-based ecash rather than node-based Lightning).
But they were still, fundamentally, a Bitcoin-adjacent payment rail.
Phase Three: NIP A3 Blows the Door Open
NIP A3 doesn’t try to solve invoice friction or custody it solves a much more basic problem: how do you even declare where you’d like to be paid, on any network, without the protocol needing to know or care what that network is?
The mechanism is intentionally simple. A user publishes a kind 10133 event containing one or more payto tags, each structured as
["payto", "
.
The type field is a lowercase string identifying the payment rail bitcoin, lightning, ethereum, monero, paypal, venmo, revolut, cashme (Cash App), and so on and the address field is whatever identifier that rail actually uses: an on-chain address, a Lightning address, a username, an account handle.
The spec also explicitly anticipates newer Bitcoin-specific formats, listing bip352 (silent payments) and bip353 (DNS-based Bitcoin addresses) among its commonly used tags.
For types clients don’t specifically recognise, the spec allows falling back to a generic payto://
bitcoin: or ethereum: when one exists.
To give you an idea of what this looks like, here’s an example of a profile set up to receive four different payment rails
- Lightning
- R-BTC (Rootstock Side Chain)
- On-chain Bitcoin
- L-Bitcoin (Liquid Network)
That’s it, that’s the whole mechanism.
One event, a list of tags, each pointing to a different payment destination on a different network sidechains, altcoins, and fiat apps included all sitting side by side in the same structure as a Bitcoin address.
If a client supported these events, the user flow would look like this.
- I publish a post
- One of my followers wants to donate on said post or my profile
- They click Zap, and a list of possible donation options pops up
- The user picks the payment method that they prefer and executes the payment
- Once completed, the payment is added to the Zapped note event so all users can see the donation.
The Real Downside: Static Addresses and KYC Linkage
This is where NIP A3’s simplicity becomes a genuine privacy concern. A payto tag is, by design, a static, reusable payment target published once and read by anyone who fetches your profile.
For a Lightning address or a Bitcoin address generated fresh for this purpose, that’s a manageable trade-off. But the spec’s own examples and commonly-used-tag list make clear this is meant to include things like PayPal, Venmo, and Revolut handles accounts that are directly tied to a real-world identity through KYC at the account provider.
Publish a PayPal or Venmo tag on your Nostr profile, and you’ve permanently linked your pseudonymous Nostr identity to a KYC’d financial account, visible to any relay operator, client, or observer who looks.
Publish a static on-chain Bitcoin address rather than something like a BIP 353 DNS-based address or fresh silent-payment output, and you’ve handed anyone who wants to track you a single address they can watch indefinitely every future payment to that address becomes trivially linkable to your Nostr identity and to each other via ordinary blockchain analysis.
Unlike a zap receipt, which is at least tied to a specific event and payment, a payto tag just sits there as a standing, all-purpose target accumulating a linkable transaction history behind it for as long as it’s used.
None of this is unique to Nostr reusing addresses and tying pseudonymous identities to KYC accounts has always carried this risk.
What NIP A3 does is make it trivially easy, protocol-native, and because it now spans fiat rails as well as crypto ones considerably higher-stakes than a reused Bitcoin address since your payments can be linked to content that might be seen as unsavoury.
Do you really want the world to know all the OnlyFans models you’re zapping? I thought so!
Adoption Is Entirely Up to Clients
It’s worth emphasising what NIP-03 actually controls, and what it doesn’t. Like every NIP, it only standardises how the event is structured. It says nothing about whether any given client renders these tags, in what order, or with what warnings attached.
The events get published to relays regardless; whether they’re ever surfaced to another user as a clickable “pay me” button is purely a client-side decision.
That leaves real room for divergence across the ecosystem.
Open to everybody clients
Some clients will likely lean into the wide-adoption path NIP A3 enables, rendering PayPal buttons, Venmo handles, and altcoin addresses right alongside Lightning and Bitcoin, chasing the broadest possible payment compatibility and the largest possible audience.
Bitcoin-only clients
Other clients, particularly those built around a Bitcoin-only ethos, may choose to only render bitcoin, lightning, bip352, and bip353 tags, ignoring or even actively warning against fiat and altcoin payto entries to keep the payment experience aligned with Bitcoin-only values, while still remaining fully spec-compliant, since NIP A3 never requires a client to display everything it receives.
That divergence is arguably the most interesting long-term consequence of NIP A3. It’s almost as if nostr has soft-forked in a way with this change, and it remains to be seen how alternative clients and alt payments will respond.
We’ve seen many altcoin-powered social media services over the years, and they’ve all failed; we’ve seen many alternative social platforms try to monetise in the shadows of big tech social platforms, and they’ve remained niche.
Could this be the moment for both ecosystems to add support for Nostr? Only time will tell.
