Payment Channel

What Is a Payment Channel?

A payment channel is an off-chain protocol that allows two parties to transact directly with each other without broadcasting every transaction to the blockchain. The two participants lock funds into a shared address on-chain, exchange signed transactions between themselves to update their balances, and only settle the final result on-chain when they are done. Regardless of whether they make ten payments or ten million, only two on-chain transactions are required: one to open the channel and one to close it.

Payment channels solve a fundamental scaling problem. Bitcoin's base layer processes roughly 7 transactions per second. By moving the bulk of transaction activity off-chain, payment channels allow throughput to scale independently of block space constraints. The blockchain serves as a settlement layer and dispute resolution mechanism rather than a ledger for every individual payment.

The concept has evolved significantly since Bitcoin's early days. Rudimentary transaction replacement was possible in Bitcoin 0.1 using the nSequence field, but practical payment channels emerged in 2013 with Jeremy Spilman's unidirectional design. The breakthrough came in 2015 when Joseph Poon and Thaddeus Dryja published the Lightning Network whitepaper, introducing bidirectional channels with a penalty-based revocation mechanism that supports unlimited updates.

How It Works

A payment channel follows a three-phase lifecycle: open, transact, and close. The critical insight is that the transact phase happens entirely off-chain, using cryptographic guarantees rather than blockchain consensus to ensure honesty.

Opening the Channel

Two parties (Alice and Bob) create a funding transaction that sends bitcoin to a 2-of-2 multisig address. Both parties must sign to spend from this address. Before broadcasting the funding transaction, they exchange initial commitment transactions as a safety measure: if one party disappears after funding, the other can still recover their funds.

Once the funding transaction confirms on-chain, the channel is open. The amount locked in the funding transaction establishes the channel's maximum capacity: the total value the channel can handle at any time.

Transacting Off-Chain

With the channel open, Alice and Bob exchange signed commitment transactions that spend from the funding output. Each new commitment reflects updated balances. For example:

1. Opening state: Alice has 0.5 BTC, Bob has 0.5 BTC
2. Alice pays Bob 0.1 BTC: Alice has 0.4 BTC, Bob has 0.6 BTC
3. Bob pays Alice 0.05 BTC: Alice has 0.45 BTC, Bob has 0.55 BTC

Each commitment transaction is a valid Bitcoin transaction that could be broadcast at any time, but neither party broadcasts it. They simply keep the latest signed state locally. For every new update, both parties exchange revocation secrets for the previous state, cryptographically invalidating old commitments.

Closing the Channel

When either party wants to settle, two closing paths are available:

• Cooperative close: both parties agree on the final balances, sign a clean closing transaction, and broadcast it. This is the normal path.
• Force close: one party unilaterally broadcasts their latest commitment transaction. The broadcaster's output is subject to a timelock (typically 144 blocks), giving the counterparty a window to dispute if a revoked state was used.

The Penalty Mechanism

Lightning Network channels use an LN-Penalty mechanism to deter cheating. Each commitment transaction is asymmetric: the broadcaster's output requires waiting through a timelock period (OP_CHECKSEQUENCEVERIFY), while the counterparty's output is immediately spendable.

If a party broadcasts a revoked commitment (an old state that gives them more funds than they are entitled to), the counterparty can use the revocation secret to construct a justice transaction that sweeps the cheater's entire channel balance. The penalty is total by design: the cheating party risks losing everything in the channel, making fraud economically irrational.

# Simplified to_local output script (BOLT #3)
OP_IF
    <revocationpubkey>       # Counterparty can spend immediately with revocation key
OP_ELSE
    <to_self_delay>
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayed_pubkey>   # Broadcaster can spend after delay
OP_ENDIF

Third-party watchtowers can monitor the blockchain on behalf of offline users and submit justice transactions if revoked states are detected, providing security even when a user is not continuously online.

Evolution of Payment Channels

Payment channels have gone through several generations, each addressing limitations of the previous design:

For a detailed walkthrough of each generation, see the research article on payment channels from concept to implementation.

Payment Channel Networks

