Bitcoin Magazine
Ark and Spark: The Channel Factories We’ve Been Waiting For
Visions of future technology are often prescient about the broad strokes while flubbing the details. The tablets in “2001: A Space Odyssey” do indeed look like iPads, but you never see the astronauts paying for subscriptions or wasting hours on Candy Crush.
Channel factories are one vision that arose early in the history of the Lightning Network to address some challenges that Lightning has faced from the beginning. Despite having grown to become Bitcoin’s most successful layer-2 scaling solution, with instant and low-fee payments, Lightning’s scale is limited by its reliance on payment channels. Although Lightning shifts most transactions off-chain, each payment channel still requires an on-chain transaction to open and (usually) another to close. As adoption grows, pressure on the blockchain grows with it. The need for a more scalable approach to managing channels is clear. Channel factories were supposed to meet this need, but where are they?
In 2025, subnetworks are emerging that revive the impetus of channel factories with some new details that vastly increase their potential. They are natively interoperable with Lightning and achieve greater scale by allowing a group of participants to open a shared multisig UTXO and create multiple bilateral channels, which reduces the number of on-chain transactions and improves capital efficiency. Achieving greater scale by reducing complexity, Ark and Spark perform the same function as traditional channel factories with new designs and additional capabilities based on shared UTXOs.
Channel Factories 101
Channel factories have been around since the inception of Lightning. A factory is a multiparty contract where multiple users (not just two, as in a Dryja-Poon channel) cooperatively lock funds in a single multisig UTXO. They can open, close and update channels off-chain without updating the blockchain for each operation. Only when participants leave or the factory dissolves is an on-chain transaction needed.
Channel factories offer a number of important advantages. By enabling multiple off-chain channels to be spun up from a single on-chain transaction, they dramatically reduce the load on the base chain. Participants can rebalance funds among themselves efficiently without needing to touch the chain at all: New channels can be created on demand inside the factory, with no cost beyond what was already paid at the factory’s creation. The ability to tweak the ratio of channels to on-chain transactions makes channel factories one of the most capital-efficient scaling approaches available for Lightning today.
Still, it’s no coincidence that channel factories have largely remained on the drawing board despite their promise. A channel factory generally requires all participants to be online and cooperative to update its state, unless special arrangements or protocols are in place to handle asynchrony. For example, Lightning service providers (LSPs) can’t use channel factories to manage downstream channels with their users because all peers need to be known at the time the factory is created. Without a way to incrementally add peers to an existing factory, the model becomes impractical for nodes whose scalability is built into their business model, as is the case with LSPs. Moreover, handling exits from the factory, especially when participants are unresponsive or malicious, involves complex mechanisms that might require participants to pre-sign a large tree of potential exit transactions covering every possible combination of cooperative and uncooperative behavior. Imagine a five-person factory where one peer goes offline or rogue — each of the remaining peers would need pre-negotiated, pre-signed exit paths for every eventuality. Without automation or covenant support, managing this becomes a combinatorial and operational nightmare. These technical and UX constraints make it hard to deliver a seamless user experience or to scale such systems in production.
We’ve seen several proposals to optimize channel factories since 2019, with continuing interest but little production deployment — until now.
A Brief History of Channel Factory Proposals
One early and very comprehensive proposal for channel factories came from Conrad Burchert, Christian Decker and Roger Wattenhofer in their 2017 paper, “Scalable Funding of Bitcoin Micropayment Channel Networks.” Their design allows a group of participants to lock funds in a single multiparty UTXO and open multiple channels off-chain between pairs of participants. Each state transition (channel open, close or rebalance) requires a complete set of presigned transactions. This ensures that every participant has a cryptographically secure way to exit the factory if needed.
However, the Burchert-Decker-Wattenhofer construction has a serious scalability limitation: Any update to the factory state requires every participant to be online and sign off on the change. As the number of participants increases, the number of required signatures and pre-signed exit paths grows exponentially, as do the coordination overhead, the storage burden and the headaches.
Efforts to improve on this model have leveraged newer Bitcoin features. Taproot simplifies the structure of exit transactions by allowing their conditions to be encapsulated in a Merkle tree of scripts, with only the spending path revealed at redemption. This reduces both transaction size and privacy leakage. OP_CHECKTEMPLATEVERIFY (OP_CTV), a proposed soft fork, would dramatically streamline factories by enabling precommitted exit paths without the need for exhaustive presigning. With OP_CTV, a factory could commit to a set of exit transactions at the time of creation. Each participant would know that they can unilaterally exit in a well-defined way, reducing both interactivity and operational complexity.
Despite such progress, practical deployment has lagged. The barriers to full participant interactivity and complex signing schemes, especially in the absence of OP_CTV, are simply too high.
Ark and Spark: Next-Generation Channel Factories
Two recent projects, Ark and Spark, reimagine the channel factory with different trade-offs. While neither project explicitly markets itself as a “channel factory,” their architectures effectively realize many of the goals that early channel factory proposals aimed for. Since both are based on a shared UTXO and both are natively compatible with Lightning, Spark and Ark represent modern incarnations of channel factories that leverage today’s tooling and assumptions. At last! Both aim to preserve the benefits of channel factories (reduced chain usage, scalable liquidity allocation) while resolving key weaknesses around liveness, interactivity and exit complexity. Most importantly, both projects take a pragmatic approach to scaling. They work within Bitcoin’s current consensus rules, avoiding the need for soft forks or new opcodes to be useful today.
UTXO Sharing
Ark introduces a UTXO-sharing model built around the concept of virtual UTXOs (VTXOs). Instead of assigning users individual on-chain outputs, Ark lets them transact off-chain using a shared pool of liquidity managed by an Ark server. Users transact by requesting that a new distribution of VTXOs be included in the next round, when the Ark server creates an “Ark block” aggregating recent user activity and posts a new shared UTXO to the blockchain. So Ark lets users pass VTXOs among themselves and periodically settle the distribution of VTXOs in the shared UTXO via batched anchor transactions on the blockchain.
Users can also perform out-of-round transactions, which instantly move VTXOs between users without waiting for the next round of anchor transactions. In this case, the Ark server co-signs the out-of-round payment, which may be compromised if the Ark server and the sender collude to double-spend the VTXO. However, the receiver can decide whether to accept the risk on the basis of the Ark server’s reputation and take the funds immediately, or to wait until the next round.
Spark takes a different path to shared UTXOs that builds on the concept of statechains. The fulcrum of Spark’s shared signing protocol is the Spark Operators (SOs), who come together in a consortium called a Spark Entity (SE). When a user joins Spark, they deposit funds into a shared-signature address controlled by themselves and the SE. The SE and the user pre-sign a withdrawal transaction, ensuring that the user can always exit unilaterally. A payment occurs whenever a new withdrawal transaction appears, which creates a new current state. Over time, the history of transactions takes on a tree structure, branching off from the original shared UTXO, and each terminal transaction owned by a user is called a “leaf.” Naturally, after each change, the SOs must delete past keys used for the past owner (i.e., pruning old leaves), and only one of the SOs in the SE must do so for the system to work securely. This allows Spark to offer trust-minimized, self-custodial off-chain payments while keeping the base UTXO unchanged.
Like Ark, Spark also introduces some new assumptions about trust. Spark requires at least one SO (or some higher configurable threshold) in the SE to act honestly and delete outdated withdrawal transactions. The result is a “moment-in-time” trust model, in which trust is only required at the time of transfer: The system maintains perfect forward security as long as operators delete their key shares after a transfer. Once the keys are deleted, even a compromised or malicious operator cannot retroactively affect past transactions or steal funds, and a deletion by any SO counts for all the SOs in the SE, distributing responsibility among multiple operators.
Lightning Interoperability
To interop with Lightning, both Spark and Ark rely on swaps facilitated by LSPs. These LSPs must participate in a given Ark or Spark Entity to act as bridges: They execute Lightning payments on behalf of users in exchange for the assets inside the respective systems — VTXOs in Ark and leaves in Spark. The process is secured by atomicity: The LSP only receives the VTXO or leaf once it can prove that the Lightning payment has been successfully completed by providing a preimage. This allows users to make Lightning payments without operating a Lightning node themselves, and it anchors both systems firmly into the broader Lightning ecosystem.
If It Walks Like a Duck…
Channel factories increase scale by leveraging shared UTXOs to amplify Lightning’s scalability. By that measure, Ark and Spark are unequivocally channel factories, albeit sporting the latest fashions in VTXO and statechain technology. Given what shared-UTXO models like these are already achieving, we can expect great things from the channel-factory labs in the near future — especially if new opcodes are added to L1.
Both Ark and Spark are significant achievements in themselves, but they also both validate Lightning. Without being able to interoperate with other subnetworks — Liquid, Fedimint, Cashu, etc. — these revamped channel factories would be far less valuable. And it’s Lightning that lets them interoperate virtually anywhere bitcoin can go. The emergence of Spark and Ark is not a sign of Lightning’s limits but of its indispensability in today’s Bitcoin economy.
Don’t miss your chance to own The Lightning Issue — featuring an exclusive interview with Lightning co-creator Tadge Dryja. It dives deep into Bitcoin’s most powerful scaling layer. Limited run. Only available while supplies last.
This piece is an article featured in the latest Print edition of Bitcoin Magazine, The Lightning Issue. We’re sharing it here to show the ideas explored throughout the full issue.
This post Ark and Spark: The Channel Factories We’ve Been Waiting For first appeared on Bitcoin Magazine and is written by Roy Sheinfeld.
