Layer 2

What Is Layer 2?

A Layer 2 (L2) is a protocol that sits on top of a base blockchain (Layer 1, or L1) and handles transactions off-chain while inheriting the security of the underlying network. The core idea: move the bulk of transaction processing away from the congested main chain, then anchor the results back to L1 so users retain the same trust guarantees.

Think of Layer 1 as a courthouse: it provides the final, authoritative resolution of disputes, but it would be impractical for every daily interaction to go through a courtroom. Layer 2 protocols are like contracts and agreements that people use day-to-day, with the understanding that either party can escalate to the courthouse if something goes wrong. Most transactions never need the court, but its existence enforces honest behavior.

The need for L2 solutions stems from a fundamental limitation of blockchains. Bitcoin processes roughly 7 transactions per second. Ethereum handles about 15. These numbers are orders of magnitude below what global payment networks require. Increasing L1 throughput directly (bigger blocks, faster block times) compromises decentralization or security. L2 protocols offer a way to scale without sacrificing the properties that make blockchains valuable in the first place.

How It Works

All Layer 2 protocols share a common pattern: they move transaction execution off-chain while using the base layer as an anchor for security. The specific mechanisms vary by architecture, but the general flow is:

1. Users lock or commit funds on the Layer 1 chain
2. Transactions occur off-chain according to the L2 protocol rules
3. The L2 periodically commits state updates or proofs back to L1
4. Users can exit the L2 and reclaim funds on L1, with L1 enforcing correctness

The critical property is security inheritance: users should always be able to recover their funds on L1, even if the L2 operators become uncooperative or go offline. The strength of this guarantee varies across L2 designs.

Payment Channels

Payment channels are the oldest and most battle-tested L2 approach on Bitcoin. Two parties lock funds in a multisig UTXO on-chain, then exchange signed transactions off-chain to update their balances. Only the opening and closing transactions touch the blockchain.

The Lightning Network extends this concept into a network of payment channels. By routing payments through intermediary nodes using HTLCs, any two participants can transact without a direct channel between them. Lightning can process millions of transactions per second in theory, with settlement finality in milliseconds.

# Simplified payment channel lifecycle
1. Open:   Alice + Bob fund 2-of-2 multisig on-chain (1 tx)
2. Use:    Exchange signed commitment transactions off-chain (0 tx)
3. Close:  Publish final state on-chain (1 tx)

# Result: 2 on-chain transactions for unlimited off-chain transfers

The tradeoff: payment channels require participants to be online and monitor the chain for fraud. If Bob tries to publish an old state where he had more funds, watchtowers or Alice herself can submit a justice transaction to penalize him. For a deeper look at channel mechanics, see the research on payment channels from concept to implementation.

State Channels

State channels generalize payment channels beyond simple value transfer. Instead of just tracking balances, state channels can track any application state: game moves, contract executions, or complex multi-party interactions. The participants agree on state transitions off-chain and can settle to L1 at any time.

The challenge with state channels is that all participants must be identified upfront, and the channel must be opened before transactions can occur. This makes them excellent for repeated interactions between known parties, but less suitable for open-ended applications with arbitrary participants.

Rollups

Rollups take a different approach: they execute transactions off-chain but post transaction data (or validity proofs) back to L1. This means L1 can always verify the correctness of the L2 state. Rollups come in two flavors:

• Optimistic rollups: assume transactions are valid by default and only run computation on L1 if someone submits a fraud proof during a challenge period (typically 7 days)
• ZK-rollups: generate cryptographic validity proofs (zero-knowledge proofs) for each batch of transactions, which L1 verifies before accepting the state update

Rollups are the dominant L2 scaling approach on Ethereum, powering networks like Arbitrum, Optimism, and zkSync. On Bitcoin, rollup designs are more constrained because Bitcoin Script has limited programmability, though proposals like BitVM are exploring ways to enable fraud proofs on Bitcoin.

Sidechains

Sidechains are independent blockchains with their own consensus mechanisms that are connected to the main chain via a two-way peg. Users lock funds on L1 and receive equivalent tokens on the sidechain, where they can transact with different rules (faster blocks, lower fees, smart contracts).

Sidechains have weaker security inheritance than other L2 types: the sidechain's security depends on its own validator set, not on the L1. If the sidechain validators collude, user funds could be at risk. Bitcoin's Liquid Network is a notable sidechain example, using a federation of functionaries rather than Bitcoin's proof-of-work for consensus.

