Increasing Interoperability Between Bitcoin’s Second-Layer Protocols

The prevailing wisdom is that, in order to achieve hyperbitcoinization, Bitcoin should scale in layers. The current discussion or debate is mainly centered around which layer-2 solution is best suited for this. Growing evidence suggests, however, there is no ‘one size fits all’ approach but rather many complementary protocols, each addressing different problems and catering to specific use cases and markets.

In this edition of Layer-2 Report, we look at some of these second-layer protocols in detail. Among other things, we will explore their interoperability (or lack thereof) and the projects using these solutions to promote mass adoption. We will also look at some of the various growing pains experienced so far, as seen recently as a result of May’s high-fee market environment.

Choosing the Right Tool for the Job

Each second layer addresses a unique set of limitations inherent in the mainchain, such as the lack of high transaction throughput, privacy, or the ability to issue assets. For example, if you want to send a friend a small amount of sats and value affordability and speed, Lightning is likely the best option. Whereas if you are a financial institution wanting to issue an asset like a bond or digital security, it makes more sense to use Liquid.

There are also varying tradeoffs when using each solution that may affect a user’s decision to opt in, like Lightning’s liquidity constraints or the trust requirements (albeit distributed) seen with federated models, such as Liquid and Fedimint. As creator Burak has openly shared, even the newest addition to the layer-2 landscape, Ark, has tradeoffs with the mainchain and other L2s.

Like the old analogy of 'choosing the right tool for the job,' in a hyperbitcoinized world, users can expect to have a toolkit of L2s at their disposal, with different capabilities and tradeoffs.

Increasing Interoperability

Often overlooked is the importance of interoperability between not only the second-layer protocol and Bitcoin but the layer-2 protocols themselves. A second layer, where end-users can leverage several protocols together and move seamlessly between them, creates a healthier, more resilient financial system and an overall better user experience—both essential for mass adoption. For example, by running Lightning on top of Liquid, users gain greater privacy, additional liquidity, and cheaper fees (and much more, as we will explore later).

While both Liquid and Lightning networks operate independently, they are complementary and interoperable, offering a secure, alternative method to stacking sats or a more cost-effective option to Lightning channel rebalancing, especially when fees are high on the mainchain.

Elements, the open-source codebase that Liquid is built on, is designed to be as close to parity with Bitcoin Core as possible. This not only offers some nice security guarantees (since any bug fix or performance improvement upstream in Bitcoin can be merged into Elements) but also greater interoperability with other L2s, given that its design functions very similarly to Bitcoin.

Connecting the Second Layer with Lightning

The basis of Lightning is its network of payment channels, which are fundamentally made possible through Bitcoin's Unspent Transaction Outputs (UTXOs) in conjunction with Lightning's Hashed Timelock Contracts (HTLCs). The UTXO model allows certain script conditions, and hash puzzles and time constraints to be encoded in the transaction for payment to be securely routed across Lightning.

One of the many design features that Liquid inherits from Bitcoin is its UTXO model. This compatibility allows Lightning's HTLCs to function with Liquid Bitcoin (L-BTC) in a manner similar to how they function with Bitcoin, enabling the payment network to operate on top of Liquid. Note that this Lightning Network on Liquid would run as a separate network but with all the advantages of Liquid as its underlying chain (e.g., Confidential Transactions and deterministic blocks). You could even bridge the two networks if you ran both—one on top of Bitcoin, the other on Liquid—for greater cross-platform compatibility. The payments remain end-to-end secure since both use the HTLC construction. The bridge, however, gets to dictate a dynamic exchange rate if the two assets being transferred are different, which is not an issue when transferring BTC and L-BTC since they are pegged.

Lightning's inherent decentralization, wide adoption, and compatibility with UTXO-based technologies could position it as the connective tissue between each L2. It could act as a primary hub for new protocols seeking to bridge to existing ones, helping to avoid the chicken-and-egg problem of adoption that has plagued new protocols in the past.