A single payment channel connects exactly two parties. To send a payment to someone you don't share a channel with, you need a network of interconnected channels that can route payments through intermediaries. This is the core idea behind the Lightning Network.

Routing with HTLCs

Multi-hop routing uses Hash Time-Locked Contracts (HTLCs) to ensure payments are atomic: either every hop along the route settles, or none of them do.

1. The recipient generates a random secret (preimage) and sends its hash to the sender
2. The sender creates an HTLC in their channel with the first intermediary: "pay X sats if you reveal the preimage of this hash before block Y"
3. Each intermediary creates a corresponding HTLC in the next channel with a shorter timelock, ensuring every hop has time to claim before the previous hop expires
4. The recipient reveals the preimage to claim the final HTLC
5. The preimage propagates backward along the route, settling each HTLC in sequence

Intermediary nodes charge small routing fees for forwarding payments. Onion routing ensures that each hop only knows its immediate predecessor and successor, preserving sender and receiver privacy.

Capacity and Liquidity Constraints

Channel-based networks face inherent liquidity management challenges. A channel's total capacity is fixed at opening, and funds can only flow in one direction at a time. Inbound liquidity (funds on the remote side) determines how much you can receive, while outbound liquidity determines how much you can send. Unidirectional payment flows gradually push all capacity to one side, requiring rebalancing, submarine swaps, or splicing to restore balance.

Each side must also maintain a channel reserve (typically 1% of capacity) as collateral. This reserve ensures both parties have economic stake in honest behavior but reduces the amount available for payments. For a deeper analysis of these dynamics, see the research on Lightning Network liquidity.

Use Cases

• Micropayments: payment channels make sub-cent transactions economically viable by avoiding on-chain fees for each transfer, enabling pay-per-use APIs, streaming sats, and tipping
• High-frequency trading: two exchanges or market makers can settle thousands of trades off-chain within a channel, recording only the net result on-chain
• Point-of-sale payments: merchants accept instant, final payments through Lightning channels without waiting for block confirmations
• Cross-border remittances: channel networks enable near-instant international transfers at a fraction of the cost of traditional correspondent banking
• Machine-to-machine payments: IoT devices can open payment channels for automated resource trading without human intervention

Risks and Considerations

Online Requirement

In penalty-based channels, both parties must monitor the blockchain for revoked commitment broadcasts. If a user goes offline for an extended period and their counterparty broadcasts a revoked state, the user could lose funds unless a watchtower submits the justice transaction on their behalf. This always-online assumption creates friction for mobile and intermittent-connectivity use cases.

Liquidity Management

Running a productive routing node requires continuous liquidity management: balancing channels, acquiring inbound liquidity, and managing capital allocation across many channels. This operational overhead is a barrier for casual users and a significant cost for businesses.

Channel Jamming

Attackers can lock up channel liquidity by sending payments and never settling them, a form of channel jamming. This ties up capital across every routing node along the path. Solutions like HTLC endorsement and upfront fees are under active development.

Force Close Costs

When a channel is force-closed, the closing party must pay on-chain fees and wait through a timelock period (often 144 blocks, roughly one day) before accessing their funds. During periods of high fee market congestion, force-close costs can consume a significant portion of the channel balance, particularly for smaller channels.

Payment Channels vs. Statechains

Statechains offer an alternative off-chain scaling model that avoids channels entirely. Instead of locking funds in a shared address and exchanging commitment transactions, statechains transfer ownership of a UTXO by rotating cryptographic key shares between parties. The on-chain UTXO never moves: what changes is the ability to sign for it.

Spark uses this statechain-based architecture with FROST threshold signatures for its signing protocol. This eliminates channel management, inbound liquidity constraints, and the requirement to be online to receive payments. Users can receive funds at any time, split and merge balances off-chain, and exit to the Bitcoin base layer unilaterally through pre-signed transactions. The tradeoff is a trust assumption: Spark's model requires at least one of the operator set's members to behave honestly, whereas payment channels are fully trustless between the two counterparties. For a detailed comparison of Bitcoin scaling approaches, see the research on Bitcoin Layer 2 solutions.

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.