哈希时间锁定合约结合了哈希和时间条件。在闪电网络中，每一跳都会转发一个包含 amount、 payment_hash 和 cltv_expiry 的 HTLC；显示匹配的原像可以通过路线向后完成支付，而如果履行未及时到达，则超时可以保护参与者。
发件人使用 SHA-256 付款哈希。接收者通过显示 SHA-256 与该哈希值完全匹配的原像来完成付款。因此，同一个秘密绑定了多跳的原子结算。
每个 HTLC 都有一个绝对 CLTV 到期日。如果原像没有及时到达，节点必须有足够的空间来使交易失败或在其上游承诺到期之前推送到链上。
在正常的闪电操作中，HTLC 是通过 update_add_htlc 以及随后的完成或失败进行通道状态更改。仅当通道在链上强制执行时才需要比特币交易。
update_add_htlc包含channel_id、id、amount_msat、 payment_hash、cltv_expiry和onion_routing_packet。 Peer 检查策略并创建后续 HTLC；它不只是盲目地复制输入对象。
洋葱数据包将仅向该跃点显示下一步所需的信息。节点将金额和传出的 CLTV 与加密的有效负载进行比较，因此它可以在不知道整个路径的情况下验证条件。
转发节点要求传入的到期时间晚于传出的到期时间。如果下游检测到原像或在截止日期前发生故障，这种差异会给予链上反应时间。
BOLT #3 将提供/接收的 HTLC 输出写入成功和超时分支的承诺交易。这些脚本将哈希、签名和时间锁结合在一起，即使没有交易对手的合作，结果也可以强制执行。
如果 HTLC 输出在扣除费用后低于交易的粉尘阈值承诺，则可以从链上输出中削减。这就是为什么 BOLT #2 将灰尘暴露视为真正的渠道风险。
仅当每一跳都接受条件并且接收者显示原像时，支付才会成功。流动性、费用限制、到期限制和路由策略可以在比特币达成共识层之前很久就停止支付。
检查 update_add_htlc、传入/传出金额和 CLTV 增量并监控履行/失败消息。对于链上执行，解码 HTLC 输出的承诺交易和 BOLT #3 成功/超时路径。
要获得更完整的理解，请将本词条与以下词条结合阅读： Lightning Network, Payment Channel, Timelock, 密码学哈希, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. 反向关联还来自： Timelock, Payment Channel, Lightning流动性, Lightning Routing.