This thesis has begun to play out more recently, with several big-name exchanges adding Lightning and swap platforms incorporating Liquid with Lightning to leverage the benefits of both protocols.

Unfairly Cheap with Lightning and Liquid

In early May, on-chain Bitcoin transaction costs surged due to network congestion, resulting in the highest fees seen in nearly two years. This affected major exchanges like Binance and Coinbase, and even some Lightning-compatible wallets like Muun, pricing some users out of the market entirely. This week-long episode underscored the importance of hardening scalability solutions like Lightning, which have so far relied on mainchain transactions to keep liquidity balanced. The event also raised awareness of the powerful benefits of using layer-2 technologies together, especially when fees on Bitcoin's mainchain are not only high but also volatile.

One of the new products in-market driven by this episode is the use of Liquid submarine swaps by Boltz to offer cheap Lightning channel liquidity to its users. As opening a Lightning channel requires an on-chain transaction and many users rely on the mainchain to add liquidity to their Lightning node, costs can quickly add up in high-fee conditions. By using the Liquid sidechain instead of the Bitcoin mainchain as the underlying liquidity source, users can rebalance their Lightning channels independently from the congested mainchain mempool—and do so without losing self-custody of their funds, thanks to the atomic nature of the swap.

In a high-fee scenario, users can expect upwards of 99% savings using the Liquid swap feature. Boltz intends to expand the scope of their Liquid integration by building an L-BTC <> BTC chain-to-chain atomic swap for trustless peg-outs—the first of its kind.

You can read more about Boltz's decision to add Liquid and why in their write-up here.

Another option for users is the self-hosted rebalancing protocol PeerSwap, which allows Lightning node operators to rebalance their channels with peers directly using BTC and L-BTC atomic swaps. This setup eliminates the need for a third-party coordinator for even greater savings and allows smaller nodes to better compete with larger ones. PeerSwap is currently available for both CLN and LND implementations.

The story does not end there, though. In addition to provisioning Lightning liquidity with Liquid, users turned to Lightning <> Liquid swaps to stack sats (and humbly, I might add). Many used a cheap starting point like Strike, Cash App, or some other fiat on-ramp to buy Lightning Bitcoin (LN-BTC) directly and then moved to one of the growing number of Lightning to Liquid swap services like Boltz, SideShift, or Classic CoinOs to convert to L-BTC to HODL for the mid-term. So, why would anyone HODL in L-BTC rather than LN-BTC? Unlike with Lightning, Liquid assets can be self-custodied offline in cold storage, like on a hardware device such as Jade. This setup is better for HODLing over a longer time frame—another difference to consider when deciding what layer-2 solution is best for you and your specific use case.

The Emergence of the Bitcoin Superapp

Some builders are already working on improving the Bitcoin layer-2 user experience by directly integrating swaps and multi-protocol support into their app offerings.

For example, the Blockstream Green team is in the final stages of adding Lightning capability via Greenlight, giving Bitcoiners the ability to self-custody mainchain, Liquid, and Lightning all in one app. Green, SideSwap, and the soon-to-be rereleased version of the AQUA wallet also plan to incorporate in-app Lightning <> Liquid swaps using the Boltz API.

Wallby, a newly anointed Bitcoin superapp supports the custody of mainchain, Liquid, and Rootstock, with further plans to add Lightning and RGB. The Wallby team is also placing emphasis on features. For instance, users can already add bitcoin and other digital assets to liquidity pools and earn interest through an automated market maker (AMM), with the ability to lend and borrow peer-to-peer and perform cross-chain swaps also on the way.

The emergence of these Bitcoin superapps and new features like in-app swaps prioritizes improving user experience, something the Bitcoin space is notoriously bad at (to the point it has become a running meme). This pivot and Lightning's maturation as a sort of lingua franca of Bitcoin will be a crucial part of the strategy for increasing layer-2 interoperability and facilitating mass adoption. Each protocol will have a unique place in the hyperbitcoinization story, ending in a second layer that is stronger than each individual protocol on its own.