Lightning’s Next Test: Can It Fix Nostr’s Relay Economy?

Lightning Network was built on a simple pitch: move value in amounts too small for a card network to bother with, fast enough that nobody notices the wait. For years that pitch stayed mostly theoretical outside tipping culture and a handful of merchant pilots. Nostr, the open social protocol that stores and distributes posts through independently run relays rather than one company’s servers, has turned that pitch into a real, currently unresolved market. Relay operators pay actual bandwidth, storage, and compute bills to move other people’s data, and roughly four years into serious experimentation, nobody has landed on a business model that reliably covers those bills.

The numbers are not subtle. An analysis of Nostr.band’s relay tracking data published on Dev Community found that of roughly 1,005 tracked relays, only about 471 remained public and reachable, around 191 sat behind some form of restriction, and 343 had simply gone offline, a split the piece used to argue that a large majority of relays never find a way to cover their own costs. That is the backdrop for this piece: a look at how Lightning micropayments, borrowed authentication specs, and old-fashioned subscriptions are being stitched together to try to fund infrastructure nobody is required to pay for.

This is deliberately not another story about zaps, the tipping feature most casual Nostr coverage already focuses on. It is a story about the less visible, less social side of the same rail: what happens when Lightning has to fund a server instead of a person, and why that has turned out to be the harder problem.

What a Relay Actually Does, and Why the Bill Never Stops

A Nostr relay is, mechanically, a fairly plain piece of software. Implementations like strfry, written in C++ for raw throughput, or khatru, a Go framework built by Nostr’s own creator that has become a common base for custom relays, do the same basic job: accept WebSocket connections, verify the cryptographic signature on incoming events, store them, and rebroadcast them to any client that has subscribed to a matching filter. There is no block reward, no protocol-level subsidy, and no built-in metering. A relay is closer to running a mail server or an open RSS host for the entire network than to running a blockchain node.

That design is deliberate. Nostr’s entire value proposition depends on nobody controlling the graph: a user’s identity is just a keypair, portable across any relay that will accept it, so no single operator can hold a user’s followers hostage the way a centralized platform can. But portability and openness also mean there is no natural chokepoint for charging for the underlying work. Anyone can spin up a relay; nothing requires them to charge for it, and until they do, they eat the costs themselves. Because the software itself is lightweight and largely free, standing a relay up is not the hard part. Keeping it running as traffic grows is what breaks most operators.

Those costs come in three flavors, and unlike a one-time setup fee, all three scale with usage rather than time:

• Bandwidth, to receive every write from every connected client and rebroadcast it to every subscriber, which grows with the size of the network whether or not the relay operator wants it to
• Storage, to keep events queryable on demand rather than discarding them, which accumulates indefinitely unless an operator actively prunes it
• Compute, to filter, index, and serve subscription queries fast enough that clients do not time out

A grant, a donation, or a single upfront fee can cover day one. None of them naturally cover month eighteen, which is exactly the mismatch the rest of this piece is about.

None of this is solved by picking one great relay and settling in, either. Most clients follow a relay list published under NIP-65, letting a user declare which relays they write to and which they read from, so a single account typically spreads its posts across several relays at once for redundancy rather than depending on any one operator staying online. That redundancy is good for the user’s data. It does nothing to change the economics for any individual relay on that list, since each one still has to absorb the full cost of storing and serving that user’s activity regardless of how many other relays are doing the exact same job in parallel.

The Free Rider Problem: A Nine Figure Event Count With No Meter

Because writing to a relay costs nothing by default, Nostr inherited the same spam dynamic every open, permissionless publishing system eventually runs into. The Dev Community analysis found that roughly 315,000 profiles carried a populated bio or contact list in early 2026, with about 228,000 daily events flowing across the 178 or more relays that each carry at least five percent of total tracked network content. Much of that unwanted traffic is not random noise. Engagement farming bots that repost or react to content automatically, throwaway keys created to test a client during development, and outright spam campaigns pushing links or scams all show up in a relay’s logs looking, at the protocol level, indistinguishable from a genuine post by a real person, since Nostr has no identity verification layer to tell them apart.

Early press coverage of Nostr told a bigger story. Forbes reported in May 2023 that the network had generated around 18 million distinct identities and roughly 500,000 daily active users. That figure and the 2026 tracker numbers above are not really measuring the same thing: the 2023 count included every public key that had ever signed a single event, throwaway test accounts and spam bots included, while more recent trackers increasingly filter for an actual, populated, followed profile. The gap between those two ways of counting is itself a symptom of the underlying problem. Creating an identity on Nostr, like writing to a relay, has always been free, so both numbers are easy to inflate and hard to compare cleanly.

How a Relay Says “Pay Me”: NIP-11 and NIP-42

Nostr’s specification process runs through community drafted NIPs, short for Nostr Implementation Possibilities, and two of them do the actual plumbing for relay payments. NIP-11, the relay information document, lets a relay publish a JSON file describing itself: name, contact, supported NIPs, server limits, and critically, a payments_url and a fees object that can specify admission, subscription, or per-event publication charges denominated in millisatoshis. A client can fetch this document with a simple HTTP request before ever connecting, and decide whether the relay’s terms are worth paying. The specification’s own documentation illustrates that fees object with a relay charging an 18,888,000 millisatoshi admission fee, close to twelve dollars at current bitcoin prices, or a 5,000,000 millisatoshi monthly subscription, a little over three dollars, giving operators a standard, machine-readable way to advertise pricing that in practice varies wildly from one relay to the next.

NIP-42 is what actually enforces those terms. A relay that wants to restrict access sends an AUTH message containing a random challenge string; the client responds by signing a short-lived event of kind 22242 that references that challenge and the relay’s own URL, then sends it back. The relay checks the signature, the challenge match, and a timestamp window, typically around ten minutes, before granting access, and the specification explicitly requires relays to exclude those authentication events from ever being rebroadcast to other clients. Between the two specs, a relay operator has everything needed to say, in machine readable terms, pay this amount through this channel, then prove you paid before being allowed to write.

“Pay Once, Get In Forever”: fiatjaf’s Blunt Fix

Nostr’s pseudonymous creator, known as fiatjaf, built one of the earliest working answers himself. expensive-relay is a reference relay implementation that requires exactly one Lightning payment per public key before that key is allowed to publish, after which it is whitelisted indefinitely. The design is about as simple as a payment gate can be: no subscription to track, no renewal logic, just a single invoice standing between a spammer and a permanent seat at the table.

It is also, by the Dev Community analysis’s own framing, an incomplete answer: a one-time payment covers day one and does nothing for month six, since bandwidth, storage, and compute keep accruing long after the invoice is settled. fiatjaf himself has been candid that he is not chasing a fully solved, professionalized version of this either. In a May 2023 profile, Forbes quoted him saying, “If today, a giant company started doing things on Nostr to make money, they would take control of the protocol, and it wouldn’t be good.” The tension he is describing runs through every model in this article: a monetization layer robust enough to fund a network at scale tends to require exactly the kind of centralized, professional operator Nostr was designed to route around.

Subscriptions Take Over: nostr.wine and the Professional Relay

The model that has actually gained the most real world traction looks less like fiatjaf’s one-shot fee and more like an ordinary SaaS subscription, just billed in sats. nostr.wine, one of the most widely used paid relays, charges roughly seven dollars a month and uses NIP-42 authentication to gate access to paying members, layering in extras like direct message privacy, regional server mirrors, and NIP-50 full text search that a free relay typically will not bother maintaining. It is not the only option in that price bracket either; Nostr.land and Eden run comparable paid tiers, giving users who want a professionally maintained relay a small but real set of vendors to choose between rather than a single default. A companion service, filter.nostr.wine, adds a further tier at 10,000 sats a month, currently somewhere around six dollars, that filters the open network firehose down to a user’s actual web of trust rather than everything anyone anywhere has posted, though it requires an existing nostr.wine membership to use.

Not every operator has settled on Lightning as the rail of choice, either. nerostr runs a similar pay-to-post model but bills in Monero instead, a reminder that even inside the small camp of relay operators who agree payment is necessary, there is no consensus yet on which payment network should carry it. Operators who would rather not build Lightning invoice handling from scratch have an off-the-shelf option, too. Nostream, another open-source relay implementation, supports connecting a ZBD API key directly, letting an operator turn on paid access without writing their own payment verification code. It is a small detail, but it matters: the easier it becomes to bolt Lightning payments onto an existing relay, the more operators are likely to actually try charging for access instead of quietly going offline.

Lined up side by side, the range of models on offer looks less like a single emerging standard and more like a market still trying things:

Zaps Are a Different Animal

It is worth being precise about what zaps do and do not solve here, since they are the part of this stack most casual coverage already knows. NIP-57, finalized in February 2023, defines a zap request event of kind 9734 and a zap receipt of kind 9735, the plumbing behind the lightning bolt icon that lets one user send sats directly to another as a tip on a specific note or profile. By May 2023, Forbes reported the network had already processed roughly 792,000 zap transactions worth about $1.9 million, an early sign the payment rail worked at the social layer. Volume has grown well beyond that early snapshot since; Lightning infrastructure firm Spark’s own research desk has tracked stretches of around 20 million zap transactions inside a single two-week window, a scale the 2023 figures only hint at.

None of that money goes to the relay that stored and served the zapped note. A zap is a payment from one user to another; the relay in the middle is doing the same bandwidth and storage work whether the note attached to it earns one sat or ten thousand. That is precisely why NIP-11 and NIP-42 had to be built as a separate mechanism from NIP-57: value-for-value tipping between people and infrastructure funding for the pipes those people talk through are different problems, and Nostr had to solve them with different specs.

The Client Layer: Primal Premium and Damus Purple

A meaningful share of the money actually changing hands in this ecosystem never touches an individual relay’s invoice at all. Damus Purple, the subscription tier for the Damus iOS client, is priced at 15,000 sats a month, roughly nine dollars at current bitcoin prices, and can be paid either over Lightning or, for iOS users who would rather not touch bitcoin directly, through Apple Pay. It bundles automatic translation, longer note retention, media hosting, and a supporter badge on the subscriber’s profile. Primal runs a comparable premium tier of its own, payable in bitcoin, that bundles media hosting and the client’s broadcast and relay infrastructure alongside a built-in Lightning wallet.

This model tends to work better in practice than asking users to pay individual relays directly, because a client operator can pool revenue across all the relay infrastructure it runs or partners with, rather than leaving every small relay operator to solve fundraising alone. The tradeoff is that it recreates something close to an ordinary platform business on top of a protocol explicitly designed so that no single app could lock in a user’s identity or audience.

Self-Hosting as the Third Path

Not every relay is trying to serve the public at all, and that turns out to be one of the cleanest fixes for the funding problem: stop trying to fund a public good and just pay for your own. Home server platforms including Umbrel and Start9 both ship one-click Nostr relay apps, typically running nostr-rs-relay or a similarly lightweight implementation, that default to private mode, a single whitelisted public key belonging to the operator, with everyone else’s writes rejected. Umbrel frames its version explicitly as a backup tool, syncing a user’s past and future activity from public relays onto hardware they control, while Start9’s own documentation recommends the private default specifically because a personal relay only has to store one person’s posts, follows, and settings rather than the entire network’s.

That framing sidesteps almost every problem raised so far. A relay with one user has no spam to filter, no free-rider dynamic, and a storage bill measured in gigabytes rather than the collective weight of hundreds of thousands of strangers’ posts. It does not solve the public relay economy, since somebody still has to run the shared infrastructure that lets different users discover each other’s content in the first place, but it is a real, already-shipping answer to a narrower question: how an individual guarantees their own data survives even if every paid and free public relay they use eventually goes dark.

Proof of Work: The Free Alternative That Only Half Works

Not every relay wants to charge money at all, and a parallel spec offers a way to raise the cost of spam without asking for a single sat. NIP-13 defines proof of work for Nostr events: since every event ID is itself a hash of its contents, a client can be made to grind through variations until it finds one with a minimum number of leading zero bits, a workload measured as difficulty. A relay can simply reject any event below a difficulty threshold it sets, making mass spam computationally expensive without requiring an account, a payment, or an identity of any kind.

It is a genuinely elegant fit for Nostr’s censorship-resistant instincts, since it needs no gatekeeper and no payment processor. It is also only half a fix. Proof of work burns real electricity for legitimate users too, tilts the playing field toward whoever has better hardware, and, unlike a Lightning payment, generates zero revenue for the operator who is still paying the bandwidth and storage bill either way. NIP-13 remains formally a draft with what the specification describes as growing but optional adoption, mostly among relays that care more about deterring spam than about funding themselves. A growing number of operators do not treat the two approaches as mutually exclusive, either, setting a modest difficulty requirement for casual free posting while reserving guaranteed, unthrottled access for anyone willing to pay, effectively using proof of work as a free tier and Lightning as the paid upgrade sitting right next to it.

Put together, the state of the network the Dev Community analysis described looks roughly like this:

The Liquidity Problem Hiding Under Every Sats Invoice

Even where a relay or client does charge in sats and a user is happy to pay, actually receiving that payment is not as trivial as the invoice makes it look. Most small relay operators are not running their own well-connected routing node; they rely on a custodial wallet, a Lightning service provider, or an exchange-hosted Lightning address to actually receive funds, which means the payment still has to cross Lightning’s underlying liquidity market before it settles. HOGE Wire has covered that market in detail: inbound liquidity has to be leased or earned before a node can reliably receive payments at all, and the businesses that supply it are themselves a fairly concentrated group. The mechanics are the same ones that show up anywhere a node needs to receive a payment it did not initiate: without channels already funded from the paying side, an incoming payment simply cannot land, which is why liquidity providers increasingly offer just-in-time channel opening, provisioning capacity the moment a payment arrives rather than requiring it to sit pre-funded and idle. It works, but it is one more piece of infrastructure, and one more party to trust, standing between a relay operator and the sats a subscriber thinks they already sent.

Jesse Shrader, chief executive of the liquidity marketplace Amboss, has described just how thin the margins on that supply side already are. Shrader told Bitcoin Magazine, “We’re supplying liquidity at less than 0.5 percent…” describing the cost routing node operators charge to lease the inbound capacity that lets a relay, a merchant, or anyone else actually get paid over Lightning. That cost is invisible to a Damus Purple subscriber tapping pay in an app, but it is exactly the plumbing that has to work underneath every payment model in this piece, and it is a large part of why building a Lightning-native business, whether a relay or anything else, is still more operationally involved than it looks from the outside.

Why This Reaches Past Nostr: Lightning’s Micropayment Thesis on Trial

In dollar terms, the entire Nostr relay economy is tiny next to the rest of crypto. Its value here is as a live, adversarial test of a claim Lightning has made since its earliest days: that it can move value in amounts too small for a card network, and often too small for even a stablecoin transfer, to bother with. Lightning Labs chief executive Elizabeth Stark made exactly that comparison at the FT Live Crypto and Digital Assets Summit in London in May 2024, telling the audience, “Compared to traditional systems like Visa, where fees in the U.S. can be as high as 3%, the cost of transacting stablecoins on the Lightning Network can be dramatically lower, often just a cent or less.” A monthly relay subscription measured in single-digit dollars, or a per-event fee measured in fractions of a cent, is precisely the kind of payment that claim is supposed to make practical.

It is also a claim Lightning is defending on more than one front at once. HOGE Wire’s look at Lightning’s standing against the major stablecoin rails found that neither Visa’s nor Mastercard’s own on-chain settlement networks include Bitcoin or Lightning anywhere on their supported chain lists, even as both companies push deeper into stablecoin settlement elsewhere. The same sub-cent, high-frequency payment problem Nostr relays are wrestling with is also showing up somewhere else entirely: AI agents transacting with each other and with paid APIs at machine speed, where a single request might be worth a tenth of a cent and a card network’s minimum fees make processing it profitably impossible. Lightning-native toolkits built around the L402 protocol are chasing that exact market, and the core economic puzzle is identical to a relay’s, since someone still has to fund the infrastructure doing the work, not just move the payment between two parties. And the same real-world commerce test is playing out one storefront at a time, too: merchants accepting Lightning at the point of sale are testing the identical thesis in a completely different context.

Custody, Control, and Who Ends Up Owning the Graph

Every model that has actually gained adoption here, subscriptions, client bundling, even fiatjaf’s one-time fee, reintroduces some version of a trusted intermediary that the underlying protocol was designed to avoid. Lightspark chief executive David Marcus described the shape of that tradeoff in blunt terms in late 2023, arguing that “if you want full support for non-custodial Lightning with offline receive and want to make it economically viable, you have to accept some form of compromise on the trustlessness level of the solution.” Swap relay operator for wallet provider and the logic holds just as well: the easier a Lightning-based payment is made for an ordinary user, the more likely there is a custodian, a liquidity provider, or a platform sitting somewhere in the path. That echoes a criticism that has dogged Lightning’s own routing layer for years, separate from anything Nostr-specific: node operators have faced scrutiny for leaning on a small number of large cloud hosting providers rather than genuinely distributed infrastructure, a concentration that undercuts the same self-sovereignty argument paid relays are quietly running into from a different angle. Neither problem has an easy fix, since the convenience and reliability of professional hosting is precisely what makes it attractive in the first place.

There is a regulatory footnote worth adding here, precisely because it is so quiet. Because relay subscriptions and client tiers are voluntary, non-refundable payments for a defined service rather than anything resembling an investment contract, they have stayed almost entirely outside the enforcement dockets that other parts of crypto keep landing in. HOGE Wire’s review of the SEC’s own crypto enforcement record is a useful contrast: the agency’s attention keeps concentrating on token sales, exchange listings, and yield products, not on a relay operator charging a flat monthly fee for bandwidth. That is not a loophole so much as a reflection of how ordinary the underlying transaction actually is.

Where the Money Goes From Here

Philanthropy bought the ecosystem its first few years of runway. Jack Dorsey sent fiatjaf 14 BTC, worth around $200,000 at the time, in December 2022 to fund early development, and by May 2023 his #startsmall initiative had donated $10 million to the Bitcoin-focused nonprofit OpenSats, with half of that, $5 million, earmarked specifically for Nostr development. Money like that paid salaries and funded relay infrastructure directly, but it was never going to be a repeatable model, and nobody involved has claimed otherwise.

What is emerging instead by 2026 looks less like a single winning business model and more like a stack of partial fixes layered on top of each other: proof of work to filter out the cheapest spam for free, NIP-42-gated subscriptions or one-time fees for relays willing to run as small businesses, private self-hosted relays for users who just want their own data preserved, zaps for the social and creator-payment layer that sits entirely apart from relay funding, and client-level bundling from operators like Primal and Damus to smooth revenue the way a platform would. None of it is fully solved. Years after fiatjaf shipped the first serious attempt at a fix, the Dev Community analysis cited throughout this piece still found most tracked relays underwater. That makes Nostr’s relay market one of the more honest, least hyped tests running anywhere of whether Lightning’s micropayment promise can actually fund infrastructure, and not just move tips between friends.

Frequently Asked Questions

What is a Nostr relay and why does it cost money to run?

A relay is a server that accepts posts, called events, from Nostr users, stores them, and forwards them to anyone subscribed to matching content. Running one costs real money because bandwidth, storage, and compute all scale with how much traffic and data the relay handles, and the Nostr protocol itself provides no built-in reward or subsidy for that work, unlike a blockchain’s mining or staking rewards.

How do paid Nostr relays like nostr.wine actually work?

Paid relays typically use the NIP-42 authentication specification, which lets a relay challenge a connecting client to prove ownership of a public key before granting write access. Combined with NIP-11, which lets a relay publish its own fee schedule, an operator can require a monthly subscription, such as the roughly seven dollars nostr.wine charges, or a one-time fee before whitelisting a user’s key to post.

What is the difference between a Nostr zap and paying for relay access?

A zap is a peer-to-peer Lightning tip, defined by the NIP-57 specification, sent from one user directly to the author of a specific note or profile, so the money goes to the person, not the infrastructure. Paying for relay access is a separate payment to the operator running the server, covering the bandwidth and storage that note actually consumes, and the two use entirely different specifications.

Can I still use Nostr for free?

Yes. Most relays remain free and open, and some use proof of work under the NIP-13 specification instead of payment, making spam computationally expensive rather than requiring money outright. Free relays do have a much higher rate of going permanently offline over time, since operators are covering every cost themselves with no revenue to offset it.

Is Lightning Network actually well suited to tiny, frequent payments like relay subscriptions?

In principle yes, since Lightning can settle payments worth a fraction of a cent far more cheaply than card networks or most on-chain transfers. In practice, reliably receiving many small payments still depends on having enough inbound liquidity, which is why most relay operators and wallet users rely on custodial services or liquidity providers rather than running a fully self-sufficient routing node.

Written by Marcus Okafor for HOGE Wire.