Design a Crypto Payment Channel Network (Like Lightning)

Problem statement

Design a crypto payment channel network that lets two parties lock funds on a base blockchain, exchange thousands of off-chain value transfers against that locked balance, and touch the chain again only when the channel is closed or disputed. Extend the design so a payment can traverse many channels through intermediaries, reaching any participant in the network without a trusted central operator.

The root constraint is the base layer itself. A Bitcoin-class chain settles roughly one block every ten minutes, caps block weight at about four million weight units, and sustains on the order of seven transactions per second globally. Public figures put daily base-layer throughput around 400,000-500,000 transactions. When demand spikes, fee markets price out small payments entirely: a 5,000-satoshi transfer paying a 3,000-satoshi fee is not a payment product. Micropayments, streaming payments, and point-of-sale latency are all impossible against those physics.

A payment channel network inverts the model. The chain becomes a settlement and dispute layer, not a throughput layer. Two users create a 2-of-2 funding output on-chain once. Every subsequent transfer is just an exchange of signed, partially-signed, or revocable transactions that redistribute that same output. Because both parties must sign each new state, neither can move funds unilaterally, and because every old state is cryptographically revoked, neither can safely cheat by publishing stale balances. Only open, close, and dispute ever consume block space.

Why this is distinctive as a design problem

A conventional payment gateway retries a failed charge. A payment channel network cannot retry a double-spend. The design therefore separates payment velocity from settlement finality. Velocity—thousands of updates per second, sub-second confirmation between counterparties—is achieved off-chain with bilateral signed state. Finality—the guarantee that a balance can actually be redeemed—remains anchored to base-layer consensus and is only as strong as the ability to publish a transaction within a protocol-defined window. Every architectural decision in this answer follows from keeping those two planes separate and making the off-chain plane safe even when one counterparty disappears.

The four architectural planes

1. On-chain settlement plane: the base blockchain, funding and commitment transactions, HTLC outputs, timelocks, and fee markets.
2. Channel state plane: bilateral signed commitments, revocation keys, HTLC lifecycle, and reestablishment after disconnects.
3. Network plane: peer topology, gossip of signed channel and node announcements, route discovery, and watchtowers.
4. Application plane: wallets, invoices, merchant gateways, liquidity providers, and payment orchestration.

A strong interview answer keeps these planes distinct. The network plane may be eventually consistent and even partially wrong; the channel state plane must never be. A routing node with a stale graph loses an opportunity. A node with inconsistent channel state loses money.

Public operating baseline versus design assumptions

Public snapshots of the Lightning Network show the category is real: on the order of five thousand BTC of public capacity, roughly thirteen thousand public nodes, and tens of thousands of public channels, with figures varying by data source and by the economic cycle of channel opens and closes. Real payment processors route real volume on this substrate, and several companies cited later in this answer publish meaningful operating details. Those are cited context figures, not our design targets.

For capacity planning this answer assumes a mature network with 60,000 routing-capable nodes, 200,000 channels, 3,000,000 payment attempts per day, and a five-times event peak. Unless a number is tied to a citation, it is a stated design assumption, target, or budget—not a claim about any company's private architecture.