The Lightning Network is a payment network built on top of Bitcoin. Two parties lock bitcoin into a shared on-chain output. They can then pay each other as many times as they like by exchanging signed updates off-chain. Payments can also hop across other people's channels to reach someone you have no channel with. Only opening and closing a channel, plus any dispute, needs a Bitcoin transaction. A payment does not wait for a block, and it costs whatever fee the routing nodes on its path charge. These fees are often a tiny fraction of an on-chain fee. You are still using real BTC: Lightning is a way of moving bitcoin, not a separate coin.

What changed recently (August–October 2026)
- Security releases for Core Lightning. Core Lightning is one of the main node implementations. It shipped security releases v26.06.7 (28 August 2026), v26.06.8 (22 September) and v26.06.9 (7 October). The release notes say each contains "fixes for vulnerabilities responsibly reported by a number of sources." The 7 October release lists fixes in channel reestablishment, splicing, and HTLC handling during shutdown, among other areas. The v26.06.7 notes warn that some Docker tags reported v26.06.7 but did not contain the fixes, and tell users who pulled them between 28 August and 1 September to check the image digest. Anyone running a Core Lightning node should be on the latest release.
- Public capacity fell over the summer. mempool.space publishes statistics for the public network. On 30 July 2026 it recorded about 4,447 BTC in public channels across 38,879 channels. On 30 August 2026 it recorded about 3,794 BTC across 32,674 channels and 16,232 nodes. These figures count only publicly announced channels; private channels are not included.
How the Lightning Network works
Payment channels
A channel starts with a funding transaction. This is an on-chain output that needs signatures from both parties: a 2-of-2 multisig, per the protocol specification (BOLT 3). After it confirms, the two parties keep a running balance between them. Each payment replaces the previous commitment transaction with a new signed one that splits the funds differently. Either party could broadcast its latest commitment transaction to the Bitcoin blockchain at any time, but normally neither does until they close the channel.
You can only send up to your side of the channel's balance, and you can only receive up to the other side's balance. This is why wallets talk about outbound and inbound liquidity.
What stops cheating
Each time the balance changes, both parties hand over a revocation key for the old state. Suppose someone broadcasts an outdated commitment transaction that paid them more. Their own output is time-locked (to_self_delay). During that delay, the other party can use the revocation key to sweep that output in a penalty transaction. The catch is that someone has to be watching the chain. Services called watchtowers do this for users who go offline, and broadcast the breach remedy for them.
Routing across the network
You don't need a channel with everyone. If Alice has a channel with Bob, and Bob has one with Carol, Alice can pay Carol through Bob. Payments are wrapped in layered onion encryption (BOLT 4). Under the specification, intermediate nodes "cannot learn which other nodes, besides their predecessor or successor, are part of the packet's route."
HTLCs: why routing is trustless
Each hop is secured by a Hash Time-Locked Contract (HTLC). The recipient's invoice contains a payment hash, and only the recipient knows the matching secret (the preimage). Each node on the route can claim its incoming payment only by revealing that preimage. Revealing it is what lets the previous node claim in turn. If the payment does not complete before the HTLC's expiry, the funds return through the timeout path. A routing node therefore cannot take a payment and keep it.
Invoices and offers
- BOLT 11 invoices are the standard payment request. An invoice carries a payment hash, a description, a timestamp, the recipient's signature and an optional amount. If no expiry is set, it expires after 3,600 seconds (one hour). The specification warns that invoices should be single-use: paying the same invoice twice is "actively dangerous."
- BOLT 12 offers are reusable payment requests. A merchant publishes one, for example as a QR code, and each payer's wallet fetches a fresh invoice from it. An offer can stay valid much longer than any single invoice.
Lightning vs on-chain Bitcoin
| Lightning | On-chain Bitcoin | |
|---|---|---|
| Settlement | When the route completes; no block wait | When the transaction is mined into a block |
| Fees | Set by each routing node (base fee + proportional rate) | Bid for block space; rises with congestion |
| Setup | Needs a funded channel or a wallet that manages one | None beyond a wallet |
| Limits | Channel balances and route liquidity | Block space |
| Funds online | Channel funds are in a hot wallet | Can be kept in cold storage |
| Best fit | Small, frequent payments | Larger transfers and long-term holding |
How cheap is it?
mempool.space's 30 August 2026 snapshot shows routing nodes' median fee settings: a proportional rate of 100 parts per million (0.01% of the amount) and a base fee of 500 millisatoshis (half a satoshi) per payment. Your total depends on how many hops your payment takes and on each node's settings. Opening and closing channels still costs on-chain fees.
Throughput
Bitcoin's base layer handles only a few transactions per second. The Bitcoin wiki's scalability page, which the wiki itself flags as outdated, gives a sustained rate of about 7. Lightning avoids this limit for payments, because only channel opens and closes use block space.
What would routing fees cost on your payment?
Enter a payment size, how many routing nodes it passes through and their fee settings to estimate the total Lightning routing fee.
| Payment amount | Routing nodes on the path (nodes between you and the recipient) | Proportional rate charged by each routing node | Base fee charged by each routing node | Estimated total routing fee |
|---|---|---|---|---|
| 100,000 sats | 1 nodes | 100 ppm | 500 msat | 10.5 sats |
| 1,000,000 sats | 2 nodes | 100 ppm | 500 msat | 201 sats |
| 10,000 sats | 3 nodes | 100 ppm | 500 msat | 4.5 sats |
- The default rate and base fee are median node settings from one mempool.space snapshot (30 August 2026), applied to every node on the route; real nodes on your path may charge more or less.
- Payment size and number of routing nodes are your own inputs, not figures from any source; a direct payment to a channel partner has no routing nodes and no routing fee.
This estimates routing fees only: it leaves out the on-chain fees for opening and closing channels, any wallet or provider charges, and cannot tell you whether a route with enough liquidity exists.
Using Lightning in practice
- Choose a wallet type. In a custodial wallet, a provider holds your funds. In a self-custodial wallet, you hold the keys and a recovery phrase. Two examples:
- Phoenix, from ACINQ, is a self-custodial Lightning wallet. It has managed its channel automatically since 2023, using splicing. - Wallet of Satoshi now presents itself as self-custodial, with a 12-word recovery phrase only the user knows. Its self-custodial version runs on Spark, a separate protocol that interoperates with Lightning, and launched in beta in July 2025.
- Fund it with a small amount of BTC from a wallet or service that supports Lightning or on-chain deposits.
- Pay by scanning a BOLT 11 invoice, a BOLT 12 offer, or a Lightning Address if your wallet supports one.
- Running your own node is optional. It gives you more control and privacy, but you have to manage liquidity, backups and monitoring yourself.
Risks to understand
- Hot-wallet exposure: channel funds are controlled by keys on an online device.
- Liquidity limits: larger payments can fail if no route has enough balance.
- Custodial risk: if a provider holds your funds, you depend on that provider.
- Channel jamming: an attacker can tie up channels' funds in pending payments, up to 20 hops away, for an extended period. Nothing is stolen, but the funds can't be used until those payments resolve. This is still an open research problem.
- Software bugs: node implementations still ship security fixes, as the Core Lightning releases in 2026 show. Keep software up to date.
- Offline exposure: if you run your own node and go offline for a long time, use a watchtower so outdated channel states can be punished.
Background
Joseph Poon and Thaddeus Dryja described the design in "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments." The draft is version 0.5.9.2, dated 14 January 2016. Lightning Labs released lnd 0.4-beta, which it called "the first Lightning mainnet beta," on 15 March 2018 and advised users to test with small amounts. On 30 January 2025, Tether and Lightning Labs announced plans to bring USDT to Bitcoin and Lightning using the Taproot Assets protocol.
FAQ
Is Lightning a separate cryptocurrency?
No. Channels are funded with BTC and settle back to the Bitcoin blockchain when they close.
Do I need to run a node?
No. Mobile wallets handle channels for you. Running a node is optional.
Can a routing node steal my payment?
HTLCs prevent that: a node can only claim funds by passing the payment on, and failed payments time out and return. The main risks are your own wallet's security, the provider (if custodial) and software bugs.
Why did my payment fail?
Usually because no route had enough liquidity, or because the invoice had expired. The default expiry is one hour.