Payment Channel Network

What Is a Payment Channel Network?

A payment channel network (PCN) is an off-chain scaling solution where pairs of participants open bidirectional payment channels by locking funds in a multisig funding transaction on the blockchain. Once open, the two parties can exchange an unlimited number of transactions between themselves without touching the base layer. A payment channel network takes this further: it connects many individual channels into a graph so that any participant can pay any other participant through a chain of intermediaries, even without a direct channel between them.

If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol through Bob. Bob forwards the payment, earning a small routing fee for providing liquidity and connectivity. Scale this pattern across thousands of nodes and channels, and you get a network where anyone can pay anyone: a payment channel network.

The concept was first described in the 2015 Lightning Network whitepaper by Joseph Poon and Thaddeus Dryja. Since then, the Lightning Network has become the largest and most widely deployed payment channel network, processing payments on Bitcoin's Layer 2.

How It Works

A payment channel network relies on three interlocking mechanisms: channels for bilateral transfers, hash-locked contracts for trustless multi-hop forwarding, and a routing protocol for path discovery.

Channel Foundation

Each channel begins with a funding transaction: both parties deposit funds into a 2-of-2 multisig output on the blockchain. From that point forward, they exchange signed commitment transactions off-chain that redistribute the balance between them. Only when they want to close the channel does a transaction hit the chain. This means thousands of payments can occur between two parties for the cost of two on-chain transactions (open and close).

Multi-Hop Forwarding with HTLCs

The key innovation that turns isolated channels into a network is the Hash Time-Lock Contract (HTLC). When Alice wants to pay Carol through Bob, the payment proceeds atomically:

1. Carol generates a random secret (preimage) and sends its SHA-256 hash to Alice via an invoice
2. Alice creates an HTLC in her channel with Bob: "Bob can claim these funds by revealing the preimage matching this hash before block height N+100"
3. Bob creates a corresponding HTLC in his channel with Carol: "Carol can claim these funds by revealing the same preimage before block height N+60"
4. Carol reveals the preimage to claim funds from Bob
5. Bob uses the revealed preimage to claim funds from Alice

The decreasing timelocks at each hop are critical. Each forwarding node sets a lower expiry than the one it received, creating a safety buffer. If something goes wrong downstream, the upstream node can still reclaim funds on-chain before its own HTLC expires. The default timelock decrement in LND is 40 blocks (roughly 6.7 hours per hop).

Onion-Routed Payments

Payment channel networks protect sender and receiver privacy through onion routing. The sender constructs a layered encrypted packet (defined in BOLT #4) where each hop can only decrypt its own layer, learning only its immediate predecessor and successor. No intermediate node can determine the full path, the total number of hops, or its own position within the route.

The onion packet is 1,366 bytes and supports up to 20 hops. It uses ECDH on secp256k1 for shared secret establishment and ChaCha20 for encryption, with HMAC-SHA256 providing integrity verification at each hop.

# Onion packet structure (BOLT #4)
# 1 byte    - version
# 33 bytes  - ephemeral public key (blinded at each hop)
# 1300 bytes - encrypted hop payloads (TLV-encoded)
# 32 bytes  - HMAC for integrity

# Per-hop payload contains:
#   amt_to_forward    (8 bytes)
#   outgoing_cltv     (4 bytes)
#   short_channel_id  (8 bytes, non-final hops)

Network Graph and Gossip Protocol

For source-based routing to work, every node needs a map of the network. The gossip protocol (BOLT #7) propagates this information through three message types:

• channel_announcement: cooperatively signed by both channel peers, proving the channel exists on-chain and identifying the two nodes
• channel_update: unilaterally issued by either peer, advertising fee rates, HTLC size limits, and timelock requirements
• node_announcement: broadcast by nodes with at least one announced channel, sharing alias and network addresses

Spam protection is built in: a node must prove it controls a valid on-chain UTXO funding a channel before its gossip messages are relayed. However, there is no consensus over the network graph. Different nodes may hold divergent views based on propagation delays and pruning policies.

Pathfinding

Lightning implementations use a modified Dijkstra's algorithm to find routes. The cost function weighs multiple factors: the fees charged by each hop (base fee plus a proportional rate in parts per million), the timelock cost of capital, and the estimated probability of payment success based on historical data.

LND's pathfinding assigns a default 60% success probability for untried channels and tracks per-hop success and failure thresholds over time through a "mission control" system. For large payments, senders may split across multiple routes using multi-path payments (MPP) to improve success rates. For a deeper look at how routing works in practice, see the Lightning Network routing deep dive.

Network Topology

Payment channel networks can theoretically form any topology, but in practice the Lightning Network has developed a scale-free, hub-and-spoke structure. Research published in PLOS ONE found that new nodes preferentially connect to well-established nodes, following a pattern similar to airport and railway networks.

This concentration is significant. Studies have measured the node-capacity Gini coefficient at approximately 0.97, indicating that a small fraction of hub nodes controls the vast majority of network liquidity. Removing central hub nodes causes a sharp drop in network efficiency, while the network is robust to random node removal.

The hub-and-spoke pattern has practical consequences. Routing through a few large hubs is efficient for pathfinding but creates centralization pressure: hub operators gain outsized influence over fee structures and payment success rates. This tension between routing efficiency and decentralization is one of the fundamental tradeoffs in payment channel network design. Proposals like channel factories aim to make channel creation cheaper, potentially enabling a more distributed topology.

Network Effects and Growth Dynamics

Payment channel networks exhibit strong network effects: each new node that opens channels increases the number of possible payment routes for all other participants, following a pattern described by Metcalfe's Law where network value grows proportionally to the square of connected users.

However, PCNs face a bootstrap problem. Users need existing liquidity to route payments, but liquidity requires users willing to lock capital in channels. Routing fee income has historically been low relative to the capital locked, making the economics of running a routing node challenging. Services like Loop and automated liquidity management help node operators maintain balanced channels, but inbound liquidity remains a persistent challenge for new participants.

Liquidity fragmentation compounds the issue. As payments flow in one direction, channels become depleted on one side, requiring rebalancing. Without rebalancing, parts of the network become "islands" disconnected from the denser core: senders may need multiple routing attempts or face delays when paths lack sufficient capacity.

Use Cases

Payment channel networks power a range of applications that benefit from instant, low-fee transactions without on-chain confirmation delays.

• Micropayments: streaming sats for content, API calls priced per request, and pay-per-use services that would be uneconomical with on-chain fees
• Point-of-sale payments: retail transactions where confirmation speed matters and customers expect sub-second settlement
• Cross-border remittances: converting fiat to Bitcoin, routing through a PCN, and converting back at the destination, bypassing correspondent banking delays
• Machine-to-machine payments: IoT devices and automated systems that need to transact small amounts frequently without human intervention
• Gaming and tipping: instant, small-value transfers in social and gaming applications where latency and fees must be negligible

For a comprehensive look at how payment channels evolved from concept to deployed infrastructure, see payment channels: concept to implementation.

Beyond Lightning: Other Payment Channel Networks

While the Lightning Network dominates, other PCN implementations exist across different blockchains:

• Raiden Network: an off-chain scaling solution for ERC-20 token transfers on Ethereum, using a similar channel-based architecture with dedicated pathfinding and monitoring services
• Sprites: an academic proposal that reduces worst-case collateral lockup time from O(path length x confirmation time) to O(path length + confirmation time) using smart contract-based state channels
• Perun: a protocol for virtual payment channels that creates off-chain channels from two existing channels, avoiding additional on-chain costs

Each approach makes different tradeoffs between capital efficiency, trust assumptions, and implementation complexity. For a broader comparison of Bitcoin scaling approaches, see the Bitcoin Layer 2 comparison.

Spark's Approach: Beyond Payment Channels

Spark takes a fundamentally different approach to off-chain payments. Instead of requiring users to open, fund, and manage payment channels, Spark uses statechains: a mechanism that transfers ownership of existing on-chain UTXOs by rotating cryptographic keys between sender, recipient, and a distributed operator set.

In a traditional payment channel network, users must lock capital in channels, manage inbound liquidity, stay online to receive payments, and run or delegate to watchtowers for security. Spark eliminates these requirements: there are no channels to manage, no liquidity to plan, and users can receive payments while offline. The architecture uses a 2-of-2 multisig model where the user holds one key and a distributed operator set collectively holds the other via FROST threshold signatures.

To solve the traditional statechain limitation of transferring only whole UTXOs, Spark introduces a tree structure with "leaves": off-chain representations of partial balances that can be split and merged instantly for arbitrary payment amounts. Users receive pre-signed exit transactions that can be broadcast to Bitcoin's base layer without operator cooperation, preserving self-custody guarantees. For a full technical walkthrough, see What is Spark?.

Risks and Considerations

Liquidity Requirements

Participating in a payment channel network requires locking capital on-chain. Every channel ties up funds that could otherwise be used elsewhere, and the capital must be distributed across channels in the right proportions to support payment flows. For routing nodes, this means significant upfront investment with uncertain returns from routing fees.

Routing Failures

Because channel balances are private, senders cannot verify whether intermediaries have sufficient liquidity before attempting a payment. Failed routing attempts can cascade through multiple retries. For large payments, atomic multi-path payments help by splitting the amount across multiple routes, but success rates still degrade as payment size increases.

Centralization Pressure

The economics of running a routing node favor well-capitalized operators who can maintain many large channels. This naturally pushes the network toward a hub-and-spoke topology where a few large nodes route most payments, creating potential single points of failure and censorship risk.

Online Requirements

In most payment channel networks, recipients must be online to receive payments. Channel participants must also monitor the blockchain for fraudulent channel closes (or delegate monitoring to watchtowers). These liveness requirements add operational complexity compared to simple on-chain transactions.

Griefing and Channel Jamming

Malicious actors can lock up channel liquidity by initiating payments they never intend to complete, a class of attack known as channel jamming. This costs the attacker little but degrades routing capacity for honest users. Proposed mitigations include HTLC endorsement and reputation-based forwarding, but no comprehensive solution has been deployed yet.

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.