What is the Lightning Network?
The Lightning Network is a peer-to-peer payment protocol built on top of Bitcoin. It was first proposed in 2015 by Joseph Poon and Thaddeus Dryja, and the first production implementations launched in 2018. Lightning enables payments that settle in under a second at a per-payment cost of fractions of a cent, by moving most transactions off the main Bitcoin chain into a network of payment channels.
A useful way to think about it: Bitcoin is the settlement layer, Lightning is the payment layer. Bitcoin records final, irreversible state. Lightning records the running balance between two parties without writing every step to the chain. When the parties are done, they close the channel and the final balance settles back to Bitcoin.
Lightning is open, permissionless, and protocol-defined rather than service-defined. Anyone can run a node, route payments, or build software on top of it. That openness is why projects like Rythm can use Lightning as infrastructure without asking permission.
Why micropayments could not work before Lightning.
Bitcoin alone has a fixed cost per on-chain transaction. The cost varies with congestion, but at typical fee rates, sending a single sat costs more in fees than the sat itself. A four-cent cover charge would not survive the round trip.
This is the same reason credit-card networks have minimum-charge thresholds (typically $0.20 to $0.50). The fixed cost of processing a transaction is too high to make cents-scale payments viable. Lightning solves this by amortizing the on-chain cost across many off-chain payments.
Open one payment channel with a single on-chain transaction, run a thousand four-cent payments through it, then close the channel with a single on-chain transaction. The fixed cost has been spread across a thousand payments. Per-payment cost drops to whatever routing fees are charged along the way, which is typically a fraction of a cent.
How payment channels work.
A payment channel is a two-party agreement to track a running balance off-chain. Imagine two friends sharing a bar tab: instead of settling up after every drink, they keep a running tally and settle once at the end of the night.
In Lightning terms: the two parties open a channel by committing some Bitcoin into a multi-signature address that requires both signatures to spend. They then exchange signed updates that say "the balance is now 70/30," "now 50/50," "now 90/10." Each update is a valid transaction that either party could broadcast at any time, but neither does, because the channel is still useful. When either party wants out, they broadcast the latest balance and the channel closes on-chain.
A network of these channels lets payments hop. If A has a channel with B, and B has a channel with C, then A can pay C by routing through B, even though A and C have no direct channel. B charges a tiny routing fee for the service. The cryptographic tricks underneath (hash time-locked contracts, or HTLCs) make routing trustless: B cannot steal the payment in transit.
Lightning Service Providers.
Most Lightning users do not run their own node. Running a node well requires keeping it online, managing channel liquidity, monitoring for closed channels, and handling backups carefully. For end-users, that is a lot of work for a wallet.
A Lightning Service Provider (LSP) is a routing node that handles the operational complexity on behalf of users. The LSP opens channels with the user, maintains liquidity, and routes payments. The user keeps the keys to their own wallet (so the LSP cannot steal funds) but offloads the connectivity and uptime work.
LSPs are how mainstream Lightning wallets like Phoenix, Breez, Mutiny, and Cash App work. The user connects their wallet, the LSP handles the rest. Rythm-compatible wallets all run this way, which is why setup is one tap and never asks the user to manage channels.
Why Rythm uses Lightning under the hood.
Cover-charge payments need three properties to work: cheap, instant, and peer-to-peer. Cheap, because the cover charge itself is four cents at the default; a payment rail that costs a dollar to move four cents would be absurd. Instant, because a sender expects their email to deliver immediately, and the cover-charge settlement should be just as fast. Peer-to-peer, because Rythm is non-custodial by design and the payment must flow from sender to recipient without any service holding funds in between.
Lightning is the only widely-deployed payment rail that meets all three constraints. Per-payment cost is fractions of a cent, settlement is under a second in typical conditions, and channel architecture is inherently peer-to-peer. The combination is what makes a four-cent email paywall economically and technically possible.
The user experience is intentionally invisible. You connect a Lightning wallet at setup. Cover-charge payments settle to your wallet automatically. You see a balance increase. You never have to think about channels, routing, or mempool fees. Lightning is plumbing, and we keep it under the floor.
Security properties.
Lightning inherits its security from the underlying Bitcoin chain. Every payment is cryptographically verified at every hop using HTLCs. If a routing node tries to steal funds, the HTLC mechanism makes the attempt fail or get clawed back on-chain.
Channel parties always have a path to recover their funds. Even if the counterparty disappears or refuses to cooperate, either party can force-close the channel by broadcasting the latest signed state. The on-chain settlement is delayed (a few hours to a few days, depending on parameters) so that watchtowers and monitoring services can detect and respond to a counterparty broadcasting a stale state, but the funds are recoverable.
For end-users, the practical security model is the same as any other non-custodial wallet: keep your seed phrase, do not run untrusted software, do not run untrusted browser extensions, and the funds are yours.
Where Lightning fits in the broader payment landscape.
Lightning is not a replacement for credit cards. It is an open-protocol payment rail with strengths and weaknesses different from card networks. Credit cards are reversible (chargebacks), require account-based identity, and have higher per-transaction costs. Lightning is irreversible (settlement is final), pseudonymous (no account is required), and has near-zero per-transaction cost.
For some use cases, Lightning is structurally better than cards. Tiny payments, like cover-charge email gating, are one. Cross-border payments without correspondent-banking infrastructure are another. Pay-per-use API access (where authentication via account would be operationally heavy) is a third.
For other use cases, cards are still the better fit. High-value purchases benefit from chargebacks. Subscription billing with regulated card-on-file flows still depends on issuer infrastructure. Rythm uses Lightning where it makes sense (cover-charge settlement) and accepts cards where they make sense (the monthly subscription).