Bitcoin Layer 2 Comparison: Lightning, Spark, Liquid, and More

Bitcoin processes roughly seven transactions per second on its base layer. That constraint is by design: decentralization and security take priority over throughput. But as adoption grows, the gap between base-layer capacity and real-world demand has driven an entire ecosystem of Layer 2 protocols, each making different tradeoffs to extend what Bitcoin can do.

This article compares the major Bitcoin Layer 2 solutions: Lightning, Spark, Liquid, Rootstock (RSK), Stacks, Ark, and RGB. Rather than declaring a single winner, it maps each protocol's architecture, trust assumptions, and capabilities so that builders and users can choose the right tool for the job.

What Qualifies as a Bitcoin Layer 2?

There is no universally agreed-upon definition, but a useful working framework requires two properties: the protocol derives its security from Bitcoin (either directly or through economic incentives tied to BTC), and users retain some mechanism to exit back to Bitcoin L1 without relying entirely on a third party. Under a stricter definition, only systems where unilateral exit is enforced by Bitcoin consensus qualify. Under a broader definition, federated sidechains and anchored smart-contract layers also count.

Each protocol in this comparison sits at a different point on that spectrum. Understanding where they fall is essential to evaluating their trust models.

Lightning Network

Lightning is the oldest and most widely deployed Bitcoin Layer 2. It uses bidirectional payment channels secured by HTLCs (hash time-locked contracts) to route payments across a network of interconnected nodes. The protocol is defined by the BOLT specification, and multiple independent implementations exist (LND, CLN, Eclair, LDK).

Architecture

Two parties lock Bitcoin into a 2-of-2 multisig UTXO on-chain. They then exchange signed commitment transactions off-chain, updating balances without broadcasting. Payments route through multiple channels using onion routing, where each hop only knows its immediate predecessor and successor.

Channel state is enforced through a revocation mechanism: if either party broadcasts an outdated commitment, watchtowers or the counterparty can claim a justice transaction that penalizes the cheater.

Strengths and limitations

Lightning is fully trustless: no federation, no operator, no third-party key holders. Payments settle in seconds with sub-satoshi fees. The network has significant adoption among wallets, exchanges, and merchants.

The tradeoffs are operational. Liquidity management is a persistent challenge: users and routing nodes must maintain inbound liquidity and channel capacity across their connections. Receiving payments requires the recipient to be online. Routing fees and path-finding complexity grow with network scale. Techniques like channel factories, splicing, and dynamic channel resizing address some of these issues, but the fundamental complexity of channel management remains.

Spark

Spark is a statechain-based Layer 2 that enables instant, self-custodial Bitcoin transfers without payment channels. Rather than creating channels between pairs of users, Spark transfers ownership of existing on-chain UTXOs by rotating cryptographic keys between sender, recipient, and a distributed operator set.

Architecture

Spark uses a 2-of-2 signing model where one key belongs to the user and the other is collectively held by the Spark Entity (a set of independent operators) using FROST threshold signatures. When a transfer occurs, the operator set generates a new key for the recipient and deletes the old key share corresponding to the sender. The on-chain UTXO never moves: what changes is the cryptographic ability to spend it.

Spark introduces a leaf architecture that solves the traditional statechain limitation of whole-UTXO transfers. Balances can be split and merged off-chain, enabling arbitrary payment amounts without on-chain interaction.

Trust model and exit

Spark operates under a 1-of-n trust assumption: as long as one operator behaves honestly, user funds are safe. Operators cannot unilaterally move funds (they only hold one key in the 2-of-2), and users receive pre-signed exit transactions that allow unilateral withdrawal to L1 at any time. This trust model applies only at the moment of transfer: once keys are rotated and old shares deleted, even a later compromise of all operators cannot reverse a completed transfer.

Stablecoins on Spark: Spark natively supports token issuance through the BTKN standard. Stablecoins like USDB operate directly on Spark, enabling dollar-denominated payments with Bitcoin-grade self-custody. This is a differentiator: most Bitcoin L2s require bridging to other chains for stablecoin functionality.

Lightning interoperability

Spark integrates natively with Lightning through Spark Service Providers (SSPs). Users can pay Lightning invoices from their Spark balance and receive Lightning payments into it, with atomic swaps ensuring that either both legs of the transfer complete or neither does. Unlike Lightning, Spark users can receive payments while offline: SSPs hold incoming payments conditionally until the recipient connects.

Liquid Network

Liquid is a federated sidechain developed by Blockstream. It uses a federation of functionaries (currently around 65 members including exchanges, financial institutions, and infrastructure companies) to manage the two-way peg between Bitcoin and L-BTC, the Liquid-native asset.

Architecture

Liquid produces blocks every minute using a round-robin signing schedule among federation members. Transactions achieve functional finality after two confirmations (roughly two minutes). The federation operates a multisig wallet that custodies the BTC backing all L-BTC in circulation.

Liquid supports Confidential Transactions, which hide transaction amounts and asset types from outside observers using Pedersen commitments and range proofs. It also supports the issuance of arbitrary assets (security tokens, stablecoins, NFTs) through its Issued Assets feature.

Trust model

Liquid requires trusting that a threshold of federation members (currently 11-of-15 for block signing) will not collude to steal funds or censor transactions. Users cannot unilaterally exit: recovering BTC from the federation requires cooperation from at least the signing threshold. This makes Liquid more centralized than Lightning or Spark, but the federation model provides operational reliability that channel-based systems sometimes lack.

Rootstock (RSK)

Rootstock is a merge-mined sidechain that brings EVM compatibility to Bitcoin. It shares hash power with Bitcoin miners, meaning the same proof-of-work securing Bitcoin also secures RSK blocks.

Architecture

RSK produces blocks roughly every 30 seconds and supports Solidity smart contracts. The peg between BTC and RBTC (RSK's native asset) is managed by PowPeg, a federation of hardware security modules (HSMs) that hold the BTC backing. PowPeg incorporates merge-mining attestations into its security model, making it harder for federation members to act maliciously without detection.

Trust model

RSK's trust model is hybrid: block production is secured by Bitcoin's hash rate through merge mining, but the peg itself depends on the PowPeg federation. The federation is designed to be progressively decentralized, but as of today, users must trust that the HSM operators will not collude. Smart contract execution is fully deterministic and enforced by RSK consensus.

Stacks

Stacks uses Proof of Transfer (PoX), a consensus mechanism where Stacks miners spend BTC to mine STX blocks. This creates an economic link between Stacks and Bitcoin without sharing hash power directly.

Architecture

Stacks uses the Clarity smart contract language, a decidable language where contract behavior can be analyzed before execution. With the Nakamoto upgrade, Stacks blocks finalize with Bitcoin blocks, tightening the connection between the two chains.

The sBTC mechanism enables a trust-minimized Bitcoin peg: a dynamic set of signers manages the BTC deposits, with economic incentives tied to their STX holdings. This represents an improvement over static federation models, though it still requires trusting the signer set.

Trust model

Stacks block production is permissionless (anyone can mine by spending BTC), but the Bitcoin peg depends on the sBTC signer set. Smart contract execution is enforced by Stacks consensus and anchored to Bitcoin through PoX. The trust profile is stronger than a pure federation but weaker than systems with cryptographic unilateral exit.

Ark

Ark is a newer protocol designed to address Lightning's liquidity and interactivity requirements. It introduces virtual UTXOs (VTXOs) that live off-chain and are periodically settled into shared on-chain UTXOs managed by an Ark Service Provider (ASP).

Architecture

Users receive VTXOs from the ASP during periodic rounds. Each round creates a shared on-chain transaction that commits to all VTXOs in that batch. VTXOs can be transferred off-chain between rounds without additional on-chain transactions. The protocol was originally designed to leverage covenants, but covenant-less variants (using pre-signed transaction trees) also exist.

Trust model

Ark requires trusting the ASP for liveness (if the ASP disappears, users must exit on-chain before their VTXOs expire) but not for safety: users can always unilaterally exit by broadcasting their VTXO redemption path. The model is similar to Spark's liveness-vs-safety separation, though the mechanisms differ significantly.

RGB

RGB takes a fundamentally different approach: client-side validation. Rather than replicating state across a network of nodes, RGB stores contract state privately with the parties involved. Bitcoin transactions serve as commitment anchors (using OP_RETURN or Taproot commitments) that prove state transitions occurred without revealing their contents.

Architecture

RGB uses single-use seals tied to Bitcoin UTXOs: each state transition consumes a seal and creates new ones. Smart contracts are defined using a schema system, and state is validated by the recipient rather than a global network. This makes RGB inherently private and scalable, since the blockchain carries only commitments, not data.

Trust model

RGB inherits Bitcoin's trust model for the commitment layer: state transitions are as immutable as the Bitcoin transactions that anchor them. There is no federation or operator. The tradeoff is complexity: interactivity requirements (both parties must be online), limited tooling maturity, and the challenge of building user-friendly applications on top of a client-side validation model.

Comparison: Trust Model and Finality

The following table compares each protocol's fundamental trust assumptions and finality characteristics.

Unilateral exit matters: The ability to withdraw funds to Bitcoin L1 without anyone's permission is the strongest guarantee a Layer 2 can offer. Lightning, Spark, Ark, and RGB all provide this. Federated systems (Liquid, RSK, Stacks) require cooperation from their respective signer sets, making them custodial to varying degrees.

Comparison: Capabilities

Beyond trust and finality, each L2 offers different capabilities for builders and users.

Which Layer 2 for Which Use Case

No single Layer 2 dominates every scenario. The right choice depends on what you are building and which tradeoffs your users can accept.

Payments and point-of-sale

Lightning remains the standard for merchant payments, with broad wallet support and established payment flows. Spark offers a compelling alternative for applications that need simpler wallet integration: no channel management, no liquidity provisioning, and the ability to receive while offline. For stablecoin payments specifically, Spark's native BTKN support avoids the bridging overhead required on other L2s.

Trading and settlement

Liquid was designed for this. Its Confidential Transactions hide trade amounts from chain observers, two-minute settlement is fast enough for most trading workflows, and the federation model provides consistent uptime. Many Bitcoin exchanges already support L-BTC deposits and withdrawals.

DeFi and smart contracts

RSK and Stacks are the primary options for complex programmability on Bitcoin. RSK's EVM compatibility lets developers port existing Solidity contracts. Stacks' Clarity language offers stronger safety guarantees through decidability: you can prove what a contract will do before deploying it. RGB offers a longer-term vision of smart contracts with maximal privacy, though tooling is still maturing.

Tokenization

Several L2s support token issuance, but with different tradeoffs. Liquid's Issued Assets are battle-tested for security tokens. RGB provides the strongest privacy guarantees for tokenized assets. Spark enables tokens (including stablecoins) with instant settlement and self-custody, making it well-suited for payment-oriented tokens like USDB.

Privacy

RGB leads on privacy: contract state never touches a public ledger. Liquid's Confidential Transactions provide strong on-chain privacy within the sidechain. Lightning's onion routing protects payment paths but not channel balances. Spark and Ark currently expose transaction metadata to their operators, though Spark's operator set is distributed across independent entities.

The Layer 2 Interoperability Question

Bitcoin Layer 2s have historically been isolated. A user on Liquid cannot directly transact with a user on Spark or Lightning without some form of bridging. This fragmentation creates friction: liquidity splinters across protocols, and users must choose which L2 to lock funds into.

Current bridges

The most mature bridge mechanism is submarine swaps, which use HTLCs to atomically exchange assets between Lightning and on-chain Bitcoin. Similar techniques extend to other L2s: Spark's SSP model uses atomic swaps for Lightning integration, and Liquid supports loop-in/loop-out operations via third-party services.

Toward composability

True cross-L2 composability requires either a shared settlement layer (Bitcoin L1 already serves this role, but slowly) or standardized protocols for atomic cross-L2 transfers. Proposals like PTLCs (point time-locked contracts) could improve cross-system atomic swaps by replacing hash locks with Schnorr-based adaptor signatures, enabling better privacy and flexibility.

In practice, the near-term path to interoperability is Lightning as a common routing layer. Spark already connects natively. Liquid and RGB have active Lightning integration work. If most L2s can send and receive via Lightning, users gain interoperability without needing direct L2-to-L2 bridges.

Emerging Trends

Covenant-based scaling

Proposals like OP_CTV, OP_CAT, and LNHANCE could unlock new Layer 2 designs that reduce trust assumptions further. Ark in particular would benefit from native covenant support, eliminating the need for pre-signed transaction trees. Covenants would also enable more efficient channel factories for Lightning and potentially new constructions that combine the best properties of multiple existing L2s.

BitVM and validity proofs

BitVM introduces the possibility of optimistic verification on Bitcoin: proving that off-chain computation was executed correctly without replicating it on-chain. This could eventually enable trust-minimized rollups on Bitcoin, bringing the scalability model that has proven effective on Ethereum to the Bitcoin ecosystem. Several teams are exploring BitVM-based bridges that would replace federated pegs with cryptographic verification.

Convergence of approaches

The lines between L2 categories are blurring. Spark combines statechain concepts with Lightning interoperability. Ark borrows ideas from both payment channels and statechains. RGB is exploring Lightning integration for instant transfers. The trend points toward hybrid protocols that combine multiple scaling techniques rather than relying on a single architecture.

Summary of Tradeoffs

Every Bitcoin Layer 2 sacrifices something. The question is whether those sacrifices align with your requirements.

• Lightning sacrifices simplicity for trustlessness: you get the strongest security model but must manage channels and liquidity.
• Spark sacrifices full trustlessness for usability: the 1-of-n operator model enables a dramatically simpler wallet experience while preserving self-custody and unilateral exit.
• Liquid sacrifices self-custody for reliability: the federation model provides consistent performance and strong privacy but requires trusting the functionary set.
• RSK and Stacks sacrifice Bitcoin-native simplicity for programmability: they bring smart contract platforms to Bitcoin but depend on their own consensus and peg mechanisms.
• Ark and RGB sacrifice maturity for innovation: they explore novel architectures that could reshape Bitcoin scaling but are earlier in their development cycles.

The Bitcoin Layer 2 landscape is not a zero-sum competition. Each protocol serves different users with different needs. A developer building a payment application may choose Spark for its simplicity and stablecoin support. A trader may prefer Liquid for its speed and privacy. A DeFi builder may need RSK's EVM. An exchange may run Lightning for its trustlessness and network effects. The ecosystem is stronger with multiple options than it would be with just one.

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.