Payment Timeout (HTLC Expiry)

What Is a Payment Timeout?

A payment timeout is the expiration deadline built into every Hash Time-Locked Contract (HTLC) on the Lightning Network. Each HTLC includes an absolute block height after which the sender (or forwarding node) can reclaim the locked funds if the payment has not been settled. This mechanism, enforced on-chain by OP_CHECKLOCKTIMEVERIFY, guarantees that funds cannot be held hostage indefinitely by an unresponsive or malicious counterparty.

In a multi-hop Lightning payment, each node along the route holds an HTLC with its own expiry. These expiries form a chain of decreasing timelocks: the sender's HTLC expires last, and each subsequent hop toward the receiver expires earlier. This staggering ensures every forwarding node has enough time to claim its incoming HTLC on-chain after learning the preimage from the downstream hop.

How It Works

The timeout structure is defined by two parameters: the cltv_expiry_delta advertised by each forwarding node, and the min_final_cltv_expiry_delta specified by the receiver in their invoice.

Decreasing Timelock Chain

Consider a payment routed from Alice through Bob and Carol to Dave. The timelocks are constructed from the receiver backward:

1. Dave (receiver) sets a min_final_cltv_expiry_delta of 18 blocks (the BOLT 11 default). If the current block height is 850,000, the HTLC to Dave expires at block 850,018.
2. Carol advertises a cltv_expiry_delta of 40 blocks. The HTLC from Bob to Carol expires at block 850,058 (850,018 + 40).
3. Bob advertises a cltv_expiry_delta of 80 blocks. The HTLC from Alice to Bob expires at block 850,138 (850,058 + 80).

Alice's outgoing HTLC has the longest timelock. If the payment succeeds, the preimage propagates back from Dave through Carol and Bob to Alice, and all HTLCs settle before any timeout is reached. If the payment fails, the HTLCs cancel back from the point of failure.

Alice ──HTLC(expires 850,138)──▶ Bob ──HTLC(expires 850,058)──▶ Carol ──HTLC(expires 850,018)──▶ Dave

Each hop's expiry = next hop's expiry + that hop's cltv_expiry_delta
Total route timeout = sum of all cltv_expiry_deltas + min_final_cltv_expiry_delta

Why the Decreasing Order Matters

The staggered expiry chain solves a critical safety problem. When a forwarding node learns the preimage from the downstream hop, it must have enough time to claim the incoming HTLC from the upstream hop. If the upstream HTLC expired at the same time (or earlier) than the downstream one, the forwarding node could lose funds: it would pay out downstream but be unable to claim upstream because the timelock already expired.

The cltv_expiry_delta is the safety buffer that prevents this. It must be large enough for the forwarding node to broadcast a commitment transaction and an HTLC-timeout transaction, have them confirm on-chain, and then claim the incoming HTLC: all before the incoming timelock expires.

Default Values

Different Lightning implementations use different default cltv_expiry_delta values for forwarding:

The final hop uses min_final_cltv_expiry_delta, which defaults to 18 blocks per the BOLT 11 specification (raised from an earlier default of 9). These values have evolved over time as implementations balance safety margins against routing efficiency.

What Happens When a Payment Times Out

When a payment cannot settle before the HTLC expiry, the timeout mechanism activates. The exact sequence depends on where the failure occurs:

Normal Timeout (Cooperative Failure)

If the receiver does not release the preimage before the final HTLC approaches expiry, the last forwarding node sends an update_fail_htlc message back upstream. Each node along the route cancels its outgoing HTLC and removes it from the commitment transaction. The sender receives a failure notification and can retry through a different route.

Stuck Payments (Uncooperative Failure)

If an intermediate node goes offline while holding a pending HTLC, the payment becomes "stuck." The upstream node cannot cancel the HTLC cooperatively because its counterparty is unreachable. As the expiry approaches, the upstream node must force-close the channel by broadcasting the latest commitment transaction on-chain.

After the force-close, the upstream node waits for the HTLC timeout to pass, then broadcasts an HTLC-timeout transaction to reclaim the funds. This process can take hours or even days depending on the cltv_expiry_delta and on-chain fee conditions. During this time, the sender's funds remain locked.

The Race Condition Risk

