A Lightning payment is a five-stage cryptographic handoff. The recipient encodes a BOLT 11 invoice, the sender's node finds a route across connected channels, each hop locks a hash time-locked contract (HTLC) against a shared payment hash, the recipient reveals the preimage to claim the last HTLC, and that reveal cascades backward so every intermediary settles (source: Lightning Network; Lightning BOLTs).
The five stages of a Lightning payment
A Lightning payment runs through invoice creation, pathfinding, HTLC propagation, preimage reveal, and backward settlement. Each stage produces a specific cryptographic artifact, and the payment only completes when all five stages close cleanly within the HTLC timelock window.
Invoice creation (recipient side): the receiving node encodes a BOLT 11 payment request carrying a payment_hash, amount (optional), description or description_hash, expiry (commonly 3,600 seconds), and the recipient's pubkey (source: GitHub).
Pathfinding (sender side): the sender's node searches the BOLT 7 channel-graph gossip for a route with enough liquidity on the right side of each channel to carry the amount to the destination (source: GitHub).
Onion construction and HTLC propagation: the sender wraps per-hop forwarding instructions in a Sphinx onion and offers the first HTLC to the first routing node; each hop peels its layer, verifies fee and timelock terms, and offers a matching HTLC to the next hop (source: GitHub).
Preimage reveal: the recipient, holding the secret preimage whose SHA256 hash is the invoice's payment_hash, claims the final HTLC from the last routing node by releasing the preimage.
Backward settlement: each routing node, now holding the preimage, uses it to claim the HTLC from the hop upstream, propagating the settlement back to the sender within milliseconds.
If any stage fails, the route unwinds. An unrouteable payment is rejected before any HTLC is committed; a route that gets stuck mid-flight refunds each HTLC at its timelock expiry rather than stranding funds with an intermediary.
Stage 1: The BOLT 11 invoice is the starting artifact
A Lightning payment begins with the recipient, not the sender. The recipient's wallet generates a random 32-byte secret (the preimage), takes its SHA256 hash to produce the payment_hash, and encodes both the hash and the rest of the invoice parameters into a bech32 string prefixed with lnbc for mainnet (source: BOLT 11 spec; Bolt11.org). The sender only ever sees the hash, never the preimage, which is what makes the downstream routing trust-minimized.
A BOLT 11 invoice carries several tagged fields that matter at the mechanism level:
payment_hash (tag p, 256 bits): SHA256 of the preimage; the condition for every HTLC on the route.
amount (optional): human-readable prefix; omitting it produces a zero-amount invoice for donation links.
description (tag d) or description_hash (tag h): short purpose string or 256-bit hash of a longer document.
expiry: default 3600 seconds; after expiry the invoice is unpayable and a new one must be generated.
min_final_cltv_expiry: minimum timelock the last hop must offer so the recipient has enough blocks to claim.
payment_secret: 32-byte value that prevents probing and enables Multi-Path Payments.
route_hints: optional hints that let wallets with private channels still receive payments.
The invoice is serialized into a lowercase string, signed by the recipient's node, and typically rendered as a QR code. Signing prevents any intermediary from forging an invoice for a different destination. Encoding the payment_hash lets the sender verify the HTLC condition matches the invoice without trusting any routing node.
For the full Lightning Network architecture that sits under this invoice mechanism, see what is the Lightning Network. For the decision logic of when to use Lightning at all, see Lightning vs on-chain Bitcoin.
Stage 2: The sender's node finds a route through the channel graph
Routing on Lightning is source-routed, not destination-routed. The sender's node is responsible for computing the full path from itself to the recipient, which is the opposite of how Bitcoin on-chain transactions work (where the network decides propagation) and the opposite of how internet packets travel (where each hop makes independent routing decisions). Source routing gives the sender control over fees, total timelock, and privacy tradeoffs.
Pathfinding input is the public channel graph every node maintains locally from BOLT 7 gossip: channel_announcement on open, channel_update for fee or status changes, and node_announcement for metadata (source: GitHub). The graph does not show private channels, does not expose balance distribution within each channel, and lags real state by gossip propagation delay. A node can pathfind against this graph but cannot know in advance whether liquidity sits on the right side of each channel for the payment direction.
Mature Lightning implementations (LND, Core Lightning, Eclair) use Dijkstra-style shortest-path search weighted by routing fees, total CLTV timelock, and a probability heuristic that learns from past payment outcomes. A route that failed yesterday gets a lower score today; a route that succeeded gets boosted. LND's mission control and CLN's askrene pathfinder both rely on this learn-as-you-go model rather than static graph analysis.
When a sender's wallet hits pay, it parses the invoice, queries the local channel graph, computes candidate routes with cumulative fees and timelocks, picks the best-scoring one, and proceeds to HTLC construction. On an uncongested graph this runs in tens of milliseconds; on a sparse path it may take several iterations and pay higher fees than a shorter route would.
For the fee economics behind the routing decision and how they compare to on-chain transaction fees, see why are bitcoin fees so high.
Stage 3: Sphinx onion routing constructs the per-hop payload
Once a route is picked, the sender builds an onion-encrypted packet that gives each routing node exactly what it needs to forward the payment and nothing more. The construction is derived from the Sphinx mix-network protocol and specified in BOLT 4 (source: BOLT 4 spec; Lightning Onion).
The onion is built backward from the recipient. The sender derives a shared secret with each hop's pubkey using ephemeral Diffie-Hellman, encrypts that hop's per-hop payload, wraps the result with the next-outer hop's payload, and so on until the outermost layer is wrapped for the first hop. When a hop receives the onion, it derives the shared secret, decrypts its own layer, extracts the forwarding instructions (next hop's channel_id, amount to forward, outgoing CLTV expiry), and passes the remaining onion onward. A hop cannot read any layer other than its own, and cannot tell how many hops are ahead or behind because the onion is padded to a fixed size.
Each per-hop payload contains: short_channel_id (the outgoing channel to forward through), amt_to_forward (the amount in msat to pass to the next hop), outgoing_cltv_value (the block height at which this hop's HTLC must expire), and a payload length plus HMAC that let each hop detect tampering.
With the onion constructed, the sender offers an HTLC to the first routing node over their existing channel. The HTLC commits an amount that can only be claimed by a party who can produce the preimage whose hash matches the payment_hash, and only before the timelock expires. In plain terms, the sender says: I'll pay X sats if you reveal a secret whose SHA256 is Y by block height Z, otherwise the payment refunds. The first hop peels its onion layer, constructs its own HTLC to the next hop with slightly less amount (its routing fee) and a slightly earlier timelock (safety margin), and the pattern repeats.
The key privacy property is that each hop only knows its direct predecessor and successor. The first hop knows the sender but not the final recipient. The last hop knows the recipient but not the sender. Intermediate hops know neither endpoint. This is why Lightning's per-hop privacy is qualitatively different from the public transaction graph of on-chain Bitcoin (source: Dl).
Stage 4: The recipient reveals the preimage to claim the final HTLC
When the HTLC chain reaches the last hop, that hop offers the final HTLC to the recipient. The recipient can reveal the preimage and claim the HTLC, or do nothing and let it refund at timeout. Because the recipient generated the preimage in Stage 1, they are the only party who can produce it.
If the recipient reveals the preimage, the last hop's HTLC resolves in the recipient's favor. Satoshis move from the last hop's side of the channel to the recipient's side. No on-chain transaction is broadcast; the channel's commitment transaction updates off-chain with new balances and both parties exchange signatures confirming the state (source: GitHub).
This is the single event that resolves the entire payment. Everything before it was conditional; everything after is backward cleanup. It happens in whatever time the recipient's wallet needs to validate and sign off, typically a few hundred milliseconds.
The recipient can also reject the HTLC if the amount or other parameters do not match the invoice. That is why a sender cannot overpay, underpay, or misroute through a compliant recipient; the wallet verifies the incoming HTLC against the issued invoice and rejects mismatches, and the payment fails back through the route with no funds moving.
What "settled" actually means at this stage
At the moment the preimage is revealed, the payment is considered settled from the recipient's perspective, even though upstream hops are still resolving. If the last hop goes offline immediately after receiving the preimage, the recipient still owns the preimage and can enforce the HTLC on-chain by broadcasting the commitment transaction to spend the HTLC output. That on-chain fallback is what makes HTLCs trust-minimized rather than trust-based.
Stage 5: The preimage cascades back, and every hop settles
Once the last hop knows the preimage, it claims the HTLC from the upstream hop by passing the preimage back with a resolution message. The upstream hop validates that the preimage hashes to the shared payment_hash and resolves in the forwarding hop's favor, pocketing the forwarded HTLC value minus its routing fee. The process repeats upstream: each hop uses the preimage to claim from its predecessor and collect its fee, until the sender's first-hop HTLC resolves and the payment is fully settled end-to-end.
Backward settlement is what gives Lightning sub-second happy-path latency. No hop needs a block confirmation to consider its HTLC resolved; each hop just needs the preimage and a signed channel update from its neighbor, both local operations on the existing channel.
This also explains why routing nodes cannot steal funds from a successfully-routed payment. The HTLC a node offers downstream is structurally identical to the one it accepted upstream in payment_hash and timelock. The preimage that claims one claims the other. A node that settles downstream without passing the preimage upstream has given away its own money. A node that fails to settle downstream still pays the upstream HTLC at on-chain enforcement if pushed there, because the upstream hop can prove it presented the preimage.
For the comparison to on-chain Bitcoin confirmation-based settlement, see how bitcoin transactions work and bitcoin confirmations.
Fees and amounts: Base fee, proportional fee, and the millisatoshi unit
Lightning routing fees are a two-component formula per hop. Each routing node in a channel_update advertises:
base_fee_msat: a fixed per-payment charge, paid regardless of amount.
fee_rate_milli_msat: a proportional charge in parts per million, applied to the amount being forwarded.
Total hop fee = base_fee_msat + (amount_msat × fee_rate_milli_msat / 1,000,000).
The unit throughout Lightning is the millisatoshi (msat), one-thousandth of a satoshi. Sub-satoshi precision only exists inside channels; when a channel is closed back to the base layer, it balances round to whole satoshis because the UTXO model cannot represent fractional sats. Msats matter for fee math on tiny payments (podcast value-for-value streams, content micropayments) where a few satoshis per payment would round away meaningful value.
As a snapshot, the 1ML statistics page consistently shows a median base fee around 0.35 sat (350 msat) and a median fee rate around 128 ppm (0.000128 sat per sat forwarded) on public channels (source: 1ML). A two-hop 10,000-sat payment at those medians costs: 2 × 350 msat + 2 × (10,000,000 msat × 128 / 1,000,000) ≈ 3 satoshi. That is roughly what beginners see in practice on public routes for coffee-sized payments, orders of magnitude below a normal on-chain fee during congestion.
Senders can cap the maximum fee they are willing to pay (the fee_limit parameter in most wallets). If no route exists within the cap, the payment fails with a fee-exceeded error rather than overpaying.
Routing component | What it controls | Typical 2026 value | Why it matters |
|---|---|---|---|
base_fee_msat | Fixed per-payment cost | ~350 msat (0.35 sat) median | Non-trivial for sub-100-sat payments |
fee_rate_milli_msat | Proportional, in ppm | ~128 ppm median | Dominates fees on larger payments |
Millisatoshi unit | Internal precision | 1/1000 sat | Enables sub-satoshi micropayments |
Timelock delta (cltv) | Safety margin at hop | 40-144 blocks typical | Affects total worst-case refund wait |
When a single channel is too small: Multi-Path Payments (MPP)
A single HTLC's upper bound is the smaller balance on either side of the tightest channel on its route. A sender with 1 BTC of outbound capacity split across ten 0.1 BTC channels can only make a 0.1 BTC single-channel payment even though the wallet shows 1 BTC. This is the payment-size cliff that trips up new Lightning users.
Multi-Path Payments split one logical payment across several parallel HTLCs that each carry a portion of the total (source: Lightning Labs). All parts share the same payment_hash. The recipient holds each incoming HTLC without releasing the preimage until the incoming amounts sum to the invoice amount, then releases and all parts settle atomically. If the full amount never arrives, the individual HTLCs time out and refund.
MPP shipped in LND 0.10 in May 2020 and is now standard across mature implementations (source: Lightning Labs). With MPP, the practical ceiling is the sender's total outbound liquidity across all usable paths, not the largest single channel. Well-funded nodes routinely send multi-BTC payments; retail wallets with a few small channels still hit the cliff, and success probability falls as payment size approaches total outbound capacity. For the underlying channel mechanics that determine outbound capacity in the first place, see lightning channels.
The payment_secret in BOLT 11 is what makes MPP safe: without it, a routing node could probe a wallet by sending a small HTLC and watching for errors. With it, the recipient rejects any HTLC missing the matching payment_secret, preventing accidental or malicious partial payments from unrelated senders.
Keysend, spontaneous payments, and BOLT 12 offers
Not every Lightning payment starts with an invoice. Keysend is a spontaneous-payment pattern where the sender generates the preimage themselves, hashes it to derive the payment_hash, and routes an HTLC to the recipient's pubkey with the preimage embedded as a TLV extension in the onion payload (source: Buildonln). The recipient extracts the preimage from the onion and claims the HTLC. This is how podcast value-for-value streams, streaming sats, and bot tipping systems work. Keysend is not part of BOLT 11 proper; it is a widely-implemented informal standard catalogued as a bLIP.
BOLT 12 offers are the next-generation invoice-replacement format. Instead of a one-shot invoice, the recipient publishes a reusable offer that senders fetch and convert into per-payment invoices on demand (source: BOLT12.org; BOLT 12 spec). Offers fix three BOLT 11 limitations: invoices are single-use so a recipient cannot publish a static payment link, invoices include the recipient pubkey in plaintext reducing privacy, and invoices expire. BOLT 12 uses onion messages for the offer-to-invoice fetch, so the sender's identity stays hidden from the recipient's node. Strike announced production BOLT 12 support in August 2024 and more integrations are rolling out through 2025 into 2026.
For users today, BOLT 11 invoices remain the dominant format and keysend powers most streaming use cases. BOLT 12 is the direction the network is moving, but a beginner does not need it to use Lightning. Which wallet a user picks matters more than the invoice format; see best Lightning wallet types for the trust-model breakdown across popular options.
Common failure modes and what they actually mean
Lightning's happy path is elegant; its failure modes are where users stumble. Understanding what each failure means is the difference between retrying sensibly and giving up on the rail.
No route found. The sender's pathfinder could not construct any path within the fee cap and timelock constraints, usually because the recipient sits on an unreachable part of the graph or no outbound channel has enough liquidity on the right side. No HTLC is committed, no funds move, and the sender can retry with a smaller amount or a higher fee cap.
Insufficient liquidity mid-route. The sender picked a route that looked viable from the graph, but one of the hops did not actually have liquidity on the outgoing side when the HTLC arrived. The hop returns a temporary_channel_failure, the pathfinder lowers that channel's probability score, and the wallet retries a different route. This is the most common Lightning failure; mature pathfinders absorb it in seconds.
Expired invoice. A BOLT 11 invoice past its expiry (typically one hour) cannot be paid; the recipient must generate a new one. This trips up users who treat an invoice like a static on-chain address.
Stuck HTLC / timelock wait. An HTLC is committed, the downstream hop goes offline before resolving it, and the sender waits until the timelock expires to reclaim funds. CLTV timelocks are typically tens to low-hundreds of blocks (hours to a day). The funds are safe, just delayed, and a force-close can speed resolution at the cost of an on-chain fee.
Payment_secret mismatch. An older wallet sends MPP without including the required payment_secret, or the recipient rejects a partial amount because the sum does not match. The sender's wallet retries or fails.
Wrong-network invoice. A sender scans a testnet invoice on a mainnet wallet. Wallets catch this from the bech32 prefix (lnbc mainnet, lntb testnet) and reject before any HTLC is offered.
Retry behavior is where Lightning wallets differentiate. Some try a single route and give up; others iterate through dozens of candidates with refined probability scoring. The same invoice can fail on one wallet and succeed on another because one has a better pathfinder.
For the broader Lightning risk surface beyond payment-flow failures, see lightning network risk.
2026 routing snapshot: what a typical payment costs and how fast it clears
The current state of the public Lightning graph gives concrete numbers for what a beginner should expect on a first payment.
Network size sits at roughly 12,000 to 16,000 public nodes and 44,000 to 75,000 public channels, with total public capacity in the 5,000 BTC range (source: 1ML; Bitcoin Visuals). Most channels are small: median node capacity is on the order of 0.002 to 0.005 BTC, while large routing hubs carry hundreds of times that. Pathfinders tend to route through hubs on longer paths rather than along peer-to-peer edges. The question of whether a user should hand channel management to a custodian or run their own is treated separately in custodial vs non-custodial Lightning wallets.
Payment latency on a healthy route is 300 milliseconds to two seconds end-to-end, dominated by round-trip network time across three to five hops rather than cryptographic work. A failing-then-retrying payment can take several seconds as the pathfinder tries alternatives, and MPP payments take slightly longer because the slowest part determines total latency.
Fees on coffee-to-dinner-sized payments (5,000 to 100,000 sat) usually total a handful of satoshi across two to four hops at 1ML medians. Fees on larger payments (1 million sat and up) are dominated by the proportional rate and routinely run into hundreds of satoshi, still far below a congested on-chain fee but no longer meaningfully smaller than a calm-day on-chain fee. The rail economics flip somewhere between 1 and 10 million sat depending on congestion.
Blofin's operational perspective on payment-flow failures
From an exchange operator's perspective, Lightning routing failures and on-chain mempool stalls present as structurally different categories that need different diagnostic paths and different fixes. When a Lightning deposit does not arrive at BloFin, our first diagnostic is whether the invoice expired, whether the sender's pathfinding hit a liquidity wall, or whether an HTLC is sitting stuck upstream; each has a distinct remediation and none map cleanly onto on-chain fee-rate thinking.
The practical user-facing lesson is that a failed Lightning payment is almost never about the network being broken. It is usually about route liquidity, invoice expiry, or payment_secret compatibility, and retrying a minute later on a slightly different route often succeeds where the first attempt did not.
FAQ
Is a Lightning payment the same as a regular Bitcoin transaction?
No, not at the mechanism level. A regular Bitcoin transaction is broadcast to the mempool, mined into a block, and confirmed on-chain; every transaction is publicly recorded and settlement depends on block confirmations. A Lightning payment is a series of off-chain HTLC updates across a routed path of pre-funded channels, settled by a preimage reveal and a cascade of backward HTLC resolutions. The base chain is only touched at channel open, channel close, or on-chain dispute enforcement. Lightning uses bitcoin and ultimately settles to Bitcoin, but the per-payment flow is structurally different.
What actually lives inside a BOLT 11 invoice?
A BOLT 11 invoice carries the recipient's pubkey, a 256-bit payment_hash derived from a secret preimage the recipient keeps, an optional amount and description, an expiry window (default 3,600 seconds), a minimum final CLTV expiry the last hop must respect, a payment_secret used for MPP safety, and optional route_hints for reaching recipients with private channels. The whole package is signed by the recipient so no intermediary can forge one, and the sender verifies the signature and matches the payment_hash to the HTLC condition before spending. The invoice itself is a bech32-encoded lowercase string, usually shown as a QR code.
Why do Lightning payments sometimes fail even when I have a balance?
Because wallet balance is not the same as usable routing liquidity. Your funds may be split across channels where the balance is on your side but the downstream hop does not have enough to forward, or no route exists within your fee cap, or the invoice has already expired, or a channel on the chosen route is temporarily offline. A payment has to find a route, offer an HTLC on every hop with liquidity on the right side, and receive a preimage back within the timelock. Any link failing fails the whole payment, even though your local balance is fine.
Can a routing node in the middle of my payment steal the funds?
No, not under correct protocol operation. Every hop's HTLC is locked to the same payment_hash and only resolves if the matching preimage is revealed before timeout. A routing node that receives the preimage downstream must pay its upstream hop by presenting that same preimage, or lose the upstream HTLC to on-chain enforcement. A routing node that tries to claim one side without honoring the other loses funds from its own channel, not from the payment in transit. Timelock asymmetry between hops gives the settlement cascade enough buffer to complete even if some hops are slow.
What is the preimage and why does it matter?
The preimage is a 32-byte secret the recipient generates when creating the invoice. Its SHA256 hash becomes the payment_hash that the invoice publishes and that every HTLC on the route uses as its condition. Because only the recipient holds the preimage, only the recipient can claim the final HTLC; because revealing it to claim that HTLC also lets every upstream hop claim theirs, the reveal cascades settlement backward. The preimage is also how a recipient can prove a payment was completed, which is sometimes called proof-of-payment.
How long does a Lightning payment take?
A successful Lightning payment on a healthy route typically settles in 300 milliseconds to two seconds end-to-end, dominated by round-trip network latency across three to five hops rather than by cryptographic work. Failing payments can take several seconds as the pathfinder tries alternative routes. Stuck HTLCs (where a hop goes offline after committing but before resolving) resolve at timelock expiry, which is usually in the tens to low-hundreds of blocks (hours to around a day). The 300ms-2s number is the perceptual "Lightning is instant" experience; the longer timelines only matter if something goes wrong.
What happens if the recipient is offline when I try to pay?
The payment usually fails because the final HTLC cannot resolve without the recipient revealing their preimage, and an offline recipient cannot reveal anything. The sender's HTLC refunds at its timelock and no funds move. This is a real limitation compared to on-chain Bitcoin, where a transaction to an address works regardless of whether the recipient is online. Async BOLT 12 payments and custodial wallet models work around this, but the BOLT 11 base case requires the recipient to be reachable.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. All facts independently verified.
Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.