Scaling & Layer 2

payment channel

A payment channel is a state channel narrowed to a single job: moving money back and forth between two parties many times while settling on-chain only once at the end. It is the original and most successful Layer-2 construction. Two people open a channel by jointly funding a multisignature output; from then on they can pay each other simply by signing a new balance allocation, with no fee and no waiting for blocks. The chain records the opening deposit and, eventually, the final split — but not the hundreds or thousands of payments in between.

A bidirectional channel needs a way to invalidate stale states so neither side can cash out an earlier, more favourable balance. The standard trick (used by Lightning) is a revocable commitment: each time the balance updates, the parties exchange the secret keys that would let the other punish them for broadcasting the now-obsolete state. If Bob ever publishes an old commitment, Alice can use the revocation secret to claim the entire channel balance during a timelocked dispute window. This penalty is what makes cheating irrational without a trusted third party.

The economics matter. A channel can only route value it already holds: your 'outbound' capacity is your side of the balance, and you cannot send more than that without rebalancing or closing and reopening. Funds are locked for the channel's lifetime, and on-chain fees at open and close make tiny one-off channels uneconomic. Payment channels therefore shine for high-frequency, repeated payments between known counterparties — streaming micropayments, machine-to-machine settlement, or hubs that many users connect to — rather than for paying a different stranger once.

Channel 'balance' is not one number but two capacities: how much you can still send (your outbound) and how much you can still receive (your inbound). A merchant with empty inbound capacity cannot accept a payment even though the channel is open and funded.