Lightning Commitment Transaction
Pronunciation: LYTE-ning kuh-MIHT-ment tran-ZAK-shuhn
Definition
A Lightning commitment transaction is a pre-signed Bitcoin transaction representing one party's enforceable view of a payment channel's current balance. When a new state replaces an old one, revocation secrets make broadcasting the obsolete commitment punishable in traditional channels. Timelocks give the counterparty time to detect and respond. Anchor outputs and fee-management mechanisms affect how closure transactions confirm. Lightning nodes must protect current commitments, revocation data, and channel backups, while watching the chain directly or through a watchtower.
Overview
Each Lightning channel participant holds a commitment transaction that can close the channel on-chain according to the latest agreed state. The two parties’ versions may use different output scripts while representing the same balance allocation and pending HTLCs.
When a new state replaces an old one, revocation secrets make broadcasting the obsolete commitment punishable in traditional channels. Timelocks give the counterparty time to detect and respond. Anchor outputs and fee-management mechanisms affect how closure transactions confirm. Lightning nodes must protect current commitments, revocation data, and channel backups, while watching the chain directly or through a watchtower. Payment services should distinguish off-chain HTLC settlement from final channel closure. Publishing a commitment can create multiple delayed or conditional outputs requiring further sweep transactions.
Lightning Commitment Transaction should be represented as a sequence of observable states rather than one success flag. In Lightning Commitment Transaction implementations, submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available. Operational systems need idempotent processing keyed to stable transaction and business identifiers.
Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Risk-control point: Commitment transactions make channel state enforceable on Bitcoin, with revocation, monitoring, timelocks, and fee management protecting the latest balance.
Key Takeaway
Commitment transactions make channel state enforceable on Bitcoin, with revocation, monitoring, timelocks, and fee management protecting the latest balance.
Sources
- Bitcoin.org Documentation: Payment Processing — Bitcoin.org (2026-07-30)
- Lightning Network Specifications — Lightning Network Developers (2026-07-30)
- Bitcoin Developer Guide: Transactions — Bitcoin.org (2026-07-30)