Quick answer
The Lightning Network is a protocol for updating bitcoin balances through payment channels whose enforceability ultimately depends on Bitcoin transactions. A user may pay across several channels without putting every update into a block, but this does not remove on-chain fees, channel-capacity constraints, custody choices, monitoring duties or failure risk. A safe evaluation starts with who controls the keys, how usable liquidity is obtained, what must remain online, and how recovery and closure work in the exact implementation.
Channel lifecycle and commitment states
Opening
Peers negotiate channel parameters and commit funds to an identified Bitcoin output. Channel type, reserve rules, fee responsibility, confirmation policy and feature support vary. Capacity is not the same as immediately usable balance in both directions, and a funding transaction can remain subject to the application’s confirmation policy.
Updating
Each side holds an enforceable commitment transaction representing its view of the channel. Updates replace an earlier state with a newer state and use revocation and HTLC rules so that publishing a superseded commitment can be penalized under the applicable commitment format. The protocol defines message and transaction requirements; a wallet’s user interface does not replace those rules.
Closing
A cooperative close uses a mutually agreed closing transaction. A force close publishes a commitment transaction and may delay an output with to_self_delay. Unresolved HTLCs can require additional transactions, timeouts or preimages. An obsolete-state publication can trigger the revocation path. All of these outcomes consume block space and depend on current on-chain conditions.
| State or event | Evidence to retain | What can still fail |
|---|---|---|
| Funding negotiation | Peer identity, channel type, contribution, fee and confirmation policy | Funding rejection, timeout, policy mismatch or delayed confirmation |
| Active channel | Current software state, channel point, balances, reserves and pending HTLCs | Peer outage, insufficient directional liquidity, route failure or state loss |
| Cooperative close | Negotiated closing transaction and destination verification | Peer non-cooperation, fee disagreement or on-chain delay |
| Force close | Published commitment, delayed outputs, HTLC status and response deadlines | Fee pressure, missed response, additional resolution transactions or loss |
Custody and control models
“Lightning wallet” describes several materially different arrangements. Ask who controls the channel keys, who chooses peers, who can close, who retains logs, who provides liquidity, and what claim the user has if an operator fails.
| Model | User controls | External dependencies and evidence |
|---|---|---|
| Custodial account | Account access, not the channel keys | Operator solvency, withdrawal policy, access controls, legal terms and incident response |
| Non-custodial mobile client | Keys under the implementation’s design | Document remote-service roles, connectivity, liquidity source, backup format and recovery limits |
| Self-operated node | Keys, peers, channels and operating policy | Operator must maintain software, chain data, liquidity, monitoring, backups and incident response |
Non-custodial does not mean dependency-free. A user may control keys while relying on hosted chain access, routing assistance, notification infrastructure or liquidity services. Each dependency needs a failure and privacy assessment.
Liquidity and routing
Outbound liquidity is the balance available to send from the user’s side of a channel. Inbound liquidity is capacity available for receiving toward that side. A multi-hop payment also needs compatible directional capacity and policy at every hop. A total wallet balance, public channel capacity or previous successful payment cannot establish that a new route will complete.
Record channel reserves, pending HTLCs, maximum and minimum payment constraints, fee policies, peer availability and route attempts. Rebalancing, opening another channel or obtaining inbound liquidity changes cost and counterparty exposure; it is not a universal fix.
Monitoring, watchtowers, backups and force closes
While a channel is open, its owner needs a path to learn about relevant on-chain spends and react within applicable timing rules. A watchtower can assist with a defined breach-response task, but its coverage, privacy, availability and recovery behaviour depend on the implementation and service design. It does not replace supported backups, chain access or an incident plan.
BOLT 2 defines peer re-establishment behaviour, including data-loss handling negotiated by supporting peers. It does not make arbitrary file copies safe. Preserve the exact software version, supported backup artifact, seed or key material, channel database procedure, peer-recovery assumptions and a tested restoration record. Never test recovery against live funds without an approved low-risk procedure.
A force close is an on-chain recovery path, not an error-free shortcut. The operator should know how to identify the commitment transaction, monitor delayed outputs and HTLCs, maintain fee funds, protect keys and escalate before any response window expires.
Fees and cost boundaries
Lightning costs can include routing fees, channel-opening and closing transactions, force-close and HTLC-resolution transactions, liquidity acquisition, swaps, service charges, custody charges and operational infrastructure. A quoted route fee does not include every lifecycle cost. On-chain fee conditions can change while a channel is open, affecting closure and recovery.
Protocol fulfillment, application accounting, on-chain confirmation and legal settlement are different states. Define which evidence the application accepts for each state instead of labeling every successful route “final.”
Privacy, security and failure modes
- Custody risk: an operator may restrict access, delay withdrawal, fail operationally or become subject to legal process.
- State risk: corruption, stale restoration, unsupported migration or lost key material can impair recovery.
- Availability risk: offline peers, failed infrastructure or impaired chain access can prevent payment or response.
- Liquidity risk: balance can exist without a usable route in the required direction.
- Fee risk: on-chain resolution may cost more or take longer than expected.
- Privacy risk: peers, services, network observers, invoices, logs and payment patterns can reveal different metadata.
- Application risk: invoice handling, amount verification, duplicate processing and accounting can fail outside the channel protocol.
- Software risk: implementation defects, incompatible features or unsafe defaults can affect funds.
Operational worksheet
- Who controls keys, channel state, peer selection, closing authority and account recovery?
- What channel type and features are active, and which pinned protocol rules and implementation documents apply?
- How are outbound and inbound liquidity obtained, measured, priced and renewed?
- What chain source, monitoring process, alert route and response deadline protect open channels?
- Which backup artifacts are supported, where are they protected, and when was restoration last tested?
- What happens during peer loss, device loss, database corruption, prolonged outage, fee pressure or operator failure?
- Which metadata reaches peers, infrastructure providers, custodians or observers, and how long is it retained?
- How are payment completion, refunds, accounting, tax and legal obligations recorded outside the protocol?
Pinned primary sources
Sources reviewed 29 August 2026. The protocol references below are pinned to repository snapshot 152897261850d93c4f4597f39cf22d7d22d6ede6. Recheck later specifications and the exact implementation documentation before operating funds.
- BOLT 2: peer protocol for channel establishment, updates, shutdown and re-establishment.
- BOLT 3: funding, commitment and HTLC transaction formats.
- BOLT 4: onion routing, hop payloads and failure messages.
- BOLT 5: on-chain handling and closing requirements.
- BOLT 7: routing gossip and channel-update policy.
- BOLT 11: invoice and payment-request encoding.
Frequently asked questions
Is a Lightning payment the same as an on-chain Bitcoin transaction?
No. A Lightning payment updates conditional balances across one or more channels. Opening, cooperative closing, force closing and some dispute or HTLC outcomes use on-chain transactions. The operational, fee and confirmation assumptions therefore differ.
Do I control the bitcoin in every Lightning wallet?
No. Control depends on the custody model. In a custodial account, the operator controls keys and channels and owes the user a balance. In a non-custodial design, the user controls channel keys, but the implementation may still depend on remote services for routing, monitoring, backups or connectivity.
Why can a Lightning payment fail even when my wallet shows a balance?
A displayed balance does not prove that a usable route exists in the required direction. Channel reserves, pending HTLCs, fees, route policy, offline peers, insufficient outbound or inbound liquidity and implementation limits can all prevent completion.
What happens when a channel is force closed?
A current commitment transaction is published on-chain. Some outputs may be delayed, HTLCs may need additional on-chain resolution and fees may be required. The exact sequence depends on the channel type, commitment state and implementation, so the user must follow the software recovery procedure.
Is a copied Lightning data directory a safe backup?
Not necessarily. Restoring stale live channel state can be dangerous. Peer re-establishment is specified at the protocol level, while backup and recovery formats are implementation-specific. Test the documented recovery path for the exact software without substituting an ordinary file copy for a supported backup.
Does Lightning make payments private or irreversible?
Lightning does not guarantee privacy. A successfully fulfilled payment generally has no payer-initiated protocol chargeback, but payment status, duplicate handling, refunds, channel resolution, underlying on-chain confirmation and legal treatment are separate questions. Different participants and observers can also learn different metadata.
