Lightning Network

The Lightning Network is a network of bidirectional payment channels built on top of Bitcoin. Participants lock bitcoin in channels and can update the allocation of those funds without recording every payment on the Bitcoin blockchain. Only transactions that open, close or enforce a channel normally require base-layer confirmation.

Lightning is intended for frequent, comparatively small payments where lower latency and lower fees are useful. It does not increase Bitcoin's base-layer block capacity. Instead, it reduces the need to publish each intermediate balance update, while introducing liquidity, availability, routing and software risks that differ from an ordinary on-chain payment.

Design

Payment channels

Two participants open a channel with an on-chain funding transaction. The funding output requires the channel parties to follow the protocol before it can be spent. They then exchange signed commitment transactions that represent the latest division of the channel balance. Each valid update replaces the prior state without being broadcast to the blockchain.

For example, Alice and Bob may fund a channel whose current balance assigns 0.06 BTC to Alice and 0.04 BTC to Bob. If Alice pays Bob 0.01 BTC, they sign a new state assigning 0.05 BTC to each. They can continue updating the balance while the channel remains open; the intermediate payments do not each become separate on-chain transactions.

The protocol discourages a party from broadcasting an obsolete commitment transaction. In the traditional penalty-based channel design, the other party has a time-limited opportunity to claim the channel funds when an old state is used. This is why a noncustodial Lightning user must monitor the blockchain or arrange monitoring by another service.

Routed payments

Alice does not need a direct channel with every recipient. If Alice has a channel with Bob and Bob has sufficient outbound liquidity in a channel with Carol, a payment can pass from Alice to Carol through Bob. Real payments may use several intermediate nodes.

Hashed Timelock Contracts (HTLCs) link the transfers along a route. The recipient releases a cryptographic secret that permits the route to settle; otherwise the transfers expire according to their timelocks. This construction lets intermediate nodes forward a payment without taking custody of the sender's funds, although each forwarding node may charge a fee.

Lightning's interoperable wire and channel protocol is described by the Basis of Lightning Technology specifications, known as the BOLTs. The specifications cover peer messaging, channel transactions, onion routing, network gossip, invoices and feature negotiation.

Liquidity and routing

A channel can send only the balance available on the sender's side, and receive only to the extent that capacity exists in the reverse direction. A route must have sufficient directional liquidity at every hop. The total advertised capacity of a channel or the network is therefore not the amount that any arbitrary user can send.

Nodes can obtain inbound liquidity by receiving payments, opening or rearranging channels, using submarine swaps, or purchasing channel liquidity from a Lightning service provider. Some providers can open a just-in-time channel when the client's first incoming payment arrives, rather than requiring the client to purchase a channel in advance. Operators may also rebalance funds between their own channels. These actions have costs and can require on-chain transactions.

Routing is probabilistic because exact channel balances are not globally announced and may change while a payment is attempted. A sender generally learns whether a proposed route works only by trying it. Wallets may retry with a different route or divide a payment into multiple parts. A successful Lightning payment can complete in seconds, but failed attempts, unavailable peers or inadequate liquidity can increase latency.

Channel closing and enforcement

A channel has no mandatory short lifetime and can remain open while both parties continue to cooperate. In a cooperative close, both parties agree on the final balance and broadcast a closing transaction. This is usually faster and more fee-efficient than unilateral enforcement.

If a peer is unavailable or refuses to cooperate, the other party can force close by broadcasting its latest commitment transaction. Timelocks delay access to some outputs and the close consumes block space and on-chain fees. The delay allows the counterparty to respond if an obsolete state was published.

Monitoring can be delegated to a watchtower. A watchtower watches the blockchain for an outdated channel close and can broadcast a penalty or recovery transaction for its client. It does not need custody of the client's funds, but its availability and the wallet's correct preparation of remedy data remain part of the security model.

Backups require special care. Restoring an obsolete channel database is not equivalent to restoring a normal on-chain wallet and can cause a peer to treat the node as publishing stale state. Implementations provide recovery mechanisms, but users and node operators must follow the backup procedure for their particular software.

