Dear fellow lightning network developers
I’ve posted a new paper on arXiv that formalizes several long-standing observations about payment channel networks (in particular with the lightning network in mind) under a single geometric framework:
https://arxiv.org/pdf/2601.04835
Many of the individual phenomena discussed in the paper are familiar to practitioners:
- channel depletion,
- capital inefficiency of two-party channels,
- the benefits of channel factories,
- and the idea that feasibility rather than routing is the real bottleneck.
The goal of this work was not to rediscover these effects, but to explain why they are structurally true and how they are connected. A key outcome of the paper is the perspective that payments should be analyzed through the set of feasible wealth distributions rather than individual paths. Liquidity states differ only by circulations within fibers over a polytope. A payment is feasible if and only if the resulting wealth vector remains inside that polytope and offchain rebalancing does not change this (as was noted by others in 2018 on lightning-dev). This leads to:
- a simple throughput law
S=c/rlinking the supported off-chain payment bandwidthSto the raterof infeasible payment attempts and onchain transaction bandwidthc - a cut-based characterization of feasibility,
- a formal explanation of why multi-party channels (coinpools / channel factories) are structurally more capital-efficient,
- and a geometric explanation of why linear asymmetric fees generically lead to channel depletion.
These insights directly motivated the recent Delving Bitcoin article, which explores Ark as a channel factory and its implications for payment feasibility:
The paper also analyzes mitigation strategies for depletion such as symmetric fees, convex/tiered fee schedules, and coordinated off-chain replenishment while explaining why some of these are difficult to deploy under today’s source-routing model.
For readers interested in simulations and executable intuition, much of the reasoning was developed alongside code and notebooks, which are collected here:
Feedback and Questions are very welcome, especially on how these results should influence protocol design and whether multi-party channels should primarily serve as channel factories or as long-lived payment venues.
With kind regards Rene Pickhardt