Ark as a conduit factory: compressing liquidity management to improve payment feasibility.

Author: Pickhardt

Source: https://delvingbitcoin.org/t/ark-as-a-channel-factory-compressed-liquidity-management-for-improved-payment-feasibility/2179

I have discussed the ideas in this article in numerous bilateral conversations over the past few months. To avoid repeating incoherent claims and to invite further feedback, I have written them down here. I apologize to readers already familiar with these concepts and welcome comments, rebuttals, and open questions.

Note: Because my native language is not English, I used LLM (Large Language Model) to polish my writing; however, the technical content and arguments are my own. When guiding the LLM, I did not deviate from standard format and language style.

summary

The Lightning Network supports fast, non-custodial Bitcoin payments, provided there is sufficient liquidity along the path of a payment flow (typically only one path). However, payment feasibility (the existence of such a payment flow) is a structural constraint that cannot be solved simply through heuristic analysis of routing or off-chain rebalancing. When liquidity is insufficient, in-chain transactions must be sent to modify the channel graph , which fundamentally limits the Lightning Network's ability to scale up Bitcoin payment throughput.

While multi-party channels are known to improve capital efficiency, coordination is challenging in practice. Ark proposes a mechanism to coordinate state updates across multiple parties on a round-by-round basis, enabling members to reach consensus on a new state with relatively low coordination overhead. This paper challenges the prevailing view that Ark should primarily function as a "last-mile" payment system, connecting with each other via Lightning Channels. Instead, this paper argues that it might be better to understand Ark as the infrastructure of the Lightning Network , particularly as a " channel factory " that enables efficient liquidity reallocation. This paper focuses on the trade-offs, feasibility constraints, and open research questions.

Important reminder : This article does not explicitly oppose the use of Ark for payments, but merely explores whether there are better application scenarios.

1. Review payment feasibility and the structural limitations of the Lightning Network

A single lightning payment is feasible when the minimum cut between the sender and receiver in the liquidity graph exceeds the payment amount. In practice, feasibility is difficult to determine due to the uncertainty of the channel balance at the remote end . This uncertainty can be reduced by using probabilistic routing and optimal reliable payment flows .

However, even if optimizing routes, updating fees, and rebalancing can improve utilization, they cannot change the overall payment feasibility unless the channel graph itself is changed.

Especially:

• Off-chain rebalancing techniques can redistribute liquidity within existing channels.
• It does not create new connectivity or directional capacity.
• When no feasible payment flow exists, an in-chain transaction needs to be initiated (opening a channel, closing a channel, concatenating channels, etc.).

This distinction is key. Even if a node can move liquidity from one channel to another (via loop payments), such an operation affects the distant channel and therefore does not specifically increase the feasibility of a desired payment. The only way to locally alter feasibility without affecting the rest of the network is through in-chain transactions.

The formal analysis in " A Mathematical Theory of Payment Channel Networks " proves that the maximum supported payment rate is highly dependent on:

• Fixed available in-chain bandwidth, and
• The expected rate of non-feasible payments.

This imposes severe limitations on two-party payment channel networks, and under realistic assumptions, the anticipated rate of infeasible payments can become extremely high without continuous on-chain bandwidth support. This limitation has prompted the exploration of coordination mechanisms to reconstruct the payment network graph topology with a smaller on-chain footprint.

2. Ark: Turn-based and Virtual UTXO

Ark introduces the concept of " rounds ": participants in the same round exchange " virtual UTXOs (vTXOs)" under the coordination of an Ark Service Provider (ASP). These vTXOs represent off-chain value commitments that can be redistributed over a period of time.

It appears that the Ark-style system reduces the coordination and online interaction requirements of the coin pool by introducing an ASP as a coordinator; the ASP provides excess liquidity within a fixed time window, thus eliminating the need for everyone to immediately agree on every new state, requiring only eventual agreement. This is a very desirable property.

However, when Ark is used directly as a payment system, its three properties cannot be ignored:

1. Liquidity lock-up due to expiration mechanism : vTXO has an expiration mechanism, where ASP funds are tied up until expiration.
2. Change amplification : Payments typically involve destroying an input and creating multiple outputs (receipt and change), which increases the amount of liquidity that ASPs must advance.
3. Trust factors in inter-round settlement : Payments can only be finally settled at the round boundary. Between two rounds, spent vTXO can theoretically be spent again, which raises questions about the compliance interpretation of hosting and ASP roles.

If vTXOs are frequently paid out before maturity, the operating capital required by the ASP could increase significantly (relative to net payments) . This complicates the argument that Ark can provide a low-overhead, scalable payment layer on its own.

3. View Ark as a channel factory and the infrastructure of the Lightning Network.

Another interpretation is not to view Ark as a payment system competing with the Lightning Network, but rather as the infrastructure beneath the Lightning Network . More specifically, it can be understood as a channel factory, or a multi-channel mechanism .

Under this understanding:

• vTXO corresponds to the Lightning channel.
• An Ark round can automatically open, close, and reshape many channels.
• A single in-chain transaction can reconstruct a large portion of the channel graph .

This is fundamentally different from routing and (off-chain) rebalancing. Instead of optimizing payment flows within a fixed graph, it brings about a structural change in the graph itself, which can make previously infeasible payments feasible.

Multiple channel operations—funding, closing, and splicing—can all be compressed into a single Ark round transaction. Because the Lightning Network already requires on-chain confirmation for such changes, Ark will not exacerbate latency, as Ark rounds can ultimately occur within each block.

