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.
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? ↩
Ark reframes Lightning reshaping channels atomically instead of just routing payments feels like the next layer of network efficiency.
Could Ark as a channel factory make Lightning payments more flexible without adding on-chain transactions, despite higher trust trade offs?
Not really. Try opening a channel to Bitfinex, Binance or FixedFloat. They won't let you (((
I thought about a more nuanced turn of phrase, but I got lazy and went with the blunt generality.
Makes more sense in the context as affinity scamming as a lightning wallet, and apparently "shock" was taken
This is the desperation pivot narrative from these schemes, its not new, but was also never at the forefront. Better awareness of the fact these are trustodial fake lightning wallets leaves them grasping at the channel factory use-case. Renee is just picking up on something Ark shills have said in flailing arguments over the last year or so.
It's desperation because that use-case has already been debunked as regular batch channel opens that reduce channel costs 80+% have existed for ages... yet remain unused. They remain unused because cost is not a meaningful barrier to adoption, and coordination still involves centralizing trust.
This is the important part, I think. People aren't using custodial lightning wallets to save on channel opening fees -- they don't want to run a lightning node, they don't want to have to open and close channels, and they don't want to think about liquidity.
But I'm curious how different the trust assumption is between a single channel with Phoenix LSP and something like Spark. Phoenix routes my payments and I have to pay attention (a little) to liquidity. Spark makes atomic swaps for me when I want to do lightning payments, but I have to come back online at least every two weeks if I really want to be safe. So in both cases, the company can't steal my sats outright, but they can refuse to let me access the larger lightning network. As far as unilateral exit, that really comes down to you needing enough sats to pay for an onchain tx.
Would you also describe it this way or is there some major difference between the two that I'm missing?
Not so sure about this, custodial does have economies of scale and sunk costs.
The tinkering user may pay more in custodian fees over time, and a volume user definitely will, but the upfront cost is practically nothing. Users generally have a very high time preference and will gladly pay 10k sats over a year than 1k sats up front.
Primarily because they see the cost
Phoenix is a good example of idiot-proof automation which is why its done well, but the biggest complaint users have is about costs.
This is likely the biggest factor, and Lightning is a cost center if you're offline. Custodians are always online. Phoenix/Zeus are so expensive because you can't earn money while you sleep, and a great example of why mobile nodes are a dead-end because they'll always be a cost-center not a tool for revenue.
So refine my earlier point, ABSOLUTE COST is not a barrier to adoption... but up-front or mental costs may be.
Channel factories don't solve that any better than batch opens, nor do they absolve the trust and centralization of custodial "graduated" on-boarding.
They're the same because they face the same underlying physics of the chain, the techno-babble Fake L2's use is an effort to distract people from this and why they are scammers.
They have to scam the user so that they be consistent when scamming the regulator, they're big companies that don't want to attract attention as a custodian, and they don't provide any real services they can monetize.
Phoenix bootstraps your liquidity with a trusted LSP credit (Lightning.Pub does this too). During this time it is completely trusted. It has to be this way because if you can't afford to hit the chain you can't afford the security of said chain. They do not feel the need to scam the regulator because what they're custodying is a service credit, not a financial service.
Once you can redeem that service credit for a proper LN channel, it becomes trustless because of the unilateral exit ability since Lighting is chain anchored.
Spark is similar, it's trusted until you exit to a real channel.
Anything above the chain has an online-ness requirement, that doesn't make it not trustless, because you still control whether your defending your claim or not. It's an additional security trade-off you're making to coordinate above the chain, not trust.
Any L2 system will have this trade-off, and there's also no such thing as off-line payments on L2's despite the claims of many a scammer or script kid. You need to be online to communicate with the chain to redeem and defend any claims you may have on layers above it.
thanks! this was very helpful.