Hashed Time-Locked Contract combines a hash condition with a time condition. In Lightning, each hop forwards an HTLC carrying an amount, payment_hash and cltv_expiry; revealing the matching preimage fulfills the payment backward through the route, while timeout paths protect participants if fulfillment does not arrive in time.
The sender commits to a SHA-256 payment hash. The receiver can complete the payment only by revealing a preimage whose SHA-256 equals that hash. This makes the same secret usable as an atomic settlement condition across multiple channel hops.
Every forwarded HTLC also carries an absolute CLTV expiry. If the preimage is not learned before the relevant deadlines, channel participants need enough time to fail or enforce the contract on-chain before upstream expiries are reached.
In normal Lightning operation, HTLCs are channel-state updates exchanged with update_add_htlc and later settled or failed off-chain. Bitcoin transactions appear only when a channel must enforce the latest state on-chain.
update_add_htlc includes channel_id, id, amount_msat, payment_hash, cltv_expiry and an onion_routing_packet. The receiving peer checks policy and forwards a related HTLC rather than blindly copying the incoming one.
The onion packet gives each hop only the information needed for its next action. A forwarding node checks the amount and outgoing CLTV value against its encrypted payload, reducing route disclosure while preserving enforceable forwarding conditions.
A forwarding node requires an incoming expiry later than the outgoing expiry. That CLTV delta is not arbitrary padding: it gives the node time to react on-chain if its downstream peer reveals a preimage or fails near the deadline.
BOLT #3 commitment transactions encode offered and received HTLC outputs with success and timeout spending paths. The exact scripts combine hashes, signatures and timelocks so either fulfillment or timeout can be enforced if cooperation ends.
If an HTLC output would be below the commitment transaction's dust threshold after considering fees, it can be trimmed instead of appearing as its own on-chain output. BOLT #2 therefore treats dust exposure as a real channel risk even though the HTLC still exists in off-chain accounting.
A routed payment succeeds only if every hop accepts the forwarding conditions and the receiver reveals the preimage. Liquidity, channel policy, fee limits, expiry limits and route failures can all prevent settlement before any Bitcoin consensus issue is involved.
Inspect update_add_htlc fields in a Lightning implementation, compare incoming and outgoing amount/CLTV deltas, and trace fulfill or fail messages. For on-chain enforcement, decode the commitment transaction and inspect the BOLT #3 HTLC output and its success/timeout path.
For the clearest picture, read this entry together with Lightning Network, Payment Channel, Timelock, Cryptographic hash, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. The reverse links also lead from Timelock, Payment Channel, Lightning liquidity, Lightning Routing.