CLTV Expiry Delta

What Is CLTV Expiry Delta?

CLTV expiry delta (also written cltv_expiry_delta) is the minimum number of Bitcoin blocks a Lightning Network forwarding node requires between the timelock on an incoming HTLC and the timelock on the corresponding outgoing HTLC. The value is defined per channel and broadcast via the BOLT #7 channel_update gossip message so that senders can build routes with correct timelocks.

Think of it as a reaction window. When a node forwards a payment, it creates two linked contracts: one with its upstream peer (incoming HTLC) and one with its downstream peer (outgoing HTLC). If the downstream peer claims the outgoing HTLC by revealing the preimage, the forwarding node needs enough time to take that preimage and claim the incoming HTLC before it expires. The CLTV expiry delta is the size of that window, measured in blocks.

The name comes from Bitcoin's OP_CHECKLOCKTIMEVERIFY opcode, which enforces absolute block-height timelocks on HTLC outputs. The "delta" is the difference between two such timelocks at adjacent hops.

How It Works

Every HTLC in a Lightning payment carries a cltv_expiry value: the block height at which the HTLC times out and funds return to the sender. For a forwarding node, the incoming HTLC's expiry must be sufficiently larger than the outgoing HTLC's expiry. The forwarding rule, specified in BOLT #4, is:

incoming_cltv_expiry - cltv_expiry_delta >= outgoing_cltv_value

If this condition is not met, the node must reject the HTLC. Here is why this matters:

1. The sender constructs an onion-routed payment with per-hop instructions
2. Each forwarding node receives an incoming HTLC and creates an outgoing HTLC with a shorter timelock
3. If the outgoing HTLC is claimed (preimage revealed), the node uses that preimage to claim the incoming HTLC
4. If the outgoing HTLC times out, the node reclaims those funds and lets the incoming HTLC time out as well

The delta provides enough blocks for the forwarding node to observe the downstream settlement and react, even if the settlement happens on-chain during a force close.

Accumulation Across Hops

Senders compute timelocks backwards from recipient to sender. Each hop adds its own delta to the running total. Consider a 4-hop route where the current block height is 800,000:

Route: Sender → Alice → Bob → Carol → Recipient

Recipient: min_final_cltv_expiry_delta = 18
  → cltv_expiry = 800,018

Carol (delta = 80):
  → cltv_expiry = 800,098

Bob (delta = 34):
  → cltv_expiry = 800,132

Alice (delta = 144):
  → cltv_expiry = 800,276

Sender's outgoing HTLC: cltv_expiry = 800,276
Total timelock: 276 blocks (~46 hours)

The sender's funds are locked for the full accumulated timelock. If the payment stalls or fails, the sender waits up to 276 blocks before the HTLC times out and funds are refunded. This is why pathfinding algorithms penalize routes with large total timelocks: they represent longer capital lockup for the sender.

The Safety Formula

BOLT #2 provides a formula for calculating the minimum safe delta:

cltv_expiry_delta = 3R + 2G + 2S

Where:
  R = reorganization depth (recommended: 2)
  G = grace period for HTLC fulfillment (recommended: 2)
  S = security margin for fee confirmation (recommended: 12+)

With recommended values:
  3(2) + 2(2) + 2(12) = 6 + 4 + 24 = 34 blocks

The R factor accounts for blockchain reorganizations that could reverse settled transactions. The G factor gives nodes time to detect and respond to on-chain events. The S factor provides a buffer for getting timeout or success transactions confirmed during periods of high fees, since HTLC transactions cannot always have their fees bumped after the fact. The S value should be set conservatively because irregular block times, empty blocks, and sudden fee spikes can all delay confirmation.

Default Values by Implementation

Major Lightning implementations ship with different defaults, reflecting different risk tolerances:

For the final hop (the payment recipient), BOLT #11 specifies a default min_final_cltv_expiry_delta of 18 blocks if not explicitly set in the invoice. This was raised from 9 blocks after analysis showed thousands of mainnet channels were running dangerously low values.

