Lightning is a protocol for moving bitcoin through a network of bilateral payment channels. It does not create a separate coin or a separate proof-of-work blockchain. Instead, it uses Bitcoin transactions to lock funds into channel structures, then lets channel participants update how those funds could be settled without publishing every update to the Bitcoin blockchain.
Why Lightning exists
Bitcoin block space is limited and globally replicated. Every confirmed on-chain transaction must be validated by nodes and included in a block. That design supports independent verification, but it also means that frequent small payments compete for the same block space as other transactions.
Lightning changes the payment workflow. Two parties can create one on-chain funding transaction, exchange many off-chain state updates, and later close the channel with another on-chain transaction. When payments cross several channels, the participants can transfer value without each pair needing a direct channel.
This can reduce routine on-chain use and shorten the time between payment initiation and an off-chain result. It does not eliminate Bitcoin fees, confirmation risk, channel management, or the possibility that a payment fails.
A channel is anchored to Bitcoin
A Lightning channel begins with a Bitcoin funding output. In the common design, that output can be spent only under the channel's agreed transaction and signature rules. The funding transaction must reach the confirmation state required by the participants or their software before the channel is treated as usable.
The amount locked into the funding output limits the channel's total capacity. Capacity is not the same as either participant's spendable balance. If Alice and Bob open a channel with 1,000,000 satoshis, the local and remote balances describe how that capacity is currently allocated from one participant's viewpoint.
A channel balance is not a global account balance stored by the Lightning Network. It is a local interpretation of the latest enforceable channel state held by the two channel peers.
Commitment states update the allocation
Each participant holds a commitment transaction representing a current settlement state. As the channel balance changes, the peers exchange messages and signatures that make a newer state enforceable and make an older state unsafe to publish.
In the traditional penalty-based channel design described by the BOLT specifications, old commitment states can be punished if broadcast. Revocation secrets allow the honest peer to claim funds from a revoked state during a defined contest window. This is why channel software must preserve current state and respond to chain events.
The exact transaction format can vary with negotiated features and implementation support. Proposed channel types, including designs that change how old states are invalidated, should not be treated as universally deployed.
Cooperative and unilateral closes
A cooperative close happens when both peers agree on a final allocation and sign a closing transaction. It can usually avoid the delay and extra script paths associated with a disputed close.
A unilateral close happens when one peer publishes an enforceable commitment transaction without the other's cooperation. This may be necessary when a peer is offline, unresponsive, or disputed. The resulting outputs can have time delays and additional on-chain transactions. The user must account for Bitcoin fees and confirmation uncertainty.
A unilateral close is not a protocol failure. It is part of the enforcement model. Off-chain updates remain credible because either participant can ultimately use Bitcoin transactions and script conditions to settle.
Routed payments connect channels
A payer does not need a direct channel with the recipient. A payment can travel through a sequence of channels. The sender or sender's software selects one or more candidate paths using known public channel information, private channel hints, local observations, and prior failures.
Suppose Alice has a channel with Bob, Bob has a channel with Carol, and Carol has a channel with Dana. Alice can attempt to pay Dana through Bob and Carol. The intermediaries forward conditional transfers rather than trusting Alice or Dana.
Public gossip can describe channels, advertised capacities, fee policies, and time-lock parameters. It cannot reveal exact usable liquidity in each direction. A public channel may have enough total capacity but insufficient outbound balance for the attempted direction.
Onion routing limits what intermediaries learn
Lightning uses onion routing so each forwarding node learns the instructions needed for its own hop rather than the complete route. The sender constructs an encrypted packet whose layers are removed one at a time.
An intermediary can generally identify the peer from which it received a forwarding request and the peer to which it should forward. It does not automatically learn the full route. However, privacy is not absolute. Timing, amounts, network topology, repeated attempts, route position, wallet behavior, and observation by coordinated parties can reveal information.
A custodial provider may also know more about a payment because it controls the user's account and payment execution.
HTLCs make forwarding atomic
Hashed Time Locked Contracts, or HTLCs, coordinate conditional payments across channels. The recipient releases a preimage whose hash matches the payment hash. Each forwarding node receives that preimage from its outgoing peer, uses it to fulfill the corresponding incoming HTLC from its upstream peer, and relays the fulfillment upstream.
If a route fails before fulfillment, nodes can return failure messages and remove the HTLCs through off-chain state updates. If an HTLC remains unresolved, staggered time locks provide timeout paths and enough margin for intermediaries to act on-chain when necessary.
The intended result is atomic payment behavior across the route: the payment settles through the path, or the linked conditional transfers are removed or timed out. Failure handling is not always immediate, and on-chain resolution can take longer when a channel closes.
Newer payment constructions may change some details, but an educational model should not assume they are universally supported.
Invoices and payment requests
A Lightning invoice is a payment request that can include a destination, payment hash, amount, expiry, description information, feature bits, and routing hints. BOLT 11 defines the widely used invoice format. BOLT 12 defines a separate negotiation flow using offers, invoice requests, and invoices. Wallet and implementation support must be checked rather than assumed.
An invoice is not proof that the recipient is trustworthy. It is structured payment data. Wallet software must validate the invoice, supported features, expiry, amount, and network before attempting payment.
Some payments use spontaneous or keysend-style behavior supported by particular implementations. That is not a substitute for describing the standard invoice workflow.
Routing fees
Forwarding nodes can advertise a base fee and a proportional fee. They may also set minimum and maximum HTLC values and a required time-lock delta. The sender estimates the total route cost from these policies.
Lightning fees are not universally zero. A payment may also create indirect costs from channel opening, closing, rebalancing, swaps, service charges, or failed attempts. Fee policy can change, and an advertised fee does not guarantee that the route has liquidity.
Inbound and outbound liquidity
Outbound liquidity is the amount a node can send from its side of channels, subject to reserves, pending HTLCs, fees, and implementation rules. Inbound liquidity is the amount that remote channel balances can deliver toward the node.
Receiving bitcoin over Lightning often requires inbound liquidity. Opening a channel by funding it entirely from the user's wallet usually creates outbound liquidity first. Inbound liquidity can arise when the user spends through the channel, receives a channel opened by another party, uses a swap or liquidity service, or participates in another rebalancing arrangement.
Capacity does not reveal direction. A channel advertised as 2,000,000 satoshis may have almost all usable balance on one side.
Pathfinding is uncertain
The sender constructs routes from incomplete information. Public gossip does not publish balances. Private channels may be disclosed only through invoice hints or other route information. Pending payments can temporarily reduce available liquidity.
A payment may fail because a channel lacks directional liquidity, a peer is offline, a fee changed, a time-lock condition is unacceptable, a channel update is stale, the recipient invoice expired, or an implementation rejected a feature.
Wallets may retry with another route, split a payment into parts, or ask for updated information. Fast payment interfaces do not guarantee successful payment. A successful payment also does not prove that every attempted route was private.
On-chain enforcement connects Lightning to Bitcoin consensus
Lightning nodes enforce channel agreements by holding valid Bitcoin transactions, signatures, secrets, and timing information. If cooperation stops, a participant can publish a transaction and rely on Bitcoin nodes to validate it under Bitcoin consensus rules.
Bitcoin consensus does not validate the full history of ordinary Lightning state updates. It validates the funding, closing, and enforcement transactions that reach the blockchain. The Lightning protocol defines how peers create and update those possible Bitcoin spends.
This boundary matters. Lightning implementations can change routing, gossip, invoices, channel management, and user interfaces without changing Bitcoin consensus. A proposed Lightning feature that needs a new Bitcoin opcode or transaction behavior would require a separate Bitcoin upgrade process.
Custody and service arrangements differ
A custodial Lightning wallet records a provider-managed account. The provider controls the relevant keys or channels and decides how payments are executed. The user depends on the provider's solvency, availability, policy, and withdrawal process.
A self-custodial Lightning arrangement gives the user control of the signing authority needed to enforce or recover channel funds without a provider's permission. Operations can still vary. The wallet may run a node on the device, connect to a user-controlled remote node, or use third parties for liquidity, swaps, routing data, encrypted backups, or infrastructure that does not take control of the user's signing authority. Provider-controlled accounts and hosted balances belong in the custodial category because the provider can control payment execution or withdrawal.
A Lightning node maintains channels and protocol state. A Lightning service provider may supply liquidity, routing, channel opening, node hosting, swaps, or payment processing. These roles should not be collapsed into one label.
A wallet interface alone does not prove self-custody. Users must examine who controls keys, who can close channels, where backups live, and which service can block or observe activity.
Monitoring and watchtowers
Penalty-based channels require attention to the Bitcoin chain because an old commitment transaction could be published. A node can monitor directly or delegate limited detection and response data to a watchtower.
A watchtower is designed to help broadcast a remedy transaction when it detects a revoked state. The design can limit what the tower learns before a breach, but privacy and availability depend on the specific protocol and implementation.
Watchtowers do not remove the need for backups or guarantee recovery from every failure. Channel state loss, incompatible backups, fee conditions, data corruption, and unavailable services can still create risk.
Practical privacy limits
Lightning avoids placing every payment on the public Bitcoin ledger, but off-chain does not mean invisible. Route participants see local information. Recipients learn payment details. Senders choose routes and may learn failure locations. Service providers can collect network and account metadata.
Channel openings and closes are on-chain and can sometimes be identified or correlated. Probing can estimate channel liquidity. Reused invoices, repeated amounts, IP exposure, and centralized service use can weaken privacy.
Privacy depends on implementation behavior, network position, wallet configuration, routing choices, and adversary capabilities. It should be treated as a set of tradeoffs rather than an automatic guarantee.
The working model
Lightning is a network of bilateral Bitcoin channels. Channel peers update enforceable settlement states. Senders route conditional payments through channels using onion-encrypted instructions. HTLCs and timeouts coordinate atomic behavior. Liquidity direction and path uncertainty determine whether an attempted route works.
The system can make frequent payments without publishing every state update. It remains connected to Bitcoin through funding, closing, and enforcement transactions. That connection supplies the settlement boundary, while Lightning's own peer protocols govern the off-chain work.