Rollups vs State Channels vs Statechains: Bitcoin Scaling Approaches Compared

Bitcoin processes roughly seven transactions per second on its base layer. That constraint is by design: small blocks and slow confirmation times are what make the network censorship-resistant and decentralized. But it also means that scaling Bitcoin for payments, programmability, and everyday use requires moving activity off-chain.

Several fundamentally different architectures have emerged to solve this problem. Rollups batch transactions off-chain and post proofs back to Bitcoin. State channels (most notably the Lightning Network) create bilateral payment tunnels between participants. Statechains transfer UTXO ownership without broadcasting transactions. And federated sidechains like Liquid run parallel blockchains anchored to Bitcoin through a multisig federation.

Each approach makes different assumptions about trust, imposes different costs on the base layer, and targets different use cases. This article builds a comparison framework across five dimensions: trust model, finality speed, cost structure, programmability, and user experience.

How Each Approach Works

State Channels: Lightning Network

The Lightning Network scales Bitcoin by creating bilateral payment channels between two parties. Each channel is backed by a funding transaction on Bitcoin L1 that locks funds into a 2-of-2 multisig. Once open, the two parties can exchange unlimited payments by updating their shared channel state off-chain, secured by hash time-locked contracts (HTLCs) that enforce atomicity across multi-hop routes.

Only two on-chain transactions are ever required: one to open the channel and one to close it. The BOLT specification defines the protocol layer, with recent extensions like BOLT12 adding reusable payment offers and splicing allowing in-place channel resizing without closing.

As of mid-2026, the Lightning Network has over 5,600 BTC in public channel capacity across roughly 17,000 nodes. Including private and unannounced channels used by mobile wallets and LSPs, total capacity is estimated to exceed 12,000 BTC. Monthly payment volume surpasses $1.1 billion.

Statechains: Spark

Spark scales Bitcoin using a statechain architecture that transfers UTXO ownership off-chain. Instead of routing payments through channels, Spark changes who can authorize spending a given output by rotating cryptographic key shares between the sender, receiver, and a set of operators called the Spark Entity.

The mechanism uses a 2-of-2 multisig: one key belongs to the user, and the other is collectively held by operators via FROST threshold signatures. When Alice pays Bob, the Spark Entity generates a new key share for Bob and mathematically adjusts its own share. Alice's old key share is deleted, making it cryptographically useless. The Bitcoin never moves on-chain.

Spark extends the original statechain concept (proposed by Ruben Somsen in 2018) with two critical improvements: a leaf architecture that allows partial-value transfers (solving the whole-coin limitation), and a distributed operator set replacing the single statechain entity with multiple independent operators. The protocol launched in April 2025, with Lightspark and Flashnet as the initial operators.

Rollups: Citrea and the BitVM Approach

Citrea launched mainnet on January 27, 2026, as Bitcoin's first production ZK rollup. It batches thousands of transactions in an EVM-compatible execution environment (a Type II zkEVM), generates a validity proof, and inscribes that proof on Bitcoin for settlement.

The key engineering challenge for Bitcoin rollups is bridging: Bitcoin Script cannot natively verify zero-knowledge proofs, so Citrea uses a BitVM-based bridge called Clementine that implements optimistic verification. Bridge operators post bonds that can be slashed if a challenger proves incorrect computation. The trust model reduces to 1-of-N honesty: one honest signer ensures funds follow pre-approved paths, one honest watchtower can block invalid claims, and one rational challenger can prove fraud.

Citrea completed the first-ever trusted setup ceremony for ZK proofs used in BitVM, with 63 contributions from teams including RiscZero, Nethermind, and StarkWare. The ceremony was the final step before Clementine's mainnet deployment.

Why not optimistic rollups on Bitcoin? Without covenant opcodes like OP_CAT or CTV, Bitcoin cannot natively enforce fraud proof verification on-chain. BitVM works around this by encoding the verifier as a series of Taproot leaves, but the approach is complex and expensive. As of mid-2026, no covenant soft fork has been activated, though CTV+CSFS has emerged as the leading candidate among core developers.

