The Art of Liquidity: What Kind of Bitcoin Off-Chain Scaling Network Do We Need?
TechFlow Selected TechFlow Selected
The Art of Liquidity: What Kind of Bitcoin Off-Chain Scaling Network Do We Need?
This article will explore the evolutionary journey of channel networks and their future development trends from the perspective of liquidity expansion.
Navigating Web3 tides with focused insightsAuthor: Ben, Founder of Discoco Labs
Preface
For a long time, I've been pondering one key question: What is the core logic behind Bitcoin-native scaling?
While deeply researching the Lightning Network and attempting to build non-custodial businesses on top of it, we began to sense certain inconsistencies. Two-party channels theoretically offer the highest transaction throughput, yet their practical maintenance and usage issues are far greater than expected. The Lightning Network has underperformed in its original micro-payment use case, primarily due to liquidity constraints. Even with numerous so-called liquidity-enhancing infrastructures recently introduced, real-world performance still falls short of expectations.
At the time of writing this article, Mutiny Wallet—a well-known self-hosted Lightning wallet—announced its shutdown, followed by the closure of its partnered Liquidity Service Provider (LSP). The collaborative model between self-hosted wallets and LSPs has long been considered a promising path for the Lightning Network's future, making these closures a sobering reminder of lingering uncertainties. At this juncture, this article aims to examine the evolution and future trajectory of channel networks from the perspective of liquidity scalability.
1. What Are the Current Issues with the Lightning Network?
Bitcoin’s block capacity is limited, and the average block time on the mainnet is approximately 10 minutes—far too slow for it to function as a global peer-to-peer cash system. Therefore, we urgently need a scaling solution that minimizes block space usage, enables fast settlement, and remains natively built on Bitcoin. This is how the Lightning Network came into existence.
The Lightning Network defines that once assets are locked on-chain, completing an exchange of commitment transactions off-chain constitutes a finalized transaction—this is why it claims “instant payments.” Compared to Bitcoin’s ~10-minute confirmation times, this significantly improves user experience for small-value payment scenarios.
However, several problems have surfaced during the Lightning Network’s actual development and adoption. This article summarizes four core challenges:
1.1 High Node Maintenance Difficulty
The current Lightning Network relies on a P2P penalty-based game theory model. To monitor whether the counterparty publishes an outdated, unfavorable state on-chain during the channel's lifetime, WatchTowers must remain online at all times—requiring users to operate their own nodes. Additionally, users must locally store penalty private keys and commitment transaction data, resulting in high technical barriers and steep learning curves for node operation.
1.2 High Interactivity Requirements
In the Lightning Network, interactivity refers to the series of interactions required during transactions—such as signing, exchanging commitment transactions, and managing penalty keys. For example, every time a new off-chain state is updated, both parties must be simultaneously online to sign and exchange new commitment transactions. This imposes strict demands on user availability. Moreover, complexity escalates dramatically in multi-hop scenarios involving HTLCs or PTLCs.
1.3 Low Capital Efficiency
The two-party LN-Penalty mechanism essentially requires each user to act like a bank with its own reserve funds. A typical issue is that even to receive payments, users must ensure sufficient inbound liquidity—resulting in very low capital efficiency. Furthermore, liquidity in peripheral channels often remains underutilized.
1.4 High Channel Management Costs
In P2P channels, liquidity imbalance occurs frequently. Users are forced to rely on auxiliary tools such as submarine swaps or channel splicing to rebalance liquidity. However, these techniques require additional on-chain transactions to modify the original FundingTx, making adjustments costly—especially when network fees rise. These costs become increasingly unbearable, creating what feels like a “fee ambush” for users who believed they were using Layer2 for cheap transactions.
All these issues have visibly hindered Lightning Network adoption: user growth remains stagnant, and most new users opt for custodial solutions instead. The following chart clearly illustrates this trend.
Statistics showing the number of new Lightning Network users choosing custodial vs. non-custodial wallet solutions
This trend is understandable—most ordinary users find operating and managing their own nodes and channels simply too difficult.
2. What Kind of Bitcoin Off-Chain Scaling Network Do We Need?
Excerpt from the Lightning Network whitepaper
According to the Lightning Network whitepaper, if every person on Earth opens and closes two channels per year, Bitcoin’s block capacity would need to grow to 133MB. By comparison, today’s Bitcoin mainnet blocks are only 1MB, and even with SegWit-enabled P2TR addresses, they reach just 4MB—a massive gap. Furthermore, since liquidity adjustment techniques (like submarine swaps and channel splicing) require additional on-chain transactions, the Lightning Network’s strain on Bitcoin’s limited block space becomes even more severe in practice.
Clearly, the current Lightning Network cannot meet the needs of large-scale consumer adoption in the near term. And given Bitcoin’s block size limitations, its long-term scalability potential is also significantly constrained.
So the question arises: What kind of Bitcoin off-chain scaling network do we truly need?
2.1 Current State of the Lightning Network
To understand the limitations of the current Lightning Network, we must revisit its design principles.
The existing model, known as LN-Penalty, is essentially a two-party channel model based on penalty transactions. Its security relies on users storing counterbalancing transactions and penalty private keys locally, while continuously monitoring the Bitcoin chain to detect any malicious behavior from their counterparties.
Under this model, running one’s own node is unavoidable—the local storage and WatchTower functionality are indispensable, as emphasized earlier.
From capital and communication efficiency perspectives, the dominant pattern today involves a central LSP (Liquidity Service Provider) super-node offering liquidity, with users establishing channels directly to it. This setup already deviates from the originally envisioned P2P mesh network and naturally converges toward a classic hub-and-spoke topology.
The diagram below illustrates this contrast: the ideal Lightning Network (left) versus the reality today (right).
2.2 Desired Characteristics of a Consumer-Facing Off-Chain Scaling Network
Now let’s envision the ideal characteristics of a consumer-facing Bitcoin off-chain scaling network:
-
Non-P2P model where users don’t need to run their own nodes, while maintaining strong security and usability
-
Asynchronous payments—users should not need to be online simultaneously; offline or asynchronous operations should suffice
-
Improved capital efficiency while preserving non-custodial guarantees
-
Cheap and efficient liquidity management—ideally without requiring users to manage liquidity themselves
With these goals in mind, this article will guide readers through the future directions of Bitcoin off-chain scaling.
3. The Evolution of Native BTC Scaling
First, we must clarify that the core mechanism of the current Lightning Network—"LN-Penalty"—relies fundamentally on two elements:
-
Storage and continuous monitoring of commitment transactions
-
Multihop coordination mechanisms (HTLC/PTLC)
These components form the foundation of the current Lightning Network design, directly contributing to the complexity of node implementation:
-
Complex encrypted communication protocols
-
Local storage of commitment transactions and penalty private keys
-
WatchTowers that must remain operational throughout the channel’s lifetime
These pain points lead us to ask: Can we replace "LN-Penalty" with a lighter-weight state update mechanism? In this context, BIP118 (SIGHASH_ANYPREVOUT) emerges as a promising alternative.
3.1 LN-Symmetry: Introducing Versioned State Updates
BIP118 proposes the SIGHASH_ANYPREVOUT signature scheme, which allows transaction inputs to not fully specify the previous output and permits updating prior transactions without invalidating signatures. Compared to "LN-Penalty," this design significantly reduces cryptographic communication complexity and storage requirements between nodes. SIGHASH_ANYPREVOUT originates from the paper eltoo: A Simple Layer2 Protocol for Bitcoin. In recent Lightning development discussions, the improved Lightning model based on this concept is referred to as "LN-Symmetry."
While LN-Symmetry reduces the burden of storing local commitment transactions, it does not eliminate the need for monitoring. Although Eltoo eliminates the need to exchange commitment transactions and penalty keys, if a participant attempts to publish an old state on-chain, the other party must still detect it in real time and broadcast the latest state to overwrite it. This monitoring task still requires a traditional WatchTower—though now its purpose shifts from punishment to state replacement. Users still need to maintain their own nodes.
Additionally, LN-Symmetry still relies on HTLC/PTLC-like mechanisms for multi-party coordination, retaining the same heavy communication overhead as the original Lightning Network.
Thus, overall, LN-Symmetry offers only marginal improvements over the current Lightning experience—still far from our ultimate goals.
To push further, this article introduces the next evolutionary step: Shared UTXO.
3.2 CoinPool: Reducing Interactivity and Liquidity Demands in Multi-Party Channels
The first paper introducing the Shared UTXO concept is CoinPool: efficient off-chain payment pools for Bitcoin. Its primary goal is to further address multi-party interactivity issues under the SIGHASH_ANYPREVOUT versioning mechanism.
While Eltoo’s new state update mechanism simplifies point-to-point channel state management in LN-Symmetry, interactivity complexity persists in multi-party settings—especially in multihop payments (HTLC/PTLC), which require tight coordination and repeated encrypted communications.
CoinPool’s innovation lies in using the Shared UTXO model, allowing multiple parties to collaborate on a single version-controlled UTXO. This way, participants can jointly commit to and manage the state of a UTXO without relying on complex HTLC/PTLC mechanisms. Key advantages include:
-
Dramatically reduced interactivity in multi-party channels: Since all participants share the same UTXO, consensus can be reached simply by signing updates to its version—eliminating the need for multiple on-chain transactions or complex off-chain interactions. This makes multi-party channel management much more efficient.
-
Simplified off-chain updates: State updates become a matter of co-signing a new version of the UTXO. This streamlines the update process and reduces dependencies and conflict points among participants.
-
Elimination of individual liquidity requirements: With the Shared UTXO model, participants effectively pool their liquidity. No longer does each participant need to independently maintain sufficient liquidity. In CoinPool’s multi-party design, liquidity needs can be drastically reduced or redistributed. Participants can leverage shared liquidity within the UTXO to make payments without locking large amounts of capital individually—improving capital efficiency and reducing financial pressure.
CoinPool successfully reduces interactivity complexity in multi-party channels to manageable levels while preserving system security and efficiency. More importantly, it lessens reliance on individual liquidity, offering a lighter, more flexible solution for multi-party collaboration—breaking free from the traditional LN model’s limitations in interactivity and liquidity management.
Yet, despite these clear advantages, why hasn’t CoinPool been widely adopted? Where lies the root problem?
3.3 Why Hasn’t CoinPool Been Implemented?
Although CoinPool offers many benefits and is viewed as an ideal scaling model, its required soft fork upgrades are so extensive that we may never see it deployed on Bitcoin within our lifetimes. CoinPool’s soft fork requirements center on two areas:
3.3.1 State Update Mechanism Upgrade
Since CoinPool builds upon Eltoo, it inherits Eltoo’s need for a soft fork to enable a new signature mode: SIGHASH_ANYPREVOUT (APO). As is well known, Bitcoin soft forks progress slowly, making it unlikely that APO will be activated anytime soon—rendering CoinPool’s state update mechanism impractical today.
3.3.2 Shared UTXO Requires Simplified Contract Operations
As previously noted, every Shared UTXO state update requires collecting signatures from all parties sharing that UTXO version. If any participant goes offline, the entire system stalls—what blockchain researchers call poor liveness.
To overcome this, the system needs a low-cost mechanism to update the Shared UTXO without full cooperation.
The CoinPool paper proposes OP_MERKLESUB, using Merkle trees to verify and update specific participant states. While theoretically feasible, this approach shares the same drawbacks as other Merkle-tree-based contracts: complex logic and difficulty in building通用, reusable contracts—similar to proposals like **OP_TAPLEAFUPDATEVERIFY (TLUV)**. Meanwhile, functions like OP_EVICT—which directly evicts uncooperative parties—are too narrow in scope to gain consensus for Bitcoin upgrades.
Among these contract proposals, OP_CheckTemplateVerify (CTV) has gained increasing attention. Unlike building and verifying Merkle trees, CTV restricts spending via predefined transaction templates. CTV is simple to implement and enables committing a chain of off-chain UTXOs to a single on-chain UTXO through a commitment chain. These off-chain UTXOs, committed on-chain, represent the origin of the Virtual UTXO (VTXO) concept.
Of all proposed opcodes, CTV has seen the strongest advocacy due to its simplicity and versatility. Its capabilities extend beyond CoinPool-like designs and can even support Rollup architectures. Imagine performing ZKP-MerkleState verification via OP_CAT and directly committing Layer2 states in scripts via Shared UTXOs—we could then build true Bitcoin ZK-Rollup solutions.
In summary, CoinPool’s implementation hinges on lightweight state updates (APO) and Shared UTXO opcode support—both requiring Bitcoin soft forks. Despite being proposed years ago, CoinPool remains a theoretical construct.
3.4 Bitcoin Clique: The 2-AS Anti-Double-Spend Primitive
In the discussion above, we saw that CoinPool’s reliance on APO necessitates a soft fork—unlikely in the short term. But what if there existed a new off-chain double-spend prevention primitive that didn’t require a Bitcoin soft fork? That would largely solve the implementation bottleneck.
The core function of SIGHASH_ANYPREVOUT is to provide an off-chain state update mechanism resistant to double-spending. Following this idea, finding an equivalent cryptographic primitive could resolve off-chain state updates without needing changes to Bitcoin’s scripting language. The emergence of the Bitcoin Clique paper brings new hope. It introduces a novel cryptographic primitive: 2-shot-adaptor-signature (2-AS), offering a fresh solution to off-chain double-spend prevention.
2-AS is based on Schnorr adaptor signatures. To understand 2-AS, we first need basic knowledge of Schnorr signatures and adaptor signatures.
3.4.1 Schnorr Signatures
Schnorr signatures have linearity: multiple signatures can be aggregated into one. For instance, if two signatures $S_1$ and $S_2$ exist, they can be added to form $S = S_1 + S_2$, and the corresponding public keys can likewise be summed as $P = P_1 + P_2$ for verification.
3.4.2 Adaptor Signatures
Adaptor signatures involve several steps: Gen, PSign, PVrfy, Adapt, Extract. For understanding 2-AS, PSign and Extract are particularly important.
This article focuses on practical usage rather than deep cryptography. In short, when two parties wish to collaboratively confirm a signature, one party uses an adaptor (often a public key) as part of the signature. The holder of the corresponding secret (private key) can then "adapt" the partial signature into a complete one. At this stage, it may seem similar to MuSig. But the unique power of adaptor signatures lies in Extract: after a full signature is revealed, the original signer can extract the secret (private key) using the complete signature, the partial signature, and the adaptor (public key).
3.4.3 Combining Both: 2-AS
Having understood Schnorr and adaptor signatures, we can now explore the magic of their combination: 2-AS.
Suppose we have a VTXO and want to ensure it can be penalized if double-spent off-chain. We can design it as follows:
-
Create a penalty output unlockable via a penalty public key, ensuring service providers can confiscate funds if a user double-spends.
-
Counterparties cooperate using adaptor signatures to confirm off-chain transactions. If a user uses the same input twice, the service provider can seize the output.
-
Require users to generate a public key for each state update as part of the penalty output. This penalty pubkey is formed by adding two predetermined pubkey pairs via Schnorr aggregation.
By pre-agreeing on key pairs and generating penalty outputs ahead of time, if a double-spend occurs, the service provider can derive the penalty private key from the two adaptor signatures.
3.4.4 Pros and Cons of Bitcoin Clique
The Bitcoin Clique scheme is not flawless. Its main drawback is that during off-chain state updates, parties must continuously exchange 2-AS keys used to construct new penalty pubkeys. Because the scheme builds on CoinPool and requires exchanging 2-AS keys and validating new UTXO versions, it still demands all participants be online during state updates. Thus, communication complexity and interactivity remain high.
More critically, this model resembles StateChain: each off-chain transfer moves ownership of a UTXO. Systems using double-spend-prevention signatures like 2-AS cannot support change in off-chain payments—severely limiting application scope.
Moreover, even with a convenient Shared UTXO mechanism and a no-soft-fork double-spend prevention primitive, we still require everyone to be online to update UTXO states—even when only a subset is affected. Requiring unrelated parties to participate online in on-chain updates is unreasonable. Also, completely eliminating liquidity needs isn't desirable—payment systems without liquidity buffers can’t provide change, and exit mechanisms force all users to hold identical denominations.
Therefore, currently, no non-channel, dynamic-denomination, UTXO-based off-chain scaling solution exists. Ethereum也曾 struggled down this path—known as the Plasma trap. See the paper *Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma* for details.
Key lessons learned:
-
Liquidity is needed to enable dynamic payments (change): Retain channel design to avoid exit issues.
-
Reduce dependence on all participants being online: Users shouldn’t need to be online for every state update. Shared UTXO updates should only require relevant parties to collaborate.
Building on these insights, we continue exploring better solutions.
3.5 Channel Factories and Virtual Channels
From earlier discussions, we recognize the need to retain channel design while leveraging Shared UTXO’s off-chain cost benefits. One long-discussed concept in the Lightning community now comes into focus: Channel Factories.
Earlier, we mentioned that off-chain UTXOs committed by an on-chain UTXO are called Virtual UTXOs (VTXOs). If we use a VTXO as the FundingTx for a channel, we get a new concept: Virtual Channels. Within a Shared UTXO, these virtual channels are connected via Virtual HTLCs. Everything moves off-chain—fully “virtualized.” This seems like an ideal solution: perform most functions—including liquidity adjustments—off-chain, seemingly solving Lightning Network scalability.
But is it really that perfect?
Due to inheriting Shared UTXO properties, Channel Factories require coordinated actions from multiple users to open and close. If any user fails to respond (e.g., goes offline), the entire factory may stall. Since all parties must co-sign state updates, any delay or malicious behavior by one party could prevent others from closing channels and withdrawing funds.
Moreover, this design retains the classic LN-Penalty security model reliant on commitment transactions and HTLCs. Thus, communication and interactivity issues persist—and implementation complexity may even exceed that of current LN-Penalty.
3.6 ARK JoinPool and Ephemeral Channels
From the Channel Factory example, we conclude: in Shared UTXO-based channel designs, we should abandon the classic "LN-Penalty" model—but still preserve the advantages of channels:
-
Dynamic denominations enabled by liquidity;
-
Easy exits.
Based on this, a new design using JoinPool for ephemeral channels has emerged: ARK Protocol.
3.6.1 JoinPool: Only Relevant Parties Participate in Updates
As discussed, CoinPool shows great potential for multi-party off-chain scaling—eliminating the need for liquidity, multihops, and fragile HTLC designs. However, CoinPool’s biggest flaw is its online requirement: all users in a Shared UTXO must be online for state updates—even those whose states haven’t changed. This forces users to run nodes continuously.
To solve this, a new model called JoinPool was proposed. The idea: whenever a user wants to update their off-chain state, only they and the service provider join a new Shared UTXO representing the updated state. This eliminates the need for unrelated users to be online during others’ transactions. In JoinPool, users only need to be online when actively transacting.
But we know that running Lightning nodes isn’t just about having private keys online for signing—it’s also about WatchTowers monitoring whether counterparties publish old states. This leads to our second challenge.
3.6.2 WatchTower Responsibility Shift: Users No Longer Need to Run Nodes
In classic LN-Penalty, each user runs their own WatchTower to detect and punish publication of old states. In that model, every user is a peer Lightning node, potentially opening channels with different nodes each time. But in ARK, all users interact solely with an ASP (ARK Service Provider), not directly with each other.
For the ASP, whenever a user trades a VTXO off-chain, they sign a waiver transaction. Ideally, a VTXO should never hit the chain but keep being referenced in subsequent trades. If a VTXO is traded off-chain but later appears on-chain, it indicates a double-spend attempt—triggering the ASP to use the user’s previously signed waiver to confiscate the on-chain funds. The ASP monitors all historical VTXOs to prevent malicious withdrawals from already spent off-chain coins.
This shifts WatchTower responsibility from end users to the operator—an enormous improvement over the Lightning Network: users no longer need to run their own nodes for security.
Summary of other approaches to reduce node operation burdens:
-
Cloud-hosted Lightning nodes
Some solutions host Lightning nodes on cloud platforms to lower entry barriers. However, this fundamentally violates the Lightning Network’s security assumptions. In Lightning, local storage of private keys and commitment transactions is crucial. Remote storage cannot guarantee safety.
Essentially, this turns a two-party game into a three-party one: user, counterparty, and cloud provider. After a transaction but before state finalization, the cloud provider could delete the commitment transaction from the user’s node—allowing the counterparty to publish a favorable old state. This creates collusion risks between the cloud provider and the counterparty.
-
CRAB and Sleepy CRAB
Aumayr et al.’s CRAB (Channel Resistant Against Bribery) protocol uses extra collateral and miner incentives to secure payment channels, especially during user downtime. This reduces reliance on third-party WatchTowers. However, the collateral mechanism worsens the “inbound liquidity” problem—requiring users to lock up more irrelevant funds upfront. While enhancing security, it sacrifices capital efficiency. Also, users still need to run nodes—just with relaxed uptime requirements.
3.6.3 Ephemeral Channels: No User-Managed Liquidity
One might ask: Why would an ASP willingly inject liquidity into JoinPool channels? Because to use a VTXO on the ARK network, users must first deposit their UTXO with the operator into a multisig address—functioning like a FundingTx—in exchange for a VTXO. Effectively, each off-chain transaction uses the operator’s capital, while the user surrenders their prior multisig-held funds.
ARK channels are called “ephemeral” due to two features:
-
Unidirectional: Funds flow only from a designated sender to recipient.
-
Single funding: ARK channels require only one-time capital injection. After funding, no further liquidity management is needed.
With this design, no rebalancing or adjustments are required post-funding. Unlike Lightning, neither users nor liquidity providers need to manage channel liquidity. The only event altering the channel is user withdrawal.
3.6.4 Summary of ARK Protocol
In summary, ARK Protocol represents a dramatic leap forward in user experience compared to the Lightning Network:
-
Users don’t need to run their own nodes
-
No need to manage channel liquidity—no inbound liquidity issues
-
Supports asynchronous interaction—no need for both parties to be online simultaneously
4. A Paradigm Shift in Bitcoin Native Scaling
Through our exploration, we’ve examined multiple off-chain scaling schemes based on Shared UTXO. Initially designed to solve liquidity issues, Shared UTXO unexpectedly unlocks advantages we once dreamed of but thought unattainable.
This marks a new direction in Bitcoin off-chain scaling—a paradigm shift from the original Lightning model:
-
From P2P to引入 trustless operators
The logic of off-chain scaling evolves from Lightning’s original “user-to-user” bilateral model to a “user-to-operator” framework. Crucially, users don’t need to trust the operator.
-
Users no longer need to run nodes to secure assets
Traditional LN-Penalty and newer models like CRAB require users to provide collateral and stay online with nodes. Future designs eliminate these burdens while remaining non-custodial—users retain full control of their assets.
-
Liquidity management shifts from users to operators
In classic and improved LN models, users must manually rebalance liquidity—complex and expertise-intensive, especially without LSPs. Shifting this duty to third-party operators removes a major barrier to entry and greatly simplifies user experience.
-
Massive gains in capital efficiency and potential
New protocols move toward a P2POOL model, fundamentally differing from Lightning in capital efficiency. In LN-Penalty, each user must supply liquidity when opening a channel—yet most sits idle (payments are infrequent and unevenly distributed), leading to inefficient capital use. In contrast, new designs centralize liquidity into shared pools, unlocking vast possibilities for future DeFi applications.
This paradigm shift reveals that liquidity management is the essence—and the core evolutionary thread—of Bitcoin-native off-chain scaling.
Going forward, as technology advances and new solutions emerge, Bitcoin’s off-chain scaling journey will undoubtedly brighten. We will continue deep research in this domain—stay tuned for further developments.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@blapta