A dangerous scenario arises when the offline node comes back online just as the timeout transaction is being broadcast. If the revived node has learned the preimage (from the downstream hop) and broadcasts an HTLC-success transaction, both transactions compete for confirmation. If the HTLC-success transaction confirms and the upstream timeout transaction does not, the forwarding node pays out downstream but cannot claim upstream: a direct loss. This is why sufficient cltv_expiry_delta is essential for safety.

The Timeout Tradeoff

Setting the cltv_expiry_delta involves balancing two competing concerns:

Longer Timeouts: More Safety

• More blocks to get HTLC-timeout transactions confirmed on-chain, even during fee spikes
• Greater protection against replacement cycling attacks
• More resilience against channel jamming and congestion attacks

Shorter Timeouts: Faster Failure and Better Routing

• Sender funds are locked for fewer blocks when payments fail, reducing capital lockup
• Routes with shorter total timelocks are preferred by pathfinding algorithms, attracting more routing volume
• Reduced total route timeout makes longer (more hop) paths feasible without excessive sender lockup

In practice, most forwarding node operators keep the defaults provided by their implementation. Nodes on routes with high reliability (high uptime, well-connected peers) may reduce their delta to attract routing traffic, while nodes prioritizing safety use larger values.

Use Cases

Routing Node Operations

Routing node operators configure their cltv_expiry_delta to balance safety and competitiveness. A node advertising a delta of 40 blocks is more likely to be selected for routes than one advertising 144, since the total route timelock is lower. However, the smaller delta leaves less room for error if a downstream channel must be force-closed during high fee conditions.

Payment Retry Logic

Wallet and application developers use HTLC expiry information to build retry strategies. When a payment fails due to a timeout, the sender knows how long funds were locked and can select alternative routes that avoid high-delta nodes. Modern pathfinding algorithms factor total route timelock into scoring alongside fee rates and channel capacity.

Hodl Invoices and Conditional Payments

Hodl invoices deliberately delay preimage release to enable escrow-like functionality. The payment timeout sets the upper bound on how long a hodl invoice can remain pending before the sender recovers funds. Applications using hodl invoices must monitor the approaching expiry and settle or cancel well before the timeout to avoid force-closures along the route.

Submarine Swaps

Submarine swaps bridge on-chain and off-chain Bitcoin by using a shared hash time-lock across both layers. The HTLC expiry on the Lightning side must be shorter than the on-chain timelock to ensure the swap service can claim its on-chain funds after settling the Lightning payment. Misconfigured timeouts can result in one side expiring before the other settles.

Risks and Considerations

Liquidity Lockup

While an HTLC is pending, the locked funds reduce the available channel capacity for every node along the route. Long timeouts amplify this effect: a single stuck payment with a 144-block delta ties up liquidity for approximately 24 hours across multiple channels.

Fee Spike Vulnerability

If on-chain fees rise sharply while an HTLC is pending, the pre-signed commitment transaction and HTLC-timeout transaction may not confirm quickly enough. Anchor outputs (used in modern channel types) mitigate this by allowing fee bumping via CPFP, but the risk is not eliminated entirely.

Congestion and Jamming Attacks

Attackers can exploit HTLC timeouts to lock up network liquidity. By sending payments through many channels and never releasing the preimage, an attacker forces all intermediate nodes to hold HTLCs until timeout. The longer the cltv_expiry_delta, the more effective this attack becomes. Proposed mitigations include HTLC endorsement and reputation-based forwarding.

Force-Close Cascades

When multiple HTLCs approach expiry simultaneously across several channels, a node may need to force-close multiple channels at once. This creates a burst of on-chain transactions that compete for block space, potentially delaying confirmations and triggering further force-closures. For a deeper analysis of Lightning routing mechanics and failure modes, see the Lightning Network routing deep dive.

Why It Matters for Spark

Payment timeouts and HTLC expiry are fundamental constraints of the Lightning Network's payment channel design. Spark takes a different approach by using statechains and virtual UTXOs (vTXOs) rather than HTLC-based payment channels. This architecture avoids the decreasing timelock chain entirely: users are not exposed to stuck payments from offline intermediaries, force-close deadlines, or the safety-versus-speed tradeoff that forwarding nodes face. Payments on Spark settle without requiring each hop to maintain an independent timeout buffer, resulting in a simpler user experience for everyday Bitcoin transactions.

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.