Speed, fees and blockchain load

Payments in an established, sufficiently liquid route can settle without waiting for a new Bitcoin block. This makes Lightning suitable for point-of-sale payments and other interactions where an on-chain confirmation would be too slow. It can also support amounts that would be uneconomic to send as individual base-layer transactions.

Lightning payments are not necessarily free. A forwarding node can charge a fixed base fee, a proportional fee, or both, and a wallet may impose its own policy. Users also bear on-chain fees when opening or closing channels, directly or through a service. The economic advantage depends on payment size, route, liquidity and prevailing base-layer fees.

Because most balance updates remain off-chain, only funding, closing and enforcement transactions normally add to the Bitcoin ledger. This reduces base-layer load per payment when a channel is reused many times, but it does not eliminate the need for Bitcoin block space or alter Bitcoin's consensus rules.

Privacy and trust

BOLT onion routing gives each forwarding node only the information needed to identify the previous and next hop and process its part of the payment. An intermediate node ordinarily does not receive the complete route. This is a privacy improvement over publishing every payment on the public blockchain, not a guarantee of anonymity: channel openings and closures are public, and timing, amount, network or endpoint observations may reveal relationships.

Two peers operating their own channel do not give a routing intermediary unilateral control of their channel funds. However, actual trust depends on the wallet model. A noncustodial wallet gives the user control of keys and requires the user or a delegated service to meet protocol obligations. A custodial Lightning wallet can hide channel management but requires trust in the provider's solvency, security and withdrawal policy.

Implementations

Several independently developed implementations use the common BOLT specifications. Major implementations include LND by Lightning Labs, Core Lightning under the Elements Project, Eclair by ACINQ and the Lightning Development Kit libraries. Interoperability reduces dependence on one codebase, but implementations have different APIs, storage formats, operational models and release schedules.

Core Lightning, formerly called c-lightning, is an open-source implementation that has operated on Bitcoin mainnet since 2018. In 2026, maintainers disclosed two remotely triggerable memory-exhaustion denial-of-service defects. The connectd issue was fixed in version 26.04 and the gossipd issue in the 26.06 release-candidate line. The defects affected node availability rather than changing the Lightning protocol itself. Operators should follow the security and upgrade guidance for their chosen implementation.

An additional August 2026 report about a possible Lightning implementation vulnerability is not included as an established fact here because no matching maintainer advisory, technical disclosure or patched release was publicly available when this draft was prepared.

Limitations and failure modes

Lightning's main trade-offs include:

• Liquidity constraints: a payment can fail even when the sender owns enough bitcoin if no route has sufficient capacity in the required direction.
• Online availability: peers and routing nodes need network availability for normal forwarding. Receiving while offline requires wallet- or service-specific support.
• Channel monitoring: noncustodial users must detect obsolete closes themselves or use a watchtower.
• On-chain dependence: opening and enforcing channels depend on Bitcoin confirmation and fee conditions; congestion can make urgent closes expensive.
• Operational complexity: routing nodes manage capital, connectivity, backups, upgrades and fee policy. Custodial services simplify this at the cost of counterparty risk.
• Payment reliability: routes can fail because of stale network information, unavailable nodes, size limits or changing liquidity.

Lightning is therefore a complementary payment layer, not a replacement for Bitcoin's settlement layer.

History

Joseph Poon and Thaddeus Dryja published the Lightning Network paper in 2015. The design built on earlier work on Bitcoin payment channels and added routed, bidirectional channels using hashlocks and timelocks.

Developers of the c-lightning, Eclair and LND implementations demonstrated cross-implementation payments in 2017. LND released its first Bitcoin-mainnet beta in March 2018, and all three implementations had beta releases by June 2018. Subsequent work has improved routing, multipart payments, watchtowers, channel management, mobile support and protocol extensions.

See also

• Bitcoin transaction
• Payment channels
• Hashed Timelock Contracts
• Off-Chain Transactions
• Segregated Witness

External links

• Lightning protocol specifications
• Original Lightning Network paper