Federated Sidechains: Liquid Network

The Liquid Network, launched by Blockstream in October 2018, is a federated sidechain that runs a parallel blockchain with one-minute block times and Confidential Transactions enabled by default.

Users peg Bitcoin into the network by sending BTC to a federation-controlled multisig address, receiving L-BTC (a 1:1 representation) on the Liquid chain. The federation consists of 87 members as of Q1 2026, but the critical security function is performed by 15 functionaries that sign blocks and manage the two-way peg. The trust model is explicit: you must trust that a majority of functionaries (11 of 15) will not collude to steal pegged funds.

In Q1 2026, Liquid processed over 1.16 million transactions, nearly five times the volume of Q1 2025. The network recorded 14,063 peg-ins (1,252 BTC) and 1,201 peg-outs (1,144 BTC) during the quarter.

Trust Model Comparison

Trust is the most consequential dimension for comparing Layer 2 designs. Each approach makes fundamentally different assumptions about who can steal or freeze your funds.

Lightning is the only approach that achieves full trustlessness: if your counterparty tries to cheat by broadcasting an old channel state, the penalty mechanism lets you claim their entire channel balance. The tradeoff is that you (or a watchtower) must actively monitor the blockchain for these fraud attempts.

Spark's trust model is narrower than it appears. Trust is only required at the moment of each transfer: once key shares are rotated and old shares deleted, operators cannot affect previously completed transactions even if later compromised. This property, sometimes called perfect forward security, means the trust window is measured in milliseconds rather than epochs.

Citrea's rollup trust model is novel for Bitcoin. The validity proof ensures correct execution, but the bridge (Clementine) relies on optimistic assumptions: a challenge period during which anyone can dispute incorrect state transitions. The bridge itself uses 1-of-N honesty, similar in structure to Spark but applied to a different component.

Finality and Settlement Speed

How quickly a payment becomes irreversible varies dramatically across approaches, and the definition of "finality" itself differs.

Lightning and Spark both achieve instant finality within their respective systems. A Lightning HTLC settles in under a second when routing succeeds. A Spark transfer completes as soon as key rotation finishes. The difference is in what guarantees that finality: Lightning relies on game-theoretic punishment (broadcast a stale state and lose your funds), while Spark relies on the operational guarantee that old key shares have been destroyed.

Citrea provides a different kind of finality. Within the rollup, transactions confirm in seconds. But settlement finality on Bitcoin requires the validity proof to be inscribed and confirmed on-chain, which inherits Bitcoin's ~10-minute block time plus any batching delay.

Cost Structure and Base Layer Footprint

Each scaling approach imposes different costs on Bitcoin's limited block space, and these costs propagate to end users in different ways.

Lightning

Opening and closing a channel requires two on-chain transactions, each consuming roughly 150-300 virtual bytes. At a fee rate of 10 sat/vB, that is approximately 3,000-6,000 sats per channel lifecycle. Once open, in-channel payments cost nothing on-chain but incur routing fees (typically 0.01-0.5% per hop). During fee spikes, opening new channels becomes prohibitively expensive for small users, creating a barrier to entry.

Spark

Spark's on-chain footprint is minimal. A single funding transaction anchors a tree of off-chain leaves. All subsequent transfers between users are purely off-chain key rotations with no on-chain cost. Exiting to L1 requires broadcasting a pre-signed transaction, with the cost depending on prevailing fee rates. Small balances may become uneconomical to exit during high-fee periods: a limitation shared by all Bitcoin Layer 2 solutions.

Citrea

Rollups amortize costs across all users in a batch. The rollup operator pays for inscribing proof data on Bitcoin (using Taproot witness space), and this cost is divided among all transactions in the batch. Individual transaction fees on the rollup are paid in gas (Citrea is EVM-compatible), typically orders of magnitude cheaper than L1 transactions. The tradeoff is that someone must continuously pay for proof inscription, creating an ongoing operational cost for the sequencer.

Liquid

Liquid transactions cost a flat 0.1 sat/vB, significantly cheaper than Bitcoin L1. However, the peg-in process requires a Bitcoin L1 transaction plus waiting for 102 Bitcoin block confirmations (roughly 17 hours) before L-BTC is credited. Peg-outs are faster but require federation approval. The low transaction fees are subsidized by the federation members who run the infrastructure.

On-chain footprint matters: During Bitcoin fee spikes (common during periods of high demand for block space), approaches with lower on-chain requirements maintain usability while channel-based systems face pressure. In December 2024, average fees exceeded 100 sat/vB, making Lightning channel opens cost over $15 each. Statechain transfers and rollup transactions were unaffected.

Programmability and Smart Contract Support

A major axis of differentiation is what you can build on each system beyond simple payments.

Lightning: payments only

Lightning is optimized for payments and does not support general-purpose smart contracts. The protocol handles conditional payments via HTLCs (and eventually PTLCs), supports keysend for spontaneous payments, and enables atomic multi-path payments for splitting large transfers. But composable DeFi, token issuance, or arbitrary computation are outside its design scope. Taproot Assets adds token transfer capabilities over Lightning channels, but this is an overlay protocol rather than native programmability.

Spark: payments and native tokens

Spark supports native token issuance through the BTKN standard. Stablecoins like USDB already operate on Spark, enabling dollar-denominated payments that settle over Bitcoin infrastructure. The token model is transfer-oriented rather than computation-oriented: you can issue, transfer, and redeem tokens, but Spark does not provide a general-purpose virtual machine for arbitrary smart contract logic.

Citrea: full EVM compatibility

Citrea runs a Type II zkEVM, providing full Ethereum-compatible smart contract execution anchored to Bitcoin. Developers can deploy Solidity contracts, build DeFi applications, create lending markets, and compose protocols exactly as they would on Ethereum L2 rollups. Citrea launched with over 30 applications including DEXes and lending protocols. The tradeoff is complexity: running an EVM execution layer requires a sequencer, proof generation infrastructure, and the Clementine bridge, all of which introduce additional trust assumptions and operational overhead.

Liquid: scripted transactions with Confidential Transactions

Liquid extends Bitcoin Script with additional opcodes (including OP_CHECKSIGFROMSTACK) and supports asset issuance natively. The primary differentiator is Confidential Transactions, which hide transaction amounts and asset types from public view while still allowing verification. This makes Liquid well-suited for institutional trading and privacy-sensitive transfers. However, Liquid does not support Turing-complete smart contracts or EVM compatibility.

User Experience Comparison

The technical architecture of each system creates distinct UX patterns that determine which use cases each approach serves best.

Channel management: Lightning's persistent challenge

Lightning requires users (or their LSP) to manage channel capacity. Inbound liquidity must be provisioned before receiving payments. Channels need periodic rebalancing. Receiving while offline is not natively supported (though workarounds like async payments are in development). For wallet developers, abstracting this complexity away from end users is a significant engineering challenge. The network trend in 2026 shows consolidation: capital is concentrating into fewer, larger, professional nodes, with the capacity Gini coefficient at roughly 0.97.

Statechains: no channels, no liquidity planning

Spark eliminates channel management entirely. Users hold leaves in a tree structure, and transfers are key rotations that require no capacity planning, no routing, and no channel rebalancing. Receiving while offline is supported natively: Spark Service Providers hold incoming transfers conditionally until the recipient comes online. This makes the mobile wallet experience considerably simpler. The tradeoff is the trust assumption on operator behavior during transfers.

Rollups: familiar but bridged

For users coming from Ethereum, Citrea's EVM environment feels familiar: connect a wallet, interact with dApps, pay gas fees. The primary UX friction is bridging. Moving BTC into the rollup requires interacting with the Clementine bridge, which involves bond posting and challenge periods. Once inside the rollup, the experience mirrors any EVM chain. But the bridge step adds latency and complexity that pure payment-focused systems avoid.

Federated sidechains: straightforward but centralized

Liquid's UX is relatively simple: peg in BTC, transact on the sidechain, peg out when done. The two-minute block time provides faster confirmations than Bitcoin L1. But the 102-confirmation peg-in requirement (~17 hours) creates significant onboarding friction. Peg-outs depend on federation responsiveness. For institutional users who keep funds on Liquid long-term, these are minor issues. For casual users, the peg-in wait is prohibitive.

Which Approach Fits Which Use Case

No single scaling approach dominates across all dimensions. The right choice depends on what you are optimizing for.

High-volume retail payments

Lightning remains the standard for point-of-sale and streaming payments where sub-second settlement is essential and the payment network effect matters. Its established merchant adoption and broad wallet support make it the default for commerce.

Mobile-first wallets and everyday transfers

Spark's statechain model excels here. No channel management means simpler wallet implementations. Offline receiving means users do not need to keep their phone connected. Native token support enables stablecoin payments alongside Bitcoin. For developers building consumer-facing wallets, Spark removes the operational complexity that has historically made Lightning wallets difficult to ship reliably.

DeFi, lending, and programmable finance

Citrea is the clear choice for applications requiring smart contract composability. Lending protocols, DEXes, and complex financial instruments need the programmability that only a full EVM environment provides. The tradeoff in bridge trust and sequencer dependency is acceptable for DeFi users who are already comfortable with similar assumptions on Ethereum L2s.

Institutional trading and privacy

Liquid's Confidential Transactions and regulated federation make it well-suited for exchanges, market makers, and institutions that need privacy for competitive reasons and are comfortable with the federated trust model. The network's growth to over $5 billion in total value locked reflects this institutional adoption.

The complementary view

In practice, these systems are increasingly interoperable rather than competing. Spark includes native Lightning compatibility: users can pay Lightning invoices from their Spark balance and receive Lightning payments into it. Citrea's rollup could eventually interact with Lightning through atomic swaps. Liquid already supports Lightning integration through submarine swaps. The realistic future is a multi-layer stack where each approach handles the use cases it serves best.

The Covenant Question

All four approaches would benefit from Bitcoin covenant opcodes, but none of them are blocked by the absence of a soft fork.

CTV would enable more efficient channel factories for Lightning, reducing on-chain costs for opening and closing channels. OP_CAT would allow native validity proof verification on Bitcoin, potentially replacing BitVM's complex Taproot leaf encoding with a direct on-chain verifier. Both would enable new vault constructions and more expressive spending conditions.

As of mid-2026, CTV+CSFS has emerged as the leading soft fork candidate among Bitcoin Core developers, but competing proposals (including BIP 446/448) have entered the discussion, making the activation timeline uncertain. Teams building on Bitcoin today, including Citrea with BitVM and Spark with FROST, have chosen architectures that work without covenant support while being positioned to benefit from it if activated.

What Developers Should Consider

Choosing a scaling approach for your application comes down to a few key questions:

• Do you need smart contract programmability? If yes, a rollup like Citrea is likely your best option.
• Are you building a payment-focused wallet? Spark eliminates the channel management complexity that makes Lightning wallet development difficult, while maintaining self-custody and Lightning interoperability.
• Do you need transaction privacy? Liquid's Confidential Transactions provide this at the protocol level.
• Is full trustlessness non-negotiable? Lightning is the only approach that achieves this today, though it comes with significant UX overhead.
• Are you targeting institutional users? Liquid's regulated federation and privacy features align with institutional requirements.

For developers interested in building on Spark, the Spark SDK documentation provides wallet and issuer SDKs for self-custodial applications with built-in Lightning compatibility. General Bread is one example of a Spark-powered wallet already live, demonstrating the simplified UX that the statechain model enables.

For deeper comparisons of Bitcoin scaling architectures, see the full Bitcoin Layer 2 comparison and the Bitcoin scaling landscape overview.

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.