How Lightning Network Payment Channels Actually Work

The Lightning Network is a "layer 2" system built on top of Bitcoin that lets two parties exchange payments instantly and cheaply by opening a private payment channel, transacting off-chain as many times as they like, and only touching the Bitcoin blockchain to open and close that channel. It solves Bitcoin's throughput problem without changing the base protocol.

To understand why this matters, it helps to remember what Bitcoin's base layer is good at and what it isn't. On-chain transactions are secure and final, but every transaction must be broadcast to the network and included in a block, which takes minutes and costs a fee that rises with demand. That's fine for settling large amounts, but impractical for buying a coffee. Lightning was designed to fix exactly this, and it's a useful companion piece to understanding what is Bitcoin at a technical level.

Opening a channel

A Lightning channel starts with a funding transaction: two participants each (or one of them) lock up bitcoin into a 2-of-2 multisignature address on the main chain. This transaction is confirmed on-chain like any other, so it costs a normal fee and takes normal confirmation time. Once confirmed, the channel is "open," and its balance is split between the two parties according to how much each contributed.

From this point forward, nothing needs to touch the blockchain again until the channel closes. The two parties simply exchange signed messages that update how the locked funds are divided between them. Each update effectively says "the balance is now X to me and Y to you," replacing the previous split. Only the latest, most recent balance state matters, and both sides hold a signed version of it as proof.

Updating balance without broadcasting

Every time a payment moves across the channel, both parties sign a new commitment transaction reflecting the updated split, and they invalidate the previous one through a revocation mechanism. This is the clever part: if one party tried to cheat by broadcasting an old, more favorable balance, the other party can prove it was revoked and claim the entire channel balance as a penalty. This game-theoretic backstop is what keeps channels honest without needing a trusted intermediary, similar in spirit to how proof-of-stake systems use economic penalties to enforce honest behavior, though the mechanisms are different.

Routing payments with HTLCs

Most Lightning payments don't happen between two directly connected parties. Instead, they hop across a network of channels, and this is where Hash Time-Locked Contracts (HTLCs) come in. An HTLC is a conditional payment: it says "I will pay you this amount if you can produce the secret (a cryptographic preimage) within a certain time window, otherwise the funds return to me."

Here's the flow in plain terms:

1. The recipient generates a secret and gives its hash to the sender (usually embedded in an invoice).
2. The sender creates an HTLC on the first channel hop, locked to that hash.
3. Each intermediate node forwards a matching HTLC to the next hop, each with a slightly shorter time lock.
4. When the HTLC reaches the recipient, they reveal the secret to claim their payment.
5. That secret propagates backward, allowing every intermediate node to claim their own HTLC in turn.

Because every hop's HTLC uses the same hash, either the whole chain settles or none of it does — nobody can be left holding a claim they can't redeem. This atomicity is why Lightning can route payments through strangers without a central custodian.

Liquidity and routing limits

A channel only has bandwidth in the direction it has funds. If you opened a channel by depositing 0.01 BTC, you can send up to that amount to your channel partner, but you can't receive more than they've committed until the balance shifts back. Multi-hop routing has to find a path where every intermediate channel has enough capacity in the right direction, which is why larger or less common payments sometimes fail to route even though the network overall has plenty of liquidity.

Closing a channel

Closing can happen cooperatively, where both parties sign a final on-chain transaction reflecting the last agreed balance, or unilaterally, where one party broadcasts their latest commitment transaction and waits out a dispute window in case the other side tries to contest it with a revoked state. Cooperative closes are cheaper and faster; unilateral closes exist as a safety valve when a counterparty is unresponsive or acting in bad faith.

Comparing channel states

Stage	On-chain action	Speed	Trust model
Open channel	Funding transaction	Minutes (1 confirmation+)	Trustless multisig
Send payment	None	Instant	HTLC + penalty enforcement
Route payment	None	Seconds	Chained HTLCs across hops
Close channel	Settlement transaction	Minutes to days (if disputed)	Trustless, on-chain arbitration

Bottom line

Lightning payment channels work by moving the bulk of transaction activity off-chain while keeping Bitcoin's blockchain as the final arbiter for opening, closing, and resolving disputes. HTLCs are the glue that make multi-hop routing safe without a trusted middleman. If you're evaluating whether to use Lightning, understanding this mechanic explains both its strengths (speed, low fees) and its practical limits (liquidity constraints, the need for channels to be funded before use). For a broader comparison of how this stacks up against sending Bitcoin directly, see our piece on Lightning Network vs on-chain Bitcoin, and if you're new to custody concepts generally, our glossary entry on wallets is a good starting point.