A channel is a changing Bitcoin contract
Two parties commit bitcoin to an on-chain funding output and keep signed commitment states describing how that value can be settled. As they pay, they replace the current state with a newer one instead of broadcasting every update. A cooperative close publishes a final settlement transaction; a unilateral close can enforce the latest valid state under protocol rules.
Lightning therefore does not create separate coins or remove the base layer. It moves frequent balance updates off-chain while retaining an on-chain enforcement route. Opening, closing and exceptional resolution consume block space and require appropriate fees.
A payment can cross several channels
The sender does not need a direct channel with the recipient. A wallet searches for a route through forwarding nodes. Hash Time-Locked Contracts make the linked transfer atomic: either the required condition completes the payment along the route, or the attempted parts fail and unwind rather than leaving a normal partial payment.
Onion routing limits what each forwarding node learns: it mainly knows the adjacent hop and its instructions, not necessarily the full route. This improves privacy but does not make Lightning perfectly anonymous; timing, amounts, endpoints and wallet-service data can still reveal information.
- the receiver creates or supplies a payment instruction
- the sender's wallet searches for a route
- the transfer either settles in full or fails
Liquidity has a direction
A channel's total capacity is not the same as the amount one side can send or receive. If most of the balance is already on the remote side, the local node may have little outbound liquidity; if it is mostly local, receiving may require inbound liquidity. Routes fail when any hop lacks enough usable balance or is offline.
Wallets may manage channels and liquidity automatically, use a Lightning service provider, or expose controls to the user. A failed attempt does not necessarily mean the network or invoice is invalid; another route or liquidity change may succeed. Fees can include base and amount-proportional components set along the route.
Invoices are payment instructions, not addresses forever
The widely used BOLT 11 invoice can encode a network, amount, payment hash, destination information and expiry. Some fields are optional. The payer should check the displayed recipient, amount and expiry in the wallet, just as an on-chain payer checks destination and value.
Lightning is suited to smaller, rapid payments, but finality and recovery expectations differ from card payments. Once settled, there is no built-in chargeback authority. Begin with small values and use on-chain Bitcoin when the wallet, recipient or risk profile does not support the intended Lightning operation.