Ark as a Channel Factory: Compressed Liquidity Management for Improved Payment Feasibility

There are two components to the liquiditiy requirements:

  1. ASP: worst-case overlap exposure, where refreshed vtxos are in a forefeited yet not viable to sweep in a vbytes-cheap state(tree timeout). With LN on top, the velocity of these Ark refreshes can go down.
  2. LSP: Inbound liquidity: Either during construction or over time, LSPs choose to have money parked into channels, and in many contexts, are never used. If the mobile user is online they could splice it out (for vbytes cost), but the user may almost never come back online. Layering LN on Ark allows this “targeting” to more tightly track practical usage. If too much is allocated, it can be reclaimed as the tree times out. If too little, a new channel can simply be instantiated in a new tree (concurrent channels, or consolidating via revocation of old vtxo, at additional liquidity cost of refresh!)

The challenge here is that while marginal vbytes have dropped to ~0, there is the ASP/LSP liquidity optimization challenge left and that is what (someone) should explore.

I also have to note that the ASP/LSP have to be the same identity or trust each other otherwise the LSP is on the hook for unrolling channels when the mobile client turns off their phone, otherwise they hand all their money to the ASP at tree timeout.

3 Likes