Lightning Network Payments, Explained: Bitcoin's Side Streets
Field Notes are researched and drafted by AHOS, an AI assistant, from the primary sources linked at the bottom of each article. They are not investment advice. How we work
Picture two neighbors opening a shared tab. They can update who owes what without writing every change into a public ledger. Later, they can settle the tab on Bitcoin's main chain. Lightning uses payment channels for off-chain bitcoin payments, with routes connecting people who do not share a direct channel.
The 10-second version
- A channel is a Bitcoin-backed connection between two participants. They can exchange payment updates inside it, then settle the channel state on the Bitcoin blockchain.
- An invoice tells the sender where and how to pay. If the sender and recipient are not directly connected, Lightning tries to route the payment through other channels.
- It is designed for quick, lower-cost payments, but the experience has conditions. Both sides need to be online for the payment cycle described in Lightning Labs' documentation, and a route can fail if channels lack suitable liquidity. Routing fees are not guaranteed to be zero.
A channel is a running tab
A Lightning channel starts with an on-chain Bitcoin transaction that anchors the arrangement. Funds are locked under rules shared by its two participants. They can update the balance without putting each payment onto the Bitcoin blockchain as a separate transaction.
The blockchain remains the settlement layer: it records the opening transaction and can be used to settle the channel's final state. Opening or closing a channel may involve on-chain transactions, confirmation time, and fees. Day-to-day channel updates do not publish a fresh on-chain transaction for every payment.
A cafe example: a customer pays for several coffees through a channel, and the balance shifts. If they later close it, the resulting balances can be settled on Bitcoin's chain. No separate on-chain transfer is needed for each cup.
Invoices and routes
To request a payment, the recipient creates an invoice. It can include an amount, a destination, validity information, and payment data. The sender passes that invoice to a Lightning node or service, which looks for a route through connected channels.
If the sender has a direct channel to the recipient, the route may be one hop. Otherwise, intermediate nodes can forward the payment along a path. Routing nodes may earn a fee for forwarding. Lightning Labs describes these fees as configurable: a node operator can set a base fee, a proportional fee, or both for a channel. Those settings can change. So a payment can be inexpensive, but "Lightning is always free" is not a safe promise.
Multi-hop payments are designed to complete along the route or fail as a whole. That does not promise a route will always be available or remove operational risks in a user's setup.
Liquidity: the money has to be on the right side
A channel has a finite capacity, and its balance is split between its two sides. To send money in one direction, the route needs enough spendable balance in that direction across each hop. A channel can have plenty of total capacity and still lack enough liquidity on the side needed for a particular payment.
Public network information describes channels and advertised policies, but cannot guarantee every node is online or has usable balance when you pay. Nodes may try several paths; routing can still fail for lack of liquidity. That is different from the Bitcoin chain rejecting an on-chain transaction.
Online, quick, and not magic
Lightning Labs' payment-cycle guide says the sender and receiver need to interact and be online at the same time for the described payment flow. Some payments may need route attempts, meet temporary availability problems, or fail for lack of liquidity. So "near-instant" describes a capability, not a guarantee for every payment.
When a payment succeeds, channel balances update off chain; the Bitcoin blockchain does not record each routed payment individually. It anchors channels and provides a way to settle them. Wallets and services can differ in how they expose the network.
Sources
- Lightning Labs: Payment Channels — read October 17, 2026.
- Lightning Labs: Lifecycle of a Payment Channel — read October 17, 2026.
- Lightning Labs: The Lightning Network Overview — read October 17, 2026.
- Lightning Labs: The Payment Cycle — read October 17, 2026.
- Lightning Labs: Channel Fees — read October 17, 2026.
This is a protocol explainer, not price, investment, legal, or tax advice. Spot a mistake? Tell us and we will fix it and say so here.