How the Bitcoin Lightning Network Works

The Bitcoin Lightning Network is a payment system built on top of Bitcoin. It lets people send bitcoin through payment channels without recording every payment as a separate transaction on Bitcoin’s main blockchain. The blockchain still matters: it is used to establish channels and, when needed, settle their final balances.

A useful comparison is a tab between two people. Instead of settling every small purchase individually, they keep track of who owes what and settle the final amount later. Lightning channels do this with cryptographic transactions, not an informal promise. Either participant can use Bitcoin’s base layer to close a channel and claim their valid balance, subject to the protocol’s rules.

Lightning is designed for payments that benefit from speed and frequent transfers, including small payments. It does not make Bitcoin’s base layer faster, and it does not turn every bitcoin into a Lightning balance automatically. Funds have to be available in channels with suitable liquidity, and users need a Lightning-compatible wallet.

In short, Lightning shifts much of the activity off-chain while relying on Bitcoin for final settlement and dispute resolution. That can reduce the need for an on-chain transaction per payment, but adds its own requirements and trade-offs.

To open a channel, two participants agree to lock bitcoin into a shared on-chain output, commonly controlled by a two-of-two multisignature arrangement. Both participants must authorize the funding transaction. Because that transaction goes on Bitcoin’s blockchain, opening a channel can take time and incur an on-chain fee.

The channel’s capacity is the total bitcoin committed to it. Capacity is not the same as the amount either person can currently send. If Alice funds a channel with Bob, Alice initially has most or all of its outbound balance, while Bob may have little or no capacity to send back to Alice. Payments shift the channel’s balance between them without broadcasting every change to Bitcoin.

The participants maintain signed transactions reflecting the current distribution of funds. These channel updates are often called commitment states. They give each side a way to close the channel and claim funds according to the latest valid state. The channel is not a separate coin or a new Bitcoin; it is an arrangement for controlling and updating bitcoin already locked on-chain.

A wallet may open a channel automatically or rely on channels managed by a service. Either way, channel funding ties up bitcoin for Lightning use until the channel is closed or otherwise rebalanced.

After a channel is open, a payment changes the channel’s agreed balances. Suppose Alice pays Bob: the participants update the channel state so Alice has less bitcoin available to send and Bob has more. They exchange the signatures needed to support the new state. The update is handled between the participants and does not normally create a Bitcoin blockchain transaction.

A payment is not simply an editable spreadsheet entry. Channel states are backed by signed Bitcoin transactions, and the protocol is designed to prevent a participant from successfully claiming an outdated balance after the other has agreed to a newer state. Revocation mechanisms and time limits help enforce the current state. If a participant tries to cheat, the other side may have a limited period to respond and claim funds, which is one reason wallet availability and channel monitoring matter.

Once a channel closes, its final balance can be settled on-chain. Participants may close cooperatively by agreeing on a settlement, or one side may initiate a unilateral, sometimes called force, close. A unilateral close can involve a waiting period before some funds can be spent, and it may cost more in blockchain fees than a cooperative close.

This design allows repeated channel payments while avoiding a separate on-chain transaction for each one. The trade-off is that users depend on channel state management and the ability to settle correctly when necessary.

Lightning is a network of channels, not just a collection of pairs who each need a direct connection. If Alice has a channel with Carol and Carol has one with Bob, Alice may be able to pay Bob through Carol. The payment passes through a route of connected channels, with each intermediary forwarding it according to the protocol.

To find a route, wallets use information about the network’s channels and fees, though not every channel or its usable balance is publicly visible. A route must have enough liquidity in the right direction at each step. A channel can have plenty of total capacity but still lack enough balance for a particular payment to pass through it.

Lightning uses hashed time-locked contracts, or HTLCs, to make multi-hop payments conditional. In simplified terms, the recipient reveals a secret needed to claim the payment, and that secret lets the preceding participants complete their parts of the transfer. Time limits give participants a way to recover funds if the payment does not complete. This design aims to prevent an intermediary from simply keeping a payment that fails partway through.

Routing nodes can charge fees for forwarding payments. They do not necessarily take custody of the sender’s entire balance, but they do participate in the conditional payment process. A route can fail if a channel is unavailable, has insufficient directional liquidity or cannot meet the payment’s requirements.

A Lightning payment usually starts with a payment request, such as an invoice generated by the recipient’s wallet. It can specify an amount, identify the destination, include a payment hash and set an expiry. The sender’s wallet reads the request, finds a route and shows the amount and any available fee details before asking for confirmation. Exact steps vary by wallet.

The recipient’s wallet creates the request and waits for a matching payment. When the payment succeeds, the wallet can mark the invoice as paid. An expired or already-paid invoice should not be reused. Some payment methods can support requests without a fixed amount or additional ways to address a recipient, but compatibility depends on the wallets and services involved.

Check the currency unit carefully. A Lightning wallet may show bitcoin in BTC or in satoshis, often shortened to sats. One bitcoin equals 100 million sats, so a small payment may be easier to read in sats. Confirm the amount, recipient details and any displayed fee before sending; a payment sent to the wrong destination may be difficult or impossible to recover.

The payment request is not the same as an on-chain Bitcoin address. An on-chain address cannot generally be paid directly as a Lightning invoice, and a Lightning invoice is not an on-chain withdrawal address. Some wallets offer conversion or swap services between the two, but those are separate features with their own terms and fees.

Lightning fees can include more than one cost. A routing node may charge a forwarding fee, often made up of a fixed amount and a rate based on the payment size. Wallets may choose routes with different fees, and providers can add their own service or conversion charges. Fee policies and estimates vary, so check the confirmation screen rather than assuming a payment is free.

There can also be Bitcoin on-chain fees. Opening a channel requires a funding transaction, and closing one may require a settlement transaction. The cost depends partly on Bitcoin network conditions and the transaction’s size. If a wallet manages channels for you, its service model may affect how these costs are handled or presented.

Liquidity is a separate practical constraint. To send bitcoin through a channel, the route needs enough outbound liquidity at each hop. To receive, a user needs inbound liquidity: capacity on channels that can move funds toward their wallet. A newly funded channel may be well set up for sending but not for receiving, depending on how it was opened and how its balance has changed.

Wallets and services may offer ways to add or rebalance liquidity, but those options can have costs and may require additional transactions or providers. A failed payment does not necessarily mean funds are lost; it may mean no suitable route was available. Before relying on Lightning for a specific payment, check that your wallet supports the payment and has adequate liquidity.

Lightning offers a different set of trade-offs from paying directly on Bitcoin. It can support frequent off-chain payments without recording every one on the blockchain, but it requires channels and working payment routes. Bitcoin on-chain transactions are more direct to verify on the base layer, but they can take longer to confirm and their fees vary with demand.

Feature	Lightning	Bitcoin on-chain
Where most payment activity happens	Within channels, off-chain	On Bitcoin’s blockchain
Typical payment path	Through one or more channels	From one on-chain address to another
Main practical constraint	Route and directional liquidity	Confirmation time and network fee
Settlement	Channel balance, with on-chain close when needed	Blockchain transaction

Lightning can be useful for smaller or repeated payments, but it is not automatically the right choice for every transfer. Large payments may be difficult to route if channels lack sufficient liquidity, and a payment can fail even when the sender’s wallet shows a Bitcoin balance. Lightning balances also should not be confused with funds immediately available for on-chain spending.

The two systems are complementary. Lightning depends on Bitcoin for channel funding and settlement, while Bitcoin’s base layer provides a fallback for closing channels. A wallet may offer both payment types, so check which network or method is selected before sending or receiving.

Lightning’s security depends on using a wallet that correctly manages channel states and on-chain settlement. Self-custodial wallets give users control of their keys, but that means users need to protect recovery information and use reliable software. A custodial wallet is easier to operate in some ways, but the provider controls the funds and the user depends on its policies, solvency and availability.

Some channel designs require a wallet or a monitoring service to notice an attempted stale-state close during a response window. Watchtowers can monitor for certain channel events on a user’s behalf, but they do not eliminate every risk or replace safe wallet practices. Keep wallet software updated, protect recovery data from theft and avoid sharing seed phrases or signing requests you do not understand.

Lightning can improve payment privacy by keeping routine channel updates off the public blockchain, but it is not a guarantee of anonymity. Routing information, wallet providers, payment counterparties and network observers may learn details. Channel funding and closing transactions are visible on-chain, and public channel information can reveal aspects of network connectivity.

There are also operational risks: a route may fail, a provider may be unavailable, and a force close may be more complex or costly than expected. Start with an amount you can afford to risk while learning the wallet. Verify the recipient and payment details, understand whether you are using a custodial service, and know how the wallet handles backups and channel closure.

Before sending, check that both wallets support Lightning and confirm whether the recipient expects a Lightning payment or an on-chain transfer. Compare the amount in BTC or sats, review the payment request’s expiry and inspect any route, service or conversion fee shown. For a first payment to a recipient, a small test can help confirm that the wallet setup is working.

Before receiving, check that the wallet can generate a Lightning payment request and has the inbound liquidity needed for the amount. If it cannot, the wallet may explain how to add liquidity or use another receiving method. Do not assume that an on-chain Bitcoin address and a Lightning invoice are interchangeable; use the payment method the recipient specified.

For ongoing use, understand where the bitcoin is held and who controls the keys. Ask whether the wallet opens channels automatically, how it handles backups and what happens if you stop using the service. If it is self-custodial, learn its recovery and channel-closure process before keeping a substantial balance there. If it is custodial, review withdrawal limits, fees and account requirements.

Lightning is best understood as a payment layer with its own balance and channel mechanics, not as a magic shortcut that removes Bitcoin’s constraints. When a payment is important, confirm the status in the wallet and keep the receipt or transaction details. If a payment remains pending or fails, consult the wallet’s support guidance before retrying or paying again.