4. Liquidity reallocation and operational considerations

Lightning Network operators already need:

• Monitoring channel
• Responding to in-chain events,
• Occasionally rebalance or shut down the channel.

Rotating vTXOs within Ark rounds (e.g., a few times per month) is operationally similar. Channels with higher utilization may require more frequent rotations, which can be coordinated while the channel is still being actively used.

The failure assumptions differ in detail but are the same in type: operators need to participate periodically, rather than continuously monitor.

5. Liquidity Pools and Dynamic Allocation

In a channel factory (or multi-channel):

• Liquidity will form a pool among participants.
• The size of each pool can be adjusted in rounds.
• Demand can be predicted or responded to dynamically.

This is the exact opposite of the current LSP model: in the LSP model, liquidity is provided on a per-user basis and is usually kept idle or unevenly distributed.

Pooling can improve capital efficiency—especially (but not limited to) mobile clients—and this applies to Ark as well, though it introduces trade-offs, including expiration events, coordination overhead, and ASP liquidity management. Determining the optimal timeout parameters (allowing ASPs to reclaim vTXOs) remains an open question.

6. Integration with Lightning Network and Hosting Considerations

When Ark is used as an infrastructure:

• The payment occurs within the Lightning Channel/Network.
• Settlement remains atomic and end-to-end.
• ASPs coordinate liquidity but do not act as intermediaries for payments.

This preserves the unmanaged, real-time settlement properties of Lightning Channel. In contrast, using Ark directly in payments introduces trust assumptions between rounds.

Each component has its own function—Lightning Channels are used for payments, and Ark is used for liquidity coordination—maintaining the Lightning Network's core guarantees, such as instant payment settlement and robust privacy, while addressing structural scalability limitations.

7. Routing, Gossip, and Openness Issues

The channel for funding via vTXO lacks on-chain funding transactions, therefore it cannot currently be publicly disclosed via Lightning Network gossip. This raises several open questions:

• How should such a channel be represented to the router?
• Should routing run at the factory level?
• Does "liquidity advertising" need a new abstraction?
• How will these mechanisms affect privacy and reliability?
• Should vTXO-based channels be restricted to exist only between the ASP and the user? Or can they exist directly between users?

8. Extended Openness Issues

Viewing Ark as the infrastructure of the Lightning Network, rather than a standalone payment system, clarifies some trade-offs, but also raises some other open questions worth exploring:

• Incentives and ASP Behavior : How can incentives be aligned so that ASP liquidity management decisions improve payment viability at the Lightning Network level, rather than just localized profitability? How will competition among multiple ASPs affect liquidity allocation and pricing?
• Centralization pressures : Will pooling liquidity in a multi-party structure favor economies of scale for a smaller number of large-scale factories? How does this compare to the effects of existing payment centers and LSPs in the Lightning Network?
• Failure Modes and Exits : Based on Peter Todd's article on Layer 2 ( Chinese translation ): What are the on-chain and operational consequences of an ASP failure (or large-scale exit)? How can the system's stress be gracefully released? And, in the worst-case scenario, what is the cost of on-chain operations?
• Latency and Feasibility : Ark supports structural reconfiguration, but only once per round. How should the round frequency and expiration window be chosen to balance payment feasibility, capital efficiency, and user experience?
• Privacy considerations : Will round-based coordination mechanisms gradually leak information about demand patterns or user activity? How do anonymous sets compare to two-way lightning channels?
• Interoperability and routing abstraction : How should a vTXO funding channel be represented to the router (given that it has no in-chain funding transactions)? Is a new gossip message or a factory-level abstraction required?

These issues are not unique to Ark; rather, they are questions that will naturally arise whenever a multi-party liquidity coordinating mechanism emerges. Solving them is fundamental to understanding how such a mechanism complements the Lightning Network.

References

1. Pickhardt et al., On the Uncertainty of Lightning Network Channel Balances [ 2103.08576] Security and Privacy of Lightning Network Payments with Uncertain Channel Balances
2. Pickhardt & Richter, Optimally Reliable Payment Flows on the Lightning Network [ 2107.05322] Optimally Reliable & Cheap Payment Flows on the Lightning Network
3. Pickhardt A Mathematical Theory of Payment Channel Networks (draft) [Lightning-Network-Limitations/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf at f670738cd2af93a55c3c919c9a864015f6dd042a · renepickhardt/Lightning-Network-Limitations · GitHub]( https://github.com/renepickhardt/Lightning-Network-Limitations/blob/f670738cd2af93a55c3c919c9a864015f6dd042a/Limits of two party channels/paper/a mathematical theory of payment channel networks.pdf)
4. Pickhardt How well does Ark scale Bitcoin payments? https://bitcoin.stackexchange.com/questions/128113/how-well-does-ark-scale-bitcoin-payments 5 Todd, Covenant dependent layer 2 review Soft-Fork/Covenant Dependent Layer 2 Review .
5. BTC++ Talk on Lightning scaling and limitations https://www.youtube.com/watch?v=c3AuaHJordg
6. Bitcoin Amsterdam LN vs Ark panel (2025) https://www.youtube.com/watch?v=AU52kQz2zIM

Acknowledgments

Discussions and feedback from many friends on BTC++ and Bitcoin Amsterdam helped me clarify these arguments. This research was funded by Optensats and Patreons.