Bitcoin Lightning: what it is and how payments actually work

Bitcoin Lightning (the Lightning Network) is a layer-2 payment network built on Bitcoin. It lets participants send many bitcoin payments off the base chain, with speed and fees closer to a messaging network than to a global auction for block space — while still relying on Bitcoin scripts and on-chain settlement when channels open, close, or dispute.

It is still bitcoin, not a separate currency. What changes is where most balance updates live: inside payment channels between nodes, connected into a routable graph.

Specs live in the BOLTs (“Basis of Lightning Technology”): github.com/lightning/bolts. Overview site: lightning.network.

Click to zoom

Why it exists

Base-layer Bitcoin optimizes for decentralized settlement: limited block space, competitive fees, and confirmation delay measured in blocks (~10 minutes each, plus waiting for depth). That is a poor fit for:

• Retail / point-of-sale style payments
• Micropayments and pay-per-request APIs
• High-frequency back-and-forth between the same parties

Lightning moves those flows into channels so the chain is used as court and vault, not as the clearing house for every coffee.

Payment channels (the atomic unit)

Two parties fund a 2-of-2 output on Bitcoin (open channel). They each keep a current view of “how much is mine / yours” and update it by exchanging new signed commitment transactions — without broadcasting every update.

• Either party can close by publishing the latest valid state (cooperative close is cleaner; unilateral close uses the protocol’s delay / penalty design).
• Old states must not be safe to publish. Lightning’s security story makes broadcasting a revoked old state punishable (justice / penalty paths), so you need to watch the chain or use a watchtower if you go offline.
• Channel capacity is finite: you cannot receive more than your inbound liquidity allows, or send more than outbound balance.

On-chain:  open channel (fund 2-of-2)     ── occasional ──►  close / dispute
Off-chain:  Alice ⇄ Bob signed balance updates   (many, fast, cheap)

Alice ----channel---- Bob ----channel---- Carol
         pay Alice→Carol by updating both channels (HTLC path)

The network: multi-hop payments

You do not need a direct channel with every payee. Lightning routes across a path of channels (A→B→C), similar in spirit to packet routing: intermediate nodes forward conditional payments; they are not trusted custodians of the full path.

Atomicity is enforced with constructions in the BOLTs historically centered on HTLCs (hash time-locked contracts): either the whole path completes and everyone is made whole according to the contracts, or it fails back without silent loss of funds to a middle hop (within the protocol’s assumptions and timeouts).

Routing nodes may charge small fees. Pathfinding depends on public channel gossip, liquidity (much of which is not fully public), and implementation heuristics.

User-facing pieces

Properties (honest version)

Marketing sometimes says “millions of TPS.” Treat that as theoretical aggregate off-chain updates, not a guarantee for your invoice right now. Real limits are liquidity, connectivity, and reliable paths.

Builder and agent angle

Lightning is a natural rail for machine payments denominated in BTC:

• L402 (Lightning Labs; formerly LSAT-style flows) — HTTP 402 with Lightning payment proofs for API access (see also DevRels agentic payments landscape)
• Pay-per-article, pay-per-inference, metered APIs
• Cross-system micropay where both sides speak BOLTs

Compared with Solana agent rails (x402, stablecoin transfers, pay.sh-style HTTP settlement): Lightning settles BTC with a channel/liquidity model; Solana paths usually settle fast L1 or L1-equivalent txs in SOL/USDC with different UX (no channel graph for the user). Pick the rail that matches asset, audience, and ops (node/LSP vs RPC/wallet).

What Lightning is not

• Not a separate L1 token
• Not custodial by definition (though many wallets are)
• Not “always online optional” without watchtowers or a trusted party
• Not a full replacement for on-chain Bitcoin (cold storage, large final settlement, some contract patterns still want L1)

Minimal mental model

1. Open channel(s)     → lock BTC on-chain
2. Pay / get paid      → invoices + multi-hop HTLC updates off-chain
3. Rebalance / manage  → liquidity so you can keep receiving/sending
4. Close or dispute    → back to Bitcoin L1 as enforcer

Further reading

• BOLT specifications
• lightning.network
• Agentic payments landscape (includes L402)
• Solana fees vs revenue — different fee market, useful contrast for “what users pay”

Summary

Bitcoin Lightning is an off-chain network of payment channels that routes bitcoin transfers quickly and cheaply, using the Bitcoin blockchain to open, close, and police channels. Builders should think in channels, liquidity, invoices, and watchers — not in “TPS” slogans. For agent and API monetization it is one mature micropayment rail (including L402); for Solana-native stablecoin agents, other settlement paths may fit better. Same product need, different substrate.