Glossary / Lightning & layer 2
CLTV expiry delta
- What is a CLTV expiry delta?
- A CLTV expiry delta is the number of blocks a Lightning node subtracts from an incoming payment's timelock before passing it on, advertised per channel direction in gossip.
Each forwarding node on a Lightning route charges two prices, a fee in millisatoshi and a delay in blocks, and the CLTV expiry delta is the delay. BOLT 7 carries it as a 16 bit field in the channel_update message alongside fee_base_msat, and each side of a channel publishes its own value independently. If a payment jams, that stack of blocks is how long your money stays frozen.
How it works
A CLTV expiry delta is chosen by the node that will do the forwarding, and it governs that node's outgoing direction only.
The spec wording is exact: a node must set the field to the number of blocks it will subtract from an incoming HTLC's cltv_expiry. So the delta is not a deadline, it is a gap. The node accepts a payment locked until some absolute block height, keeps the delta for itself, and offers the next hop a payment locked until that height minus the delta. That gap is the node's safety margin: if the downstream hop settles at the last possible moment, that many blocks remain to claim upstream.
Every public channel carries two of these numbers, one per direction, each signed by the node that set it. They ride in channel_update, message type 258, beside htlc_minimum_msat and the two fee fields. Only the updates announced by nodes that will forward matter: on a route A to B to C to D, the payer uses B's update for B to C and C's update for C to D, and none of its own.
Routes are therefore built backwards. The payer starts at the destination with the minimum final expiry the invoice asks for, walks back adding each hop's advertised delta, and the running total becomes the timelock on the HTLC it hands its first peer. When a node revises its prices, BOLT 7 asks it to keep accepting the previous parameters for 10 minutes, because gossip does not reach every payer at once.
Where you see it
CLTV expiry deltas decide how long a stuck Lightning payment ties up your balance, and BOLT 7's own routing example puts figures on two otherwise identical routes.
Four nodes sit in a diamond: A, B, C and D, advertising 10, 20, 30 and 40 blocks, with C asking for a final expiry delta of 18, which the spec calls the default. A sends 4,999,999 millisatoshi to C. Routed through B, A hands its peer 5,010,198 millisatoshi, 10,199 of it B's fee, and the first HTLC expires at the current block height plus 80: 20 blocks for B's hop, 18 for C, and 42 more of padding. Routed through D, the same payment costs 5,020,398 millisatoshi and expires at the current height plus 100. Same sender, same recipient, same amount, and 20 extra blocks of exposure.
That 42 is not arbitrary slack. BOLT 7 warns that a route built by summing the deltas honestly lets an intermediate node work out its own position, and from there guess who is being paid, so a payer is advised to add a random offset, found by walking the graph outward from the recipient and summing the deltas it meets. The spec calls the result a shadow route extension.
None of this is yours to set unless you run the forwarding node. Phoenix, which our review calls a real self-contained Lightning node on the handset, publishes its sending price as 0.4% plus 4 sat, and that table prices the money, not the blocks.
CLTV expiry delta vs OP_CHECKLOCKTIMEVERIFY
A CLTV expiry delta is a routing policy figure published in gossip, while OP_CHECKLOCKTIMEVERIFY is the bitcoin script opcode that enforces an absolute deadline on chain.
They share three letters and little else. A delta is relative and lives entirely off chain: it appears in no script, no full node validates it, and the node that set it revises it with a fresh channel_update. OP_CHECKLOCKTIMEVERIFY is written into the coin, checked by every full node, and cannot be edited once the coin exists.