The Lightning Network: Channels, Routing, and the Specs

The layer, and its rulebook

Lightning is a second layer. It moves payments across channels that sit on top of bitcoin’s blockchain, so the chain settles the framework while the payments fly between. The design is not folklore and not one company’s product. It is a written specification suite, the BOLT documents, whose own index enumerates the protocol parts from messaging to invoice encoding ^[1]. The repository’s README describes the suite as work in progress ^[2]. That self-description is kept here, because a reader deserves to know the specification set still moves.

The channel, in spec terms

A channel opens with an on-chain transaction. The spec’s transaction format names the part. The funding transaction output. A 2-of-2 structure: both parties must sign to spend it ^[1]. That shared output is the channel. Once it exists, the two parties pay each other by signing new balance arrangements. Between themselves. No blockchain transaction is needed per payment.

The chain reappears at the end. Only two things get recorded on the blockchain. The opening. The closing ^[1]. The spec also plans for trouble. It carries recommendations for on-chain handling when participants disagree or fail. The cross-signed transaction must then be spent ^[1]. Cooperative closes are one path. Unilateral exits are another. Time-bound remedies are a third. The spec plans for all of it. That tells a reader what kind of machine this is.

The fee correction this page carries

Older copy on this page said channel payments happen without having to pay fees or wait for confirmations. Half of that sentence is wrong as worded. The correction is protocol-grounded. Channel payments do avoid an on-chain fee per payment. They do avoid per-payment confirmation waits. But routed payments are different. Those are the ones that cross other parties’ channels. They pay Lightning routing fees. Nodes advertise those fees through the network’s gossip protocol ^[1]. On-chain fees apply at open and close. Free is not the mechanism. The mechanism is cheaper per payment, inside a structure with its own costs.

How a routed payment travels

A payment across multiple channels rides an encrypted route. The spec’s onion routing protocol defines the packet structure. It carries the payment instruction hop by hop ^[1]. The conditional payment primitive is the HTLC. A time-bound contract. It resolves, or it times out. The peer protocol specifies how one is added to a channel ^[1]. At the destination end sits an invoice. The spec describes it as stating the destination and purpose of a payment. The payer can later prove success ^[1].

The stack is worth naming because it answers a quiet question. Lightning payments are not broadcast like blockchain payments. They travel a path. Hop by hop. Under encryption. Conditional on a secret. That is a different machine from the layer below. The specifications are the difference, written down.

The network, on a dated read

A named analytics counter, 1ML, rendered the network on 12 September 2026. It read 5,910 nodes. 19,930 channels. 2,651.81 bitcoin of capacity ^[3]. The same page carried thirty-day deltas. Nodes down 1.52 percent. Channels up 1.39 percent. The counter is named because counters disagree. Node counts differ by explorer methodology. An older figure of 20,000 nodes still circulates from a 2023 snapshot. It reflects a different counter’s definitions. Not growth. Not collapse ^[3].

Two omissions are deliberate. Cumulative transaction counts do not appear. The named counter does not carry them. This library does not re-date what no source states. Capacity is stated in bitcoin, its native unit, on the read date.

The launch, as history

The network launched on bitcoin mainnet in 2018. That date is consensus history, kept as history. Nothing about the launch year predicts the next one, and this page’s snapshot is a read, not a trajectory.

What a channel demands of its parties

A channel is a relationship, not a button. Opening one costs an on-chain transaction at market fees. Keeping one means watching the chain, because the protocol’s remedies are time-bound. Closing one costs another on-chain transaction. The specifications define watch responsibilities and timeout rules for exactly this reason ^[1]. Software can automate the watching. The responsibility still belongs to the party whose funds sit in the channel. That shape is the honest cost of the layer’s speed, and it belongs on any page that describes the mechanism.

The channel model also bounds what a single channel can do. Payments between two parties flow both ways inside one channel, up to the funds each side has committed. Routing across the wider network is how payments exceed any one channel’s balance, and routing is where the fees and the path-finding live ^[1].

Where this page sits

The what is bitcoin page holds the layer below, the blockchain and its ten-to-sixty-minute confirmations, which is the cadence this layer exists to skip around. The mining explainer holds how the base layer settles. The chains hub covers the networks both layers run on, and the bitcoin hub is this page’s home root.