Statechain and Spark

Spark represents a newer category of Bitcoin L2 that uses statechains and threshold signatures to enable off-chain transfers of UTXOs without payment channels. Instead of routing payments through a network of channels, Spark transfers ownership of UTXOs by rotating signing keys between the sender, receiver, and a set of operators using Schnorr-based threshold schemes.

This approach avoids the liquidity constraints of payment channels: there is no channel capacity limit, no inbound liquidity requirement, and no need for complex routing. Users retain the ability to unilaterally exit to L1 at any time. For a comprehensive overview, see What Is Spark: Bitcoin Layer 2.

Bitcoin L2 vs. Ethereum L2

The L2 landscape looks very different on Bitcoin compared to Ethereum, largely because the base layers have different capabilities:

Bitcoin's limited scripting means L2 designs must work within tighter constraints. This has led to creative solutions like HTLCs, Schnorr signatures, and threshold cryptography. Proposed covenants (like OP_CTV) could expand what Bitcoin L2s can do, enabling more trust-minimized designs. For a detailed comparison, see the research on Bitcoin Layer 2 comparison.

Use Cases

• Micropayments: L1 transaction fees make payments under a few dollars impractical on Bitcoin. L2 protocols enable sub-cent transactions, unlocking use cases like streaming payments, pay-per-article, and machine-to-machine payments.
• Point-of-sale payments: retail transactions require confirmation in seconds, not minutes. Lightning and Spark provide near-instant settlement, making Bitcoin viable for everyday purchases.
• Stablecoin transfers: protocols like Spark support stablecoin issuance and transfer on Bitcoin L2, combining dollar stability with Bitcoin's security. See the research on USDB: a stablecoin that pays Bitcoin.
• Cross-border remittances: sending value internationally through L2 protocols avoids the multi-day delays and high fees of traditional correspondent banking.
• DeFi on Bitcoin: newer L2 designs are bringing programmable finance to Bitcoin, including lending, swaps, and yield generation without relying on Ethereum or other chains.

The Scalability Trilemma

Layer 2 protocols exist because of the blockchain scalability trilemma: it is difficult for a single system to simultaneously maximize decentralization, security, and scalability. L1 blockchains like Bitcoin prioritize decentralization and security at the cost of throughput. L2s reclaim scalability by processing transactions off-chain.

However, L2s introduce their own trilemma of sorts. Each design makes tradeoffs:

• Lightning offers trustless, instant payments but requires online participation, channel management, and sufficient liquidity across the route
• Rollups achieve high throughput with strong security guarantees but add withdrawal delays (optimistic) or computational overhead (ZK)
• Sidechains provide flexibility and performance but rely on their own consensus, weakening security inheritance
• Spark eliminates channel management complexity but introduces reliance on operator availability for cooperative transfers (with unilateral exit as fallback)

Risks and Considerations

Security Inheritance Varies

Not all L2s are equal in how much security they inherit from L1. A channel-based L2 like Lightning gives users a direct on-chain enforcement path: if your counterparty cheats, you can submit a justice transaction to L1 and claim their funds. A federated sidechain like Liquid requires trusting a consortium of validators. When evaluating an L2, the key question is: can users always recover their funds on L1 without anyone else's cooperation?

Liveness Requirements

Many L2 designs require participants (or their delegates) to be online and monitoring the chain. In Lightning, if you go offline and your counterparty publishes an old channel state, you need to respond with a penalty transaction before the timelock expires. Services like watchtowers mitigate this, but they add another dependency.

Liquidity Fragmentation

Funds locked in L2 protocols are not immediately available on L1, and moving between different L2s often requires going through L1 as an intermediary. As more L2 protocols launch, liquidity fragments across systems. This is especially pronounced in the Ethereum ecosystem, where dozens of rollups each hold separate pools of liquidity.

Complexity and User Experience

L2 protocols add layers of complexity for both developers and users. Channel management, liquidity provisioning, withdrawal periods, and bridge security are all concerns that don't exist on L1. The best L2 solutions abstract this complexity away: users should not need to understand the underlying protocol to use it safely. Spark's SDK approach aims to make L2 interaction as simple as a standard wallet API.

Regulatory Uncertainty

As L2 protocols handle increasing transaction volume, regulators are examining whether L2 operators (node operators, sequencers, federations) have compliance obligations. The regulatory treatment of L2 infrastructure is still evolving across jurisdictions, creating uncertainty for builders and operators.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.