Lightning Network explained for Nostr users

Every zap on Nostr is a Lightning payment. If you want to send or receive zaps, you are using Lightning whether you think of it as Lightning or not. And if the whole thing feels like a black box, this guide opens it.

We are not going to cover the cryptographic details of payment channels unless you ask. This is the Lightning explanation that skips the HTLC math and focuses on what you actually encounter as a Nostr user: invoices, wallets, fees, and why it all works in seconds instead of minutes.

TL;DR. Lightning is a fast payment layer built on top of Bitcoin. Payments are off-chain, routed through a network of nodes, and settled in under a second. Fees are typically a fraction of a cent. Nostr uses Lightning for zaps because only Lightning makes one-cent social tips practical.

When you are ready, grab your @nostr.blog address →

The problem Lightning solves

Base-layer Bitcoin is secure and decentralized, but it is slow and not cheap for small payments. Every Bitcoin transaction is recorded in a block, and blocks come about every ten minutes. A transaction pays a fee proportional to its size, and in busy periods the fee to move a few dollars can be a few dollars.

This makes Bitcoin a poor fit for tipping. A one-cent tip that costs ten cents in fees and takes ten minutes to confirm is not a tip; it is an error.

Lightning exists because people wanted both Bitcoin's properties (self-custodial, permissionless, no intermediary) and the economics of a payment network (fast, cheap, for small amounts). Off-chain payment channels solve this by amortizing the blockchain cost across many payments.

How a channel works, without the math

Two people who want to transact often on Lightning open a payment channel by publishing one Bitcoin transaction. That transaction locks some Bitcoin in a shared 2-of-2 address. Both parties now have a channel with a capacity equal to what they locked.

They can then send each other payments by updating an off-chain record of the channel's current balance. Alice sends Bob 100 sats: the record is updated. Alice sends Bob 100 more sats: updated again. They do this thousands of times. None of it touches the blockchain.

When they are done, they close the channel by publishing one more Bitcoin transaction that records the final balance. Two on-chain transactions cover arbitrarily many payments between them.

Now scale this up. Alice does not have a channel with every Bitcoin user in the world. She has a channel with two or three well-connected nodes. Those nodes have channels with dozens of other nodes, and so on. A Lightning payment from Alice to a stranger across the network routes through a path of intermediate nodes, each of which has a channel with the next.

The payment is atomic: it either completes end-to-end or fails entirely. No intermediate node can steal funds because the cryptography ensures they only get paid if the next hop also gets paid. This is the part with the HTLC math we are skipping; the important property is atomicity.

What this looks like as a user

You do not see any of the above. Here is what you actually see:

As a sender: you tap "send" in your Lightning wallet, paste an invoice or a Lightning address, choose the amount, confirm. The wallet finds a route through the network and settles the payment. The whole operation takes under a second.

As a receiver: you share a Lightning address (like alice@getalby.com) or generate an invoice (a long string starting with lnbc). The sender pays either; your wallet balance goes up.

The wallet abstracts the channels, the routing, the cryptographic atomicity, and the fee calculation. What you see is numbers going up and down, and occasionally a failed payment notice if routing did not find a path.

Where Nostr uses Lightning

Zaps are the Nostr-specific application of Lightning. The flow:

1. You want to tip someone for their post.
2. Your client asks their Lightning address for an invoice attached to a zap-request event (a specific Nostr event describing the tip).
3. Their wallet (or the service hosting their Lightning address) generates an invoice for the amount you chose.
4. Your wallet pays the invoice.
5. Once paid, a zap-receipt event gets published to Nostr relays by the service that handled the payment.
6. Your client and theirs both see the receipt and render it as a zap with the amount visible next to the tipped post.

Five of those six steps are Lightning. Only step five is Nostr-specific. The rest is standard Lightning infrastructure that happens to be called by Nostr clients.

This is why getting zaps to work means getting Lightning to work. A Nostr zap that fails usually fails because the Lightning layer failed, not because Nostr is broken.

Custodial vs non-custodial wallets

Two kinds of Lightning wallets exist, and the difference matters.

Custodial wallets (Wallet of Satoshi, Strike, Blink, Primal wallet) hold your Bitcoin on their own infrastructure. You have an account; they have the keys. Advantages: zero setup, instant availability, no channel management. Disadvantages: the wallet provider can freeze your funds, they see your payments, and if they disappear your funds go with them.

Non-custodial wallets (Phoenix, Mutiny, Breez, Zeus, Alby self-hosted) hold the keys on your device or your own node. Advantages: only you can spend, nobody can freeze you, privacy is better. Disadvantages: you manage channels and backups yourself, liquidity is something you have to think about occasionally, setup is more involved.

For Nostr zap activity, both work. New users almost always start with a custodial wallet because the friction is lower, and many stay there because zap amounts are small and the convenience wins. Users with higher balances or stronger privacy needs move to non-custodial.

Lightning addresses vs invoices

A Lightning address looks like alice@getalby.com. It is a permanent identifier you publish in your Nostr profile. Senders can tip you without generating a new invoice every time; their wallet asks your Lightning address for a fresh invoice automatically.

An invoice is a one-time payment request. Starts with lnbc... and encodes the amount, the destination node, and an expiration time (usually an hour). Single-use; once paid, cannot be reused.

For zaps, you share the Lightning address. Your wallet handles invoice generation behind the scenes. Raw invoices are for direct transfers (pay this person 0.01 BTC right now) where you know the exact amount and do not need repeat payments.

Fees, the realistic numbers

Lightning fees are tiny compared to base-layer Bitcoin.

• Typical zap (21 to 1000 sats): fee is often zero or one sat. Some routes charge a few sats extra for very small payments.
• Medium payment (100,000 sats, about $60): fee usually 1 to 10 sats. 0.001 to 0.01 percent.
• Large payment (1,000,000 sats, about $600): fee 50 to 500 sats. Still under 0.05 percent typically.
• Channel open (one-time, on-chain): whatever the current Bitcoin mempool fee rate is. Ranges from 200 sats on quiet days to 20,000 sats on busy days.

The fee structure reverses Bitcoin's in an important way: small Lightning payments are cheap in absolute terms (a fraction of a cent), whereas small on-chain Bitcoin payments pay a flat fee that dominates the amount. Lightning exists to make small payments economical.

What Lightning cannot do yet

Honest limitations as of 2026:

• Receive without inbound liquidity. You need channels where the other side has a balance to "send" you sats. New non-custodial wallets solve this with auto-liquidity purchases, but there is still a first-time awareness curve.
• Move very large amounts in one payment. Routing a 10 BTC payment through a typical Lightning network is hard because no single path has that much liquidity. Multi-path payments help but do not fully solve it.
• Be fully anonymous. The sender knows the path's first hop; receivers know their immediate neighbor. The full path is hidden from everyone except the sender, but metadata leaks. Tools like route randomization and trampoline routing close some gaps, not all.
• Work offline. Lightning requires both sender and receiver (or a wallet infrastructure representing them) to be online when the payment happens. Base-layer Bitcoin works asynchronously; Lightning does not.

These are active engineering areas, not fundamental limits. The 2026 Lightning network handles use cases that the 2021 Lightning network could not. The trajectory is toward fewer limitations each year.

What to do next

If you are here because you want to zap someone on Nostr:

1. Install a Lightning wallet. Wallet of Satoshi is the easiest starting point for beginners; Phoenix if you want non-custodial on mobile. (If you signed up through nostr.blog, a wallet is already provisioned for you as part of the flow, so you can skip this step.)
2. Fund it with sats. Any exchange that supports Lightning withdrawals will work; several let you deposit fiat and withdraw Lightning directly.
3. In your Nostr profile, set your Lightning address (the wallet gives you one).
4. Now you can send and receive zaps.

The whole setup takes about ten minutes. The "Lightning Network" sounds intimidating when you read articles like this one; in practice it is a wallet app that sends Bitcoin the way any other app sends dollars.