Why It Matters

CLTV expiry delta directly affects three aspects of the Lightning Network that every node operator and wallet developer should understand:

• Payment reliability: if a forwarding node's delta is too small, it risks losing funds during on-chain resolution. This makes nodes reluctant to forward payments, reducing overall network reliability.
• Payment speed: larger deltas across a route mean longer total timelocks, which lock sender funds longer if payments fail. Pathfinding algorithms factor this in, preferring routes with lower total timelock.
• Routing competitiveness: nodes with very high deltas may be avoided by senders building routes. Operators must balance safety against being selected for forwarding, which affects their ability to earn routing fees.

For a deeper look at how routing decisions interact with channel parameters, see the Lightning Network routing deep dive.

Use Cases

Node Operator Configuration

Routing node operators tune their CLTV expiry delta based on their infrastructure. A node with reliable uptime, redundant internet connections, and a dedicated watchtower can safely run a lower delta because it has more confidence in detecting and responding to on-chain events quickly. A node that goes offline periodically needs a higher delta to account for the time it might miss critical HTLC settlements.

In LND, the delta is configured with the bitcoin.timelockdelta parameter:

# lnd.conf
[Bitcoin]
bitcoin.timelockdelta=80

Wallet Pathfinding

Lightning wallets use CLTV expiry delta values advertised by each channel to compute total route timelocks. A wallet building a route will sum the deltas along each candidate path and factor the total into its routing score alongside fee rates and channel capacity. Routes with lower total timelocks are preferred, all else being equal, because they reduce the sender's risk exposure.

Channel Management

When managing Lightning channels, the CLTV expiry delta interacts with other safety parameters. Nodes using anchor outputs have more flexibility to bump fees on commitment transactions, which can justify slightly lower deltas. The overall approach to channel management should consider delta settings alongside reserve requirements and fee policies.

Risks and Considerations

The Forwarding Risk

The fundamental risk that CLTV delta mitigates is a timing attack on forwarding nodes. If a forwarding node's delta is too small, this scenario becomes possible:

1. The downstream peer claims the outgoing HTLC on-chain just before it times out
2. The forwarding node needs time to see this transaction, extract the preimage, and broadcast its own claim on the incoming HTLC
3. If the incoming HTLC times out before the node can get its claim transaction confirmed, the upstream peer reclaims those funds
4. The forwarding node loses the payment amount: it paid out downstream but could not collect upstream

Replacement Cycling Attacks

Disclosed in October 2023, replacement cycling is an attack where a malicious peer repeatedly replaces the forwarding node's honest HTLC-claim transaction in the mempool. By cycling conflicting transactions, the attacker tries to prevent the honest transaction from confirming until the timelock expires. Longer CLTV deltas are a key mitigation: they give the forwarding node more attempts to get its transaction confirmed before the deadline.

Channel Jamming Amplification

Larger CLTV deltas can amplify channel jamming attacks. An attacker who sends payments that stall along a route locks up liquidity at each hop for the full timelock duration. Higher deltas mean each jammed HTLC ties up capital for longer, making the attack more effective per attempt.

Maximum Route Timelock

To limit exposure, implementations enforce a maximum total CLTV expiry for incoming HTLCs. The BOLT specification standardized this at 2,016 blocks (approximately two weeks). Any HTLC whose total timelock exceeds this limit is rejected. This cap means that routes with many hops or nodes running very high deltas may fail to find valid paths, since the accumulated delta would exceed the maximum.

Choosing the Right Value

There is no universally correct CLTV expiry delta. The right value depends on a node's specific circumstances:

• Nodes with high uptime and robust monitoring can use lower values (34 to 40 blocks)
• Nodes that go offline regularly or lack dedicated monitoring should use higher values (80 to 144 blocks)
• During periods of sustained mempool congestion, even well-connected nodes benefit from larger margins

For an in-depth discussion of how Bitcoin timelocks work at the protocol level, including both CLTV and CSV, see Bitcoin timelocks: CLTV and CSV explained.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.