Bitcoin Layer 2 — Why the Scaling Problem Is Still Partially Unsolved

Bitcoin processes approximately 7 transactions per second on its base layer. Visa processes around 24,000. The scaling gap between Bitcoin as a payment network and any plausible global payment infrastructure has been acknowledged since at least 2015, and the technical community has spent the decade since attempting to close it through layer 2 solutions — protocols built on top of Bitcoin that inherit its security while enabling higher throughput.

The honest assessment in 2026 is that significant progress has been made, and the problem remains partially unsolved. This is not a failure of engineering ambition; it is a reflection of Bitcoin's distinctive design constraints and governance culture.

## Lightning Network: The Real Adoption Picture

The **Lightning Network**, first proposed in a 2015 whitepaper by Joseph Poon and Thaddeus Dryja, routes transactions through a network of payment channels. Two parties lock Bitcoin into a multi-signature address, transact off-chain by updating a shared balance state, and settle to the blockchain only when they close the channel. In theory, this allows millions of transactions per second at near-zero fees.

The real adoption picture is more complicated. Lightning's public channel graph counts approximately 14,000 routing nodes as of mid-2026, with a total public liquidity of around 5,000 BTC. This is meaningful capacity — enough to handle significant payment volume — but well below early projections. The more instructive metric is who is actually using it and how.

The core problem with Lightning is **inbound liquidity**. To receive payments on Lightning, a node needs channels where the counterparty has allocated Bitcoin to your side of the channel. New participants frequently have outbound liquidity (they can pay) but insufficient inbound liquidity (they cannot easily receive). Managing channel liquidity requires ongoing attention and sometimes capital lockup that retail users find impractical.

The market response has been largely to route around the complexity through custodial Lightning wallets. Services like Wallet of Satoshi, which held significant Lightning adoption volume, operate as custodians — they manage the channels, handle the liquidity, and the user simply has an account balance. This is functionally similar to a bank: fast and convenient, but it reintroduces the trusted intermediary that Bitcoin was designed to eliminate. This raises the question of whether Lightning has scaled Bitcoin or merely created a new layer of custodial services.

It is worth noting that this custodial trend is not necessarily a permanent state. Self-custody Lightning tooling has improved considerably, and protocols like **LSP (Lightning Service Providers)** are creating standardized ways for wallets to access inbound liquidity programmatically. The trajectory is toward better self-custody tools, even if the present state leans custodial.

## Ark: An Alternative Payment Architecture

The **Ark protocol**, proposed by developer Burak in 2023, addresses Lightning's inbound liquidity problem through a different mechanism. Rather than bilateral channels, Ark uses a coordinator (an "Ark Service Provider") to facilitate atomic swaps within a shared UTXO structure. Users can receive Bitcoin without pre-established channels, as the coordinator provides liquidity within a round-based transaction model.

Ark is still early in implementation — production-grade deployments are limited — but it has attracted serious attention as an alternative to Lightning for certain use cases, particularly for users who receive Bitcoin infrequently and don't want to manage channel state. Its trust model is different from Lightning: users must trust the Ark coordinator to some degree during transaction rounds, though they can exit to the base chain unilaterally if needed.

The coexistence of Lightning and Ark reflects a broader reality: there is unlikely to be a single dominant Bitcoin L2, just as there is no single dominant Ethereum L2. Different use cases favor different trust and liquidity trade-off models.

## RGB, BitVM, and Expressiveness on Bitcoin

Bitcoin's scripting language, Script, is intentionally limited. This was a deliberate choice by Satoshi Nakamoto — a restricted script language reduces the attack surface and simplifies the security model. The trade-off is that building complex protocols directly on Bitcoin is significantly harder than on Ethereum, which has a Turing-complete virtual machine.

**RGB** is a client-side validation protocol that moves contract state off-chain while anchoring it to Bitcoin transactions. It enables token issuance and smart contracts whose logic and state are validated by the parties involved rather than by the entire network. RGB's trust model is different from Ethereum's: there is no global shared state machine, which means some classes of applications (like public orderbooks or fully composable DeFi) are difficult or impossible to implement cleanly.

**BitVM**, proposed by Robin Linus in 2023, demonstrated a theoretical mechanism for expressing any computation verifiable on Bitcoin, using Bitcoin's existing script capabilities in a clever challenge-response structure. BitVM contracts require interaction between parties (they cannot be fully non-interactive) and are currently impractical for many use cases due to transaction size constraints — but they have demonstrated that Bitcoin's expressiveness limits are softer than previously assumed.

**Babylon Protocol** approaches the problem differently: rather than building applications on Bitcoin, it uses Bitcoin's security directly as staking collateral for other proof-of-stake chains. Bitcoin holders can stake their BTC to provide economic security to external chains without wrapping or bridging their coins, using a timestamping mechanism anchored to Bitcoin's base layer. This positions Bitcoin as a shared security asset rather than purely a payment network.

## Bitcoin's Upgrade Culture and Fragmentation

The fundamental reason Bitcoin's L2 development is more fragmented than Ethereum's is Bitcoin's governance culture. Ethereum's ability to ship significant protocol changes through rough consensus and coordinated hard forks — EIP-1559, the Merge, Dencun, Pectra — has no real analogue in Bitcoin. Bitcoin Improvement Proposals that touch the base layer face extraordinarily high scrutiny and social resistance, for reasons that are philosophically coherent given Bitcoin's design goals.

**OP_CAT**, a basic operation that would concatenate data on the stack and that was removed from Bitcoin in 2010, has been proposed for re-enablement multiple times. It would meaningfully expand what is possible in Script and enable cleaner vault and covenant implementations. It remains unactivated as of mid-2026, despite years of discussion, because a subset of technically influential participants objects to its expressive scope.

This conservatism is defensible — a change to Bitcoin's base layer, once activated, cannot be easily undone, and the risk of unintended consequences is real. But it means that L2 developers must build within constraints that will not be relaxed quickly, producing a more diverse and less composable ecosystem than Ethereum's.

> **Key Takeaway:** Bitcoin's scaling problem is real and the solutions in progress are genuine, but the fragmentation of L2 approaches — Lightning for payments, Ark as an alternative, RGB for tokens, BitVM for contracts, Babylon for staking — reflects both the richness of the design space and the absence of a coordinating upgrade path that Ethereum has used to standardize its L2 ecosystem. The Lightning Network's real adoption is substantial but remains partly dependent on custodial intermediaries, which partially reintroduces the trust assumptions Bitcoin was built to eliminate.

Bitcoin Layer 2 — Why the Scaling Problem Is Still Partially Unsolved

// COMMENTS

ON THIS PAGE