Lightning, Spark, and Ark: Can Bitcoin's Layer 2s Interoperate or Are They Islands?

Bitcoin now has multiple Layer 2 protocols in production: Lightning for payment channels, Spark for statechains, Ark for virtual UTXOs, and Liquid for federated sidechains. Each solves Bitcoin's scalability constraints differently. But here is the question nobody building on a single L2 can avoid: can a Lightning user pay a Spark user without either party thinking about which protocol they are on?

The answer is more nuanced than a simple yes or no. Interoperability between Bitcoin L2s already exists in certain forms, but the mechanisms, trust assumptions, and user experience vary significantly across protocol pairs. This article maps the current landscape of Bitcoin L2 interoperability, examines the technical primitives that make cross-layer payments possible, and assesses where each protocol pair stands today.

The Bitcoin L2 Landscape: Three Architectures

Before analyzing interoperability, it helps to understand why these protocols diverge so fundamentally. Each makes different tradeoffs between trust, capital efficiency, and operational complexity.

Lightning: Payment Channels

The Lightning Network uses bidirectional payment channels between two parties, connected into a routable network via HTLCs (Hash Time-Locked Contracts). As of September 2026, the network holds approximately 4,900 BTC in public channel capacity across roughly 41,000 channels and 17,000 nodes. When private channels are included, total capacity likely exceeds 12,000 BTC.

Lightning's strength is its fully trustless model: no third party can steal funds or prevent unilateral channel closure. Its weakness is operational complexity. Channel liquidity management, inbound capacity acquisition, and the requirement that recipients be online to receive payments create friction, particularly for mobile users and casual senders.

Spark: Statechains with FROST Signing

Spark launched on mainnet on April 29, 2025. It uses a statechain model enhanced with FROST threshold signatures and a leaf architecture that supports partial transfers. Users hold one key of a 2-of-2 multisig; Spark Operators collectively hold the other via distributed FROST signing. Transfers happen by rotating the operator key share while destroying the old one: the on-chain UTXO never moves.

The trust model is 1-of-n: as long as one operator behaves honestly, user funds remain secure. Currently Lightspark and Flashnet serve as operators. Spark requires no channels, no liquidity planning, and supports offline receiving: a significant UX improvement over Lightning for end users.

Ark: Virtual UTXOs and Rounds

Ark pools multiple users into shared on-chain UTXOs and issues virtual UTXOs (vTXOs) that can be transferred off-chain. An Ark Service Provider (ASP) coordinates periodic rounds, typically every 15 to 60 minutes, that batch transfers into a single on-chain transaction. Each round creates a covenant tree containing all new vTXOs.

Bark, built by Second, launched on Bitcoin mainnet on June 9, 2026, becoming the first production-grade Ark implementation. Arkade (by Ark Labs) reached public beta in October 2025 after processing its first mainnet payments at Baltic Honeybadger in August 2025. Ark Labs raised a $5.2 million seed round backed by Tether in March 2026.

Key distinction: Lightning requires pre-funded channels between specific pairs. Spark rotates key shares on existing UTXOs. Ark batches transfers into periodic rounds with shared UTXOs. These architectural differences determine what interoperability mechanisms are possible between each pair.

What Interoperability Actually Means

In the Ethereum ecosystem, interoperability typically means arbitrary smart contract composability across chains: calling a function on Arbitrum that triggers state changes on Optimism. Bitcoin L2 interoperability is fundamentally different. Because Bitcoin L2s are payment-focused rather than general-purpose computation platforms, interoperability means one thing: can a user on protocol A pay a user on protocol B without manual intermediate steps?

This can be decomposed into three levels:

1. Manual bridging: the user explicitly converts between layers using a swap service, bearing the cognitive and fee overhead themselves
2. Service-mediated: an intermediary (LSP, SSP, or ASP) handles the cross-layer conversion automatically, but the user must select the right payment method
3. Transparent: the user sends a payment and the infrastructure routes it across layers without the user knowing or caring which L2 the recipient uses

Most Bitcoin L2 interoperability today operates at level two. The infrastructure for level three exists in narrow cases but is not yet universal.

The Technical Bridge: Submarine Swaps

Submarine swaps are the oldest and most battle-tested mechanism for moving value between Bitcoin's base layer and Lightning. They use HTLCs to create an atomic swap where either both legs complete or neither does. In a forward submarine swap, a user locks BTC on-chain and receives an equivalent Lightning payment. In a reverse swap, the user sends a Lightning payment and receives on-chain BTC.

How the Mechanics Work

The process relies on the same hash preimage being used in both the on-chain HTLC and the Lightning payment. A user provides a Lightning invoice to the swap provider. The provider extracts the payment hash, generates a P2WSH address on-chain locked to that hash, and waits for the user to fund it. Once funded, the provider pays the Lightning invoice. The recipient reveals the preimage by claiming the payment, which the provider uses to unlock the on-chain funds.

Atomicity is guaranteed by the hash lock: the preimage that unlocks the Lightning payment is the same preimage that unlocks the on-chain HTLC. If either party abandons the swap, timelocks return funds to their original owners.

Submarine Swap Providers

The submarine swap landscape shifted significantly in 2026. Boltz, the largest implementation-agnostic swap provider, suspended all swap services on August 3, 2026, citing automated AI-assisted probing attacks that outpaced their patching capacity. While Boltz's non-custodial design meant no user funds were at risk, the shutdown affected downstream wallets including ZEUS, Aqua, and Bull Bitcoin.

One week later, on August 10, 2026, Blockstream announced Blockstream Swaps, connecting Bitcoin mainchain, Lightning, and Liquid via HTLC-based atomic swaps. Lightning Labs continues to operate Loop for LND node operators, which received a MuSig2 upgrade in February 2025 enabling static, reusable deposit addresses using 2-of-2 taproot constructs.

Cross-L2 Atomic Swaps: HTLCs as the Universal Glue

The same HTLC primitive that powers submarine swaps also enables cross-layer atomic swaps between Bitcoin L2 protocols. The pattern is consistent: if two protocols can both lock funds contingent on a hash preimage, they can swap atomically.

Spark to Lightning

Spark's interoperability with Lightning is the most mature cross-L2 bridge in the Bitcoin ecosystem. Spark Service Providers (SSPs) act as intermediaries that hold balances on both Spark and Lightning. When a Spark user wants to pay a Lightning invoice, the SSP executes an atomic swap: the user transfers Spark balance to the SSP, and the SSP simultaneously pays the Lightning invoice. Both legs are locked to the same hash preimage, so either both complete or neither does.

This works in both directions. A Lightning sender can pay a Spark recipient through an SSP that converts the incoming Lightning payment into a Spark transfer. Crucially, Spark supports offline receiving: the SSP holds the incoming payment conditionally until the recipient comes online, a capability Lightning alone cannot provide.

The result is that from the sender's perspective, paying a Spark user feels identical to paying any Lightning recipient. The cross-layer swap is invisible. This approaches level-three interoperability for the Spark-Lightning pair.

Ark to Lightning

Ark's interoperability with Lightning follows a similar pattern but with added constraints. Users can attach HTLCs to pool transactions, enabling the ASP to act as a Lightning gateway. The ASP handles channel management and routing on behalf of Ark users, similar to how an LSP serves Lightning mobile wallets.

However, Ark's round-based architecture introduces latency. Because transfers settle in periodic rounds (every 15 to 60 minutes for on-chain settlement), a cross-layer payment from Ark to Lightning may need to wait for the next round to finalize the Ark-side leg. This creates an asymmetry: Lightning-to-Ark payments can settle quickly (the ASP fronts liquidity), but Ark-to-Lightning payments may be delayed by the round interval.

Fulmine, a Bitcoin wallet daemon integrating Ark with Lightning infrastructure, is designed for routing nodes and payment hubs that need both protocols.

Spark to Ark

Direct Spark-to-Ark swaps are theoretically possible using HTLCs as the common denominator. An intermediary holding balances on both protocols could atomically swap between them. In practice, no production service offers this today. The more likely path is indirect routing through Lightning as a hub: Spark → Lightning → Ark. Since both protocols already interoperate with Lightning, Lightning functions as a de facto interconnection layer.

Lightning as the interchange network: Because Lightning is the most widely adopted L2 and both Spark and Ark already bridge to it, Lightning naturally becomes the routing backbone connecting all Bitcoin L2s. Any new L2 that implements Lightning interoperability automatically gains connectivity to every other L2 that has done the same.

Feasibility Assessment: L2 Pair Interoperability

The following table assesses the current state of interoperability for each Bitcoin L2 pair across trust model, latency, and production readiness.

HTLCs vs PTLCs: The Privacy Dimension

All current cross-L2 swap mechanisms on Bitcoin rely on HTLCs. While functional, HTLCs have a significant privacy weakness: the same payment hash is visible at every hop along the route. An observer who controls multiple nodes can correlate payments by matching hashes, defeating the onion routing privacy that Lightning otherwise provides.

PTLCs (Point Time-Lock Contracts) solve this by replacing hash preimages with adaptor signatures. Each hop uses a different cryptographic point, breaking the correlation vector entirely. PTLCs also consume less block space and prevent routing interception attacks.

The cryptographic foundation for PTLCs has been available since Taproot's activation in November 2021, which brought Schnorr signature support to Bitcoin. However, as of September 2026, no major Lightning implementation has shipped PTLC support in production. The migration from HTLCs to PTLCs requires coordinated changes across implementations and remains an active area of development.

When PTLCs eventually ship across Lightning implementations, they will improve privacy for cross-L2 swaps as well. An SSP performing a Spark-to-Lightning swap with PTLCs would leave no correlatable on-chain or in-network fingerprint linking the two legs of the transaction.

Lessons from Ethereum's L2 Fragmentation

Ethereum's experience with Layer 2 scaling offers both warnings and insights for Bitcoin. As of 2026, L2Beat tracks over 120 scaling projects securing approximately $41 billion in value. But the top three rollups (Base, Arbitrum, and Optimism) process roughly 90% of all L2 transactions, while smaller L2s have seen usage decline by 61% since mid-2025.

Liquidity fragmentation is the core problem. Average liquidity depth dropped 40% across Ethereum L2 networks as capital spread across dozens of chains. Users need different tokens on different networks, bridges introduce trust assumptions, and the mental overhead of managing assets across multiple rollups creates friction that undermines the scaling gains.

Ethereum's Interoperability Approaches

The Ethereum ecosystem has developed several interoperability strategies:

• Intent-based bridges (ERC-7683): users declare a desired outcome and competitive solvers execute it across chains. Co-authored by Uniswap Labs and Across Protocol, with the Ethereum Foundation launching the Open Intents Framework in February 2025
• Shared sequencers: projects like Espresso and Astria provide shared ordering infrastructure. The Optimism Superchain runs 30+ chains on the OP Stack with planned native interoperability
• ZK bridges: trust-minimized bridges using validity proofs to cryptographically verify state changes across chains

What Bitcoin Can Learn

Bitcoin's L2 landscape differs from Ethereum's in ways that reduce fragmentation risk. Bitcoin has fewer L2 protocols (Lightning, Spark, Ark, Liquid versus Ethereum's 120+), and they are payment-focused rather than general-purpose computation platforms. This narrower scope means interoperability requires only value transfer, not arbitrary cross-chain contract calls.

The critical lesson from Ethereum is that fragmentation compounds quickly. Every new L2 that cannot interoperate with existing ones splits the user base and dilutes network effects. Bitcoin's advantage is that HTLC-based atomic swaps provide a universal interoperability primitive that works across any protocol supporting hash locks. As long as new Bitcoin L2s implement Lightning gateway functionality, they inherit connectivity to the entire existing network.

Does the User Need to Know Which L2 They Are On?

The ultimate measure of interoperability is whether it is invisible. Today, most Bitcoin L2 interactions still require users to understand what layer their funds sit on. A Lightning user knows they are managing channels. An Ark user knows their vTXOs expire. The layer is not abstracted away.

Spark comes closest to layer abstraction for end users. Because SSPs handle Lightning interoperability automatically, a user holding Spark balance can pay any Lightning invoice without thinking about the underlying swap mechanics. Wallets like Wallet of Satoshi and Breez have integrated Spark in ways that make the L2 distinction largely invisible to end users.

The Ethereum ecosystem has a term for this: chain abstraction. The goal is that users interact with applications without knowing or caring which chain their transaction settles on. For Bitcoin L2s, the equivalent would be a wallet that automatically selects the optimal layer for each payment based on amount, speed, cost, and recipient capabilities. This is technically feasible today for the Spark-Lightning pair and conceptually possible for a broader multi-layer wallet architecture.

Protocol Developments Enabling Interoperability

Several recent protocol upgrades improve the foundation for cross-L2 interoperability:

BOLT12 Offers

BOLT12 was merged into the Lightning specification in September 2024. Unlike BOLT11 invoices, offers are reusable, support blinded paths for receiver privacy, and enable recurring payments. As of 2026, CLN ships BOLT12 enabled by default, LDK has stable support, and Eclair has full RPC integration. LND's native BOLT12 support remains incomplete, though foundational work on onion message pathfinding was merged by May 2026.

For interoperability, BOLT12 matters because it provides a richer addressing standard that L2 gateways can use. An SSP or ASP can present a BOLT12 offer that works across protocol boundaries, simplifying the user-facing payment flow.

Splicing

Splicing was formally merged into the BOLTs in March 2026, allowing channels to be resized without closing and reopening them. CLN, LDK, and Eclair now support splicing in production. This reduces the operational overhead of Lightning channel management and makes Lightning a more practical interconnection layer for other L2s.

Taproot Channels

Simple Taproot Channels reduce the on-chain footprint of Lightning channels and lay the groundwork for PTLC adoption. By moving channel operations into Taproot key-path spends, cooperative closes become indistinguishable from regular single-sig transactions on chain. This is a prerequisite for the privacy improvements that PTLCs will eventually bring to cross-L2 swaps.

The Road Ahead: Islands or Archipelago?

Bitcoin's L2s are not islands, but they are not yet a seamless continent either. The better analogy is an archipelago: distinct landmasses connected by bridges of varying quality. Some bridges (Spark to Lightning) are well-paved highways. Others (Ark to Lightning) are newly opened roads. And some routes (Spark to Ark directly) require ferry service through an intermediate island.

The path toward better interoperability runs through three developments:

1. PTLC adoption across Lightning implementations, improving privacy for all cross-layer swaps
2. Standardized addressing (BOLT12, BIP 353) that works across protocol boundaries, so users can pay addresses without knowing the recipient's L2
3. Multi-layer wallets that abstract the L2 selection entirely, routing payments through whichever layer offers the best combination of speed, cost, and reliability for each transaction

Spark's architecture is well-positioned for this future. Its native Lightning compatibility through SSPs already provides transparent cross-layer payments, and its SDK enables developers to build wallets that span both protocols without exposing the complexity to users. To explore building on Spark, see the Spark developer documentation and SDK. For a broader comparison of Bitcoin L2 architectures, see our Bitcoin Layer 2 comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.