Channel factories in Lightning are a way of using one on-chain transaction to create a lightning channel between many parties, who can then use updates to the state of this channel to create new off-chain channels between any of the members of the factory. This is cool because it lets you change what a part of the lightning network looks like without actually making new onchain transactions.

This differs fundamentally from routing or rebalancing. Rather than optimizing flows on a fixed graph, [channel factories] enable structural changes to the topology of the graph itself, which potentially makes previously infeasible payments feasible.

Earlier this month, Rene Pickhardt put out his Mathematical Theory of Payment Channel Networks (#1409858), but a few weeks before publishing his theory paper, he made this interesting post on delving: Ark as a Channel Factory: Compressed Liquidity Management for Improved Payment Feasibility in which he describes Ark as a kind of channel factory for lightning.

An alternative interpretation is to treat Ark not as a payment system competing with Lightning, but as infrastructure beneath it. More specifically it can be understood as a channel factory or multi-party channel mechanism.

I find this very interesting. Traditional Lightning is still about as close to onchain bitcoin security as you can get while still being able to pack many many payments into one or two onchain transactions, but the people don't seem to want to use lightning. As many have pointed out, most zaps on nostr seem to be using custodial wallets. If people aren't using custodial, they're probably using trustodial solutions like liquid swaps, Spark, or ecash. Even 100% self-custody wallets like Phoenix have weaker guarantees (if you are using Phoenix mobile, you only have one channel and it's with Phoenix's LSP. They can simply refuse to route to you or refuse to let you route through them).

@justin_shocknet has done a great job helping me understand a fundamental difference between the Lightning Network and Ark or statechains like Spark:^[1] Lightning is an open, permissionless network: you can make a channel with anyone. Ark is a permissioned network: you may have unilateral exit, but you can't just open an ark with anyone you like, it's more of a client-server relationship. In this sense, an Ark is much more like a Lightning channel than it is like the Lightning Network.

Thinking about Ark as a channel factory makes much more sense:

In this framing:

• vTXOs correspond to Lightning channels,
• an Ark round can open, close, or reshape many channels atomically,
• a single on-chain transaction can reconfigure a large fraction of the channel graph.

Thinking about things from a different angle doesn't change their trust assumptions. In my book, Ark still requires more trust and has less censorship resistance guarantees than running a real Lightning node, but it does challenge me to question how much better my Phoenix "node" is than just joining an Ark.

Pickhardt's delving post is a little technical, but there's some interesting discussion in the comments below and it's worth putting the effort in if you want to change your Lightning/Ark paradigm.

1. I would like to note that it's really confusing that Spark, a statechain, decided to use a name that includes "ark" even though Spark is not an ark and Arks are not statechains. Goddammit, bitcoiners, can't we do better with naming? ↩