Is the Lightning Network secure?

Lightning inherits its security from Bitcoin. Funds inside a channel are real bitcoin held in a 2-of-2 multisignature address, and the channel's enforcement script lets either party recover their balance on-chain even if the counterparty disappears or tries to cheat. The trade-offs are operational (staying online, managing liquidity, backing up channel state), not cryptographic.

Why are Lightning fees so much lower than on-chain fees?

On-chain transactions pay miners to record the transaction in a block that every full node stores and validates forever. Lightning payments only update state between two parties off-chain. The fee on Lightning is mainly compensation to routing nodes for committing liquidity for a moment, so it can be a tiny fraction of a cent even for relatively large payments.

Do I need to run a Lightning node to use Lightning?

No. Most users start with a custodial or mobile self-custodial wallet that handles channels and liquidity in the background. Running your own node gives you full sovereignty and is recommended for power users and builders, but it is not a prerequisite for sending and receiving sats.

What happens if my Lightning wallet goes offline?

For sending, you can spend again when you're back online. For receiving, payments to your node will fail while you're offline but no funds are lost. The bigger risk is force-closing channels while you're offline, which is why most modern wallets include a built-in watchtower or use one provided by their Lightning service provider.

How is Lightning different from a sidechain or a rollup?

A sidechain is a separate blockchain pegged to Bitcoin with its own consensus rules. A rollup posts compressed proofs of off-chain state back to a base chain. Lightning is neither: it is a network of bilateral payment channels secured by Bitcoin script. There is no separate ledger and no global Lightning state — each channel only knows its own balance, and the routing layer composes those channels into a usable network.

Can I send dollars or other currencies over Lightning?

Lightning natively settles in bitcoin (1 BTC = 100,000,000 sats). However, exchanges and wallets routinely convert fiat in and out at the edges, so a sender can pay in dollars and a receiver can settle in dollars, with Lightning carrying the value transparently in between. Several services offer stable-sats or fiat-denominated accounts on top of Lightning rails.

Is Lightning private?

Lightning is meaningfully more private than the base layer for routed payments, thanks to onion routing — intermediate nodes see only their immediate neighbors. Privacy is not absolute: senders and receivers know each other's identities, channel graphs are largely public, and traffic analysis is possible. BOLT12 offers and route blinding improve recipient privacy further.

What is a Lightning Address?

A Lightning Address looks like an email — for example, you@example.com. Under the hood, it resolves via an LNURL-pay endpoint that generates a fresh BOLT11 invoice for each payment. It is the easiest way to share a 'send me sats' handle that works across wallets.

How small or large can a Lightning payment be?

Lightning payments can be as small as a single satoshi (or, with milli-satoshi accounting, a thousandth of a satoshi). Large payments are constrained by the liquidity available along the route; multi-path payments let wallets split large payments across several routes. Payments in the tens of millions of sats route reliably across the public network.

Where can I try Lightning without committing any money?

Public faucets — including Lightning Faucet — let you earn small amounts of sats by claiming, playing games, or completing earn tasks. Once you have a balance, you can withdraw to any Lightning wallet. It is the lowest-friction way to feel what an instant, near-free Bitcoin payment is actually like.

How does the Lightning Network work

How the Lightning Network works: payment channels, HTLC routing, invoices, liquidity, and the trade-offs of using Lightning for instant Bitcoin payments.

By Lightning Faucet team May 13, 2026 12 min read

The Lightning Network is a payment layer built on top of Bitcoin that lets people send and receive bitcoin almost instantly, for fees that are usually a fraction of a cent. Instead of writing every payment to the Bitcoin blockchain, Lightning lets two parties open a private payment channel, settle as many transactions as they want between themselves off-chain, and only publish a final summary when they close the channel. Those private channels are connected into a network, so a single payment can hop through several channels and reach almost anyone with a Lightning wallet.

This guide explains how that works — channels, routing, invoices, liquidity, and the trade-offs — and how you can use Lightning to play sat-denominated poker, bet on prediction markets, or earn sats without waiting for block confirmations.

The scaling problem Lightning was designed to solve

Bitcoin's base layer is intentionally conservative. Every full node validates and stores every transaction forever, and a new block is only produced about every ten minutes. That design is great for settlement assurances, but it caps the network at roughly seven transactions per second globally. A single on-chain payment usually waits at least one confirmation before merchants treat it as final, and on-chain fees rise sharply whenever the mempool fills up.

For a coffee payment, a tip, an in-game wager, or a micro-payment to an API, those properties are a poor fit. Lightning was designed to take everyday payments off-chain while still inheriting Bitcoin's security guarantees at settlement time.

What the Lightning Network actually is

The Lightning Network is a peer-to-peer network of bidirectional payment channels. A payment channel is a 2-of-2 multisignature address funded by two participants, with off-chain machinery that lets them update the balance between them many times without broadcasting each update to Bitcoin. The combined web of channels — plus the routing protocol that lets payments hop across them — is what we call "Lightning."

Three properties matter most:

Instant settlement. Once a payment route is found, the payment clears in seconds, often less than one second.
Tiny fees. Routing fees are typically a few satoshis or less, regardless of payment size up to the channel limits.
Bitcoin-secured. The balances inside channels are real bitcoin, locked in a Bitcoin script. If a counterparty disappears or cheats, you can recover your funds through the base chain.

Lightning is sometimes called a "layer 2" because it derives its security from a base layer (Bitcoin) but processes most transactions outside of it.

How a payment channel works

Channels are the atomic unit of the Lightning Network. Understanding them is the key to understanding everything else.

Opening a channel

Two parties — call them Alice and Bob — decide to open a channel. One or both of them deposits bitcoin into a 2-of-2 multisignature address on the Bitcoin blockchain. This funding transaction is a normal on-chain transaction. Once it confirms, the channel is open and the deposited amount becomes the channel's capacity.

At all times, the channel has a state: how the capacity is split between Alice and Bob. Initially, if Alice funded the channel with 1,000,000 satoshis, the state might be "Alice: 1,000,000, Bob: 0." Channels can also be dual-funded, where each side contributes.

Updating state off-chain

When Alice wants to pay Bob 50,000 satoshis, they jointly sign a new state ("Alice: 950,000, Bob: 50,000") and exchange signatures. Neither broadcasts anything to the Bitcoin network. The new signed state simply exists, ready to be broadcast if either party needs to enforce it.

Crucially, each new state invalidates the previous one. If Alice tried to cheat by broadcasting an old state where she had more bitcoin, Bob would have a window of time to publish a justice transaction — a penalty branch in the channel script that sweeps the entire channel balance to him. This punishment mechanism is what keeps both parties honest without requiring a trusted referee.

Closing a channel

A channel can be closed two ways:

Cooperative close. Both parties sign a final settlement transaction that pays out the current balances. This is cheap and fast.
Force close. One party publishes the latest state unilaterally. After a time-lock expires (usually a few hundred blocks), the funds become spendable on-chain. If the published state was outdated, the counterparty has that time window to publish the justice transaction.

Either way, only two on-chain transactions are required to support an unlimited number of off-chain payments: one to open the channel, one to close it.

How payments hop across the network

A single channel only lets two specific parties pay each other. The interesting property of Lightning is that channels compose. If Alice has a channel with Carol, and Carol has a channel with Bob, Alice can pay Bob through Carol without trusting Carol with the funds.

Hashed Time-Locked Contracts

The trick that makes routed payments trustless is called a Hashed Time-Locked Contract, or HTLC. When Bob wants to be paid, he generates a random secret R and shares its hash H = SHA-256(R) with Alice (this is what a Lightning invoice contains). The payment from Alice to Carol, and then from Carol to Bob, is conditional: each intermediary can only claim the funds by revealing the preimage R within a time window. Bob releases R to claim his payment from Carol; Carol uses the now-revealed R to claim her payment from Alice. If anything stalls, the time-locks ensure everyone's funds eventually return safely.

The result is an atomic, multi-hop payment. Either every hop succeeds and Bob has the money, or every hop reverts and nobody has lost anything.

Onion routing

Lightning uses onion routing inspired by Tor. The sender wraps the payment instructions in nested encrypted layers, one for each hop. Each routing node can decrypt only its own layer, which tells it where to forward the payment and how much to send onward. Nodes in the middle of the route generally do not learn who the original sender or final recipient is, only their immediate neighbors. This is a meaningful privacy property compared to a fully transparent base-layer transaction.

Pathfinding

A sending wallet keeps a local view of the public channel graph — capacities, fee policies, and announced channels — and computes a route from itself to the destination. Modern wallets try multiple parallel paths (Multi-Path Payments, or MPP), splitting a single large payment across several routes so it can succeed even when no single channel has enough liquidity. If a hop fails, the route is rebuilt and tried again, often within a few hundred milliseconds.

Liquidity: the part beginners miss

A common surprise for new Lightning users is that having bitcoin in a Lightning wallet is not enough to receive payments. You also need inbound liquidity — channels where the bitcoin currently sits on the other side, ready to flow toward you.

Imagine Alice opens a channel to Carol with 1,000,000 satoshis on Alice's side and zero on Carol's. Alice can send up to a million satoshis through that channel, but she can receive zero, because there's nothing on Carol's side to send back yet. As Alice spends, her outbound capacity drops and her inbound capacity rises in lockstep.

There are several ways to get inbound liquidity:

Spend outbound. Pay for things; your inbound capacity grows automatically.
Receive a channel. Ask a routing node, a Lightning service provider, or a peer to open a channel to you.
Liquidity marketplaces. Markets like Lightning Pool or Magma let nodes buy and sell channels.
Splice-in / splice-out. Newer protocols let you resize a live channel without closing it.

For everyday users on consumer wallets, this complexity is usually hidden behind the wallet's defaults. Power users who run their own nodes spend a lot of time thinking about it.

Invoices, Lightning Addresses, and how senders find receivers

Lightning supports several ways to request and send a payment.

BOLT11 invoices

The classic Lightning invoice is a BOLT11 string — a bech32-encoded blob that contains the recipient's node identifier, the payment hash, the amount (optional), an expiry, and a route hint. The sender scans or pastes it, and the wallet does the rest. BOLT11 invoices are single-use: the preimage is consumed on first payment.

Keysend and spontaneous payments

Sometimes you want to push satoshis to someone without first asking for an invoice — a tip, for example. Keysend lets the sender generate the preimage and ship it along with the payment, baked into the onion payload. The recipient learns the preimage on arrival and claims the funds. Most modern wallets support it.

Lightning Addresses and LNURL

Sharing a BOLT11 invoice over coffee is awkward. Lightning Addresses look like email — [email protected] — and resolve via an LNURL endpoint that generates a fresh invoice on demand. This is what most consumer apps use today for "send to a username" experiences. LNURL also covers other flows: LNURL-pay, LNURL-withdraw, and LNURL-auth (a passwordless login scheme that uses your Lightning node key as identity).

BOLT12 offers

BOLT12 is a newer specification for reusable, privacy-preserving payment requests. An "offer" is a static string that any sender can fetch a fresh invoice from, without revealing the recipient's node identity.

Custodial, non-custodial, and self-custodial wallets

Lightning wallets fall on a spectrum:

Custodial. A third party holds the keys and manages liquidity for you. Easy and beginner-friendly, but the custodian can freeze or limit your funds. Most modern faucet, gaming, and tipping sites — Lightning Faucet included — give users a custodial balance for friction-free play and let users withdraw to a non-custodial wallet whenever they want.
Self-custodial mobile wallets. Your phone holds the keys, but channels are typically managed by a Lightning service provider (LSP) that helps with liquidity. You can sweep funds on-chain if you ever lose trust in the LSP.
Self-hosted nodes. You run your own Lightning implementation (LND, Core Lightning, Eclair, LDK-based stack), manage your own channels, and have full custody. The most resilient option, and the only one with full sovereignty, but it requires ongoing operational attention.

There is no single "right" answer — the right choice depends on how much you're moving and how much operational work you want to do.

What you can actually do with Lightning

Lightning is no longer experimental. Real consumer and merchant use is widespread, and the protocol has stabilized enough to support a wide range of categories:

Micro-payments and tips. Send a few satoshis for a tweet, an article, a podcast clip, or a chat message.
Streaming payments. Pay-per-second video, audio, and AI inference services bill in real time over Lightning.
Games and entertainment. Lightning is well-suited to small, frequent, instant settlements — exactly the pattern of casino-style spins, free spin promotions, and in-game economies.
Multiplayer poker. Lightning poker lets real players sit at sat-denominated cash tables and tournaments, with deposits and withdrawals settling over Lightning rather than waiting on slow card processors.
Prediction markets. Sats-based prediction markets let participants take positions on outcomes like BTC difficulty, mempool fees, weather, and sports without sign-up friction.
Earn surfaces. Earn-style tasks and rewards pay out instantly in satoshis with no minimum withdrawal beyond a Lightning invoice.
APIs and machine payments. Protocols like L402 (formerly LSAT) let agents pay per request for an API, an model call, or a data feed. Builder-focused docs and gateways are available on the build hub for developers integrating Lightning into their own products.
Cross-border remittance. Lightning makes small, fast transfers across borders without the legacy correspondent-banking stack.

The common thread: any product where on-chain confirmation latency or fees would crush the user experience is a natural fit for Lightning.

Trade-offs and honest limitations

Lightning is powerful, but not a free lunch. The most important trade-offs:

Liquidity management. Receiving requires inbound capacity. For self-custodial users this is a real operational concern, although LSPs and automated tooling have made it dramatically easier.
Online requirement. A Lightning node must be online to receive payments and to watch for counterparty cheating. Watchtowers help, but add another moving part.
Routing failures. Not every payment finds a route on the first try, especially large payments through thin links. Multi-path payments mitigate this but do not eliminate it.
Privacy is good, not perfect. Onion routing hides intermediate hops, but senders and receivers still know each other, and channel graphs are largely public.
Channel closing costs on-chain fees. When the mempool is expensive, force-closing many channels at once can be costly.
Backups matter. Losing channel state can mean losing the funds in those channels. Static Channel Backups and modern wallet designs reduce this risk, but discipline is still required.

Custodial services hide these concerns; running your own node confronts them head-on.

Feel a Lightning payment for yourself

Reading about channels and routing only gets you so far. The moment Lightning clicks is the first time a payment you sent settles before you finish blinking. You can have that moment without spending anything: claim a few sats from the weekly free spin, withdraw them to a Lightning wallet, and watch the invoice settle in real time.

Once the sats are in your own wallet, every concept in this guide becomes concrete. The string you paste is a BOLT11 invoice, the path your payment takes is the routing described above, and the instant, near-free settlement is the whole reason this network exists.

Frequently asked questions

Is the Lightning Network secure?: Lightning inherits its security from Bitcoin. Funds inside a channel are real bitcoin held in a 2-of-2 multisignature address, and the channel's enforcement script lets either party recover their balance on-chain even if the counterparty disappears or tries to cheat. The trade-offs are operational (staying online, managing liquidity, backing up channel state), not cryptographic.
Why are Lightning fees so much lower than on-chain fees?: On-chain transactions pay miners to record the transaction in a block that every full node stores and validates forever. Lightning payments only update state between two parties off-chain. The fee on Lightning is mainly compensation to routing nodes for committing liquidity for a moment, so it can be a tiny fraction of a cent even for relatively large payments.
Do I need to run a Lightning node to use Lightning?: No. Most users start with a custodial or mobile self-custodial wallet that handles channels and liquidity in the background. Running your own node gives you full sovereignty and is recommended for power users and builders, but it is not a prerequisite for sending and receiving sats.
What happens if my Lightning wallet goes offline?: For sending, you can spend again when you're back online. For receiving, payments to your node will fail while you're offline but no funds are lost. The bigger risk is force-closing channels while you're offline, which is why most modern wallets include a built-in watchtower or use one provided by their Lightning service provider.
How is Lightning different from a sidechain or a rollup?: A sidechain is a separate blockchain pegged to Bitcoin with its own consensus rules. A rollup posts compressed proofs of off-chain state back to a base chain. Lightning is neither: it is a network of bilateral payment channels secured by Bitcoin script. There is no separate ledger and no global Lightning state — each channel only knows its own balance, and the routing layer composes those channels into a usable network.
Can I send dollars or other currencies over Lightning?: Lightning natively settles in bitcoin (1 BTC = 100,000,000 sats). However, exchanges and wallets routinely convert fiat in and out at the edges, so a sender can pay in dollars and a receiver can settle in dollars, with Lightning carrying the value transparently in between. Several services offer stable-sats or fiat-denominated accounts on top of Lightning rails.
Is Lightning private?: Lightning is meaningfully more private than the base layer for routed payments, thanks to onion routing — intermediate nodes see only their immediate neighbors. Privacy is not absolute: senders and receivers know each other's identities, channel graphs are largely public, and traffic analysis is possible. BOLT12 offers and route blinding improve recipient privacy further.
What is a Lightning Address?: A Lightning Address looks like an email — for example, [email protected]. Under the hood, it resolves via an LNURL-pay endpoint that generates a fresh BOLT11 invoice for each payment. It is the easiest way to share a 'send me sats' handle that works across wallets.
How small or large can a Lightning payment be?: Lightning payments can be as small as a single satoshi (or, with milli-satoshi accounting, a thousandth of a satoshi). Large payments are constrained by the liquidity available along the route; multi-path payments let wallets split large payments across several routes. Payments in the tens of millions of sats route reliably across the public network.
Where can I try Lightning without committing any money?: Public faucets — including Lightning Faucet — let you earn small amounts of sats by claiming, playing games, or completing earn tasks. Once you have a balance, you can withdraw to any Lightning wallet. It is the lowest-friction way to feel what an instant, near-free Bitcoin payment is actually like.