Section V: Bitcoin Layer 2 and Extensions

Having established how Bitcoin's network operates and maintains security, we can now explore how these foundational mechanisms enable higher-layer innovation. This section examines two distinct categories of extension: scaling solutions that move transactions off-chain for speed and cost efficiency, and data layer applications that leverage Bitcoin's immutability for on-chain use cases. While these serve fundamentally different purposes (one addresses throughput constraints, the other exploits Bitcoin's censorship-resistant storage), both demonstrate how a simple, constrained base layer can enable sophisticated higher-layer functionality.

Scaling: L2 Classification and Trust Models

Before examining specific scaling solutions, it's essential to understand what actually qualifies as a Layer 2 (L2) and what security guarantees are possible given Bitcoin's current capabilities. Numerous projects claim to offer Bitcoin L2 solutions with different tradeoff profiles, but evaluating these claims requires a clear definitional framework.

The fundamental dilemma centers on a basic limitation: while Bitcoin Script can verify signatures and basic spending conditions, it cannot enforce complex constraints on future transactions or verify claims about external state.

The definitional challenge stems from what constitutes a genuine L2: a scaling solution that inherits the security properties of its base layer without introducing additional trust assumptions. True L2s allow users to unilaterally exit back to the main chain using only cryptographic proofs, no permission needed from any third party. The base layer's consensus mechanism can directly adjudicate disputes and enforce the L2's rules. Most current Bitcoin scaling solutions, however, are more accurately described as sidechains or federated networks with Bitcoin bridges, since they require users to rely on external validators beyond Bitcoin's own consensus.

This creates a security constraint for L2 bridges and rollups. When someone wants to withdraw funds from an L2 back to Bitcoin's main chain, the system needs a way to verify that the withdrawal is legitimate according to the L2's state. However, Bitcoin Script cannot practically check things like "this withdrawal matches an entry in the L2's state tree" or "these outputs correspond to a valid Merkle proof." Script lacks the needed covenant and introspection primitives to make this practical without reliance on intermediaries.

As a result, today's Bitcoin L2 solutions fall back on third-party validators, federations of signers, multisig arrangements, or programmatic attesters, to validate and co-sign withdrawals. This is exactly what systems like Stacks' sBTC do with their "decentralized network of signers." While these signers may be distributed across multiple parties, they still represent a fundamental custody risk: if they collude, get compromised, or their software has bugs, user funds can be censored or stolen. The "trustless" promise of cryptocurrency gets reduced to relying on this federation model.

Potential Solutions: Covenants and Alternatives

Developers have proposed several ways to fix Bitcoin's L2 limitations. Each approach offers different tradeoffs between how soon it could work and how secure it would be.

The most straightforward solution involves upgrading Bitcoin itself. Developers have proposed adding new opcodes to Bitcoin's programming language through a soft fork. The leading candidates include re-enabling something called OP_CAT and adding new tools like CTV and CSFS. Together, these would let Bitcoin scripts create custom messages, verify signatures, and set rules about how coins can be spent later.

For L2 bridges, this would be transformative. Right now, you have to trust a group of signers to approve withdrawals. With covenants, Bitcoin's blockchain could check the math itself and enforce the exit rules automatically. You could withdraw your funds using only cryptographic proofs, and no federation could stop you. The debate now focuses on figuring out the smallest set of new opcodes that would enable this safely. None of these proposals are active yet, and they would need broad agreement from the Bitcoin community to implement.

While covenant opcodes might take years to activate, BitVM takes a different approach. It works with Bitcoin exactly as it exists today, without any upgrades needed. BitVM and its newer versions (BitVM2 and BitVM3) use what's called an optimistic model.

Here's how it works: an operator makes a claim about what's happening on the L2. If they're lying, anyone can challenge them on the Bitcoin blockchain within a certain window (usually a few days to two weeks). If the challenge succeeds, the operator loses the money they put up as collateral. Recent research claims BitVM3 can reduce the data needed to about 66 kilobytes using something called garbled circuits, but the designs are still changing quickly. In fact, one version from July 2025 had to be pulled back after researchers found a security flaw. These approaches are still experimental rather than ready for real use.

BitVM systems have important limitations. They're complicated to run and require active participation. Someone has to actually watch for fraud and challenge it within the time window. The security depends on at least one honest person being willing and able to raise the alarm. This is fundamentally different from covenant-based systems, where Bitcoin itself checks the proofs directly without needing anyone to file a dispute.

The key distinction comes down to who enforces the rules. Today's federation-based systems ask you to trust that most signers will be honest. Covenant-enabled systems would move that enforcement into Bitcoin's consensus rules themselves, making invalid withdrawals literally impossible to include in the blockchain regardless of what any federation tries to do. This would be a major security upgrade.

Whether Bitcoin will actually adopt these changes, and when, is still an open question in the development community.

Lightning Network

Bitcoin's base layer is optimized for high-assurance settlement, which makes small everyday payments economically inefficient. High fees and limited block space mean buying coffee with an on-chain transaction doesn't make sense. The Lightning Network attempts to solve this by moving small, frequent payments off the main blockchain.

The basic concept is straightforward. Instead of broadcasting every payment to the entire network, two parties can open a private payment channel by locking funds in a special on-chain transaction that requires both signatures to spend. Once the channel is open, they can update their balances off-chain by creating new versions of how the funds could be split, along with cryptographic penalties that punish anyone who tries to cheat by broadcasting an old state. When they're done transacting, they can close the channel and settle the final balance back to the main blockchain.

The network becomes more powerful through routing. Users don't need direct channels with everyone they want to pay. If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol through Bob. The network uses routing techniques that hide the full payment path from intermediate nodes, providing better privacy than repeatedly using the same on-chain addresses. However, the privacy isn't perfect. Careful analysis of payment amounts, timing, and network probing can still reveal information.

Lightning's Strengths

When Lightning works well, it delivers compelling advantages. Payments settle in seconds rather than waiting for block confirmations, making it viable for point-of-sale transactions and interactive applications. Transaction costs drop to negligible amounts, often just a few satoshis, enabling microtransactions that would be completely impractical on the base layer. The off-chain nature of payments provides better privacy than repeatedly using the same on-chain addresses, as intermediate routing nodes only see encrypted payment data. For users who establish well-connected channels with sufficient liquidity in both directions, Lightning can provide a smooth payment experience that approaches the convenience of traditional payment systems while maintaining non-custodial control of funds.

The Liquidity Challenge

Lightning users can only send payments if there's enough balance on their side (outbound capacity), and they can only receive payments if the other side has enough room (inbound capacity). This liquidity constraint is Lightning's biggest practical limitation.

When channels lack sufficient liquidity in the right direction, payments fail or must be split across multiple routes. Some technical improvements help: payments can be automatically split across several paths to improve success rates, and specialized service providers can help users acquire the inbound capacity needed to receive payments. Channel rebalancing can redistribute liquidity, but it costs fees and takes time. Even with these tools, the fundamental challenge of having liquidity in the right place at the right time remains.

Operational Realities

Lightning faces several hurdles to adoption. Unlike Bitcoin's base layer where payments arrive automatically even when the recipient is offline, Lightning typically requires users to be online to receive payments. Some services can monitor channels for cheating attempts while you're offline, keeping your funds safe, but they don't enable offline receiving itself.

Some wallet providers offer workarounds that allow payments to arrive when you're offline, but these often involve trusting the service provider with some custody or control. For users, managing channels is complex. They must acquire inbound capacity to receive payments, stay online or use trusted services, and navigate the separation between L1 and L2. This operational overhead is difficult for non-technical users.

Higher base layer fees create additional challenges. Opening and closing channels becomes more expensive, and during fee spikes, time-sensitive transactions may need to be confirmed quickly or risk forcing channels to close. Modern improvements allow channels to be resized without fully closing them and enable better fee management, but the operational complexity remains.

For merchants, integration complexity is compounded by Bitcoin's price volatility, which creates accounting and pricing challenges regardless of whether payments arrive on-chain or through Lightning.

The Custodial Trade-off

These limitations have led many users toward custodial or semi-custodial Lightning wallet services that manage channels and liquidity on their behalf. While this dramatically improves user experience and payment reliability, it reintroduces the trust requirements and vulnerabilities that Bitcoin was designed to eliminate. Users face custodial risk: funds can be frozen, accounts can be closed, services can fail, and providers must be trusted not to mismanage or steal funds. This represents a fundamental tension between usability and the self-sovereignty that attracted many to Bitcoin in the first place.

Beyond Payments: Bitcoin as a Data Layer

Having explored scaling solutions aimed at transaction throughput and smart contracts, we now turn to an entirely different category of Bitcoin extension. While Lightning and L2s attempt to reduce on-chain activity, Ordinals and inscription-based systems embrace it, using Bitcoin's immutability and censorship resistance to anchor arbitrary data permanently on the blockchain. This represents a philosophical shift from "Bitcoin as payment rail" to "Bitcoin as permanent storage layer."

Ordinal Theory

Ordinal theory is a way of treating individual satoshis as unique, collectible units rather than interchangeable currency. The core idea is simple: assign every satoshi a serial number based on when it was mined. This numbering system allows specific satoshis to be tracked as they move through transactions, similar to how you might track a dollar bill by its serial number.

This tracking system enables a practice called inscriptions, where users attach arbitrary data (images, text, or other content) to specific satoshis. The inscribed satoshi becomes a carrier of that digital content, creating something analogous to digital collectibles or NFTs directly on the Bitcoin blockchain.

Inscriptions use a two-step process. First, a transaction commits to what will be inscribed. Then, a second transaction reveals the actual content by including it in the transaction's witness data. This stores the content directly on the blockchain rather than just storing a reference to external data.

This approach differs from earlier methods of embedding data in Bitcoin. The inscription data lives in witness space, which can be pruned by nodes that don't want to store it after validation. Archive nodes and specialized indexers maintain the full inscription history, allowing users to retrieve the content even if many nodes have pruned it.

Bitcoin-Native NFTs

An inscribed satoshi functions like a Bitcoin-native NFT: a unique token with on-chain content and provenance that transfers by moving that specific satoshi. The architectural difference from Ethereum's NFTs is notable. Ethereum relies on smart contract standards like ERC-721, often with media stored off-chain on services like IPFS. Bitcoin achieves uniqueness through ordinal numbering, with the media bytes embedded directly in the blockchain's witness data. The result is a digital artifact whose uniqueness is enforced by Bitcoin's transaction model combined with off-chain indexers that follow ordinal conventions.

Transferring an inscription requires careful control of which satoshis are being spent. Users must ensure their transaction's input and output ordering moves the target inscribed sat and not the surrounding ones. Purpose-built wallets and specialized tooling provide this precise sat selection capability. Experts recommend keeping inscribed sats in separate addresses to avoid accidental merges or spends, while marketplaces often use partially signed transactions so users can verify exactly which inscription is being transferred before signing.

BRC-20: Experimental Fungible Tokens

While Ordinals create unique digital artifacts, BRC-20 extends the concept to fungible tokens on Bitcoin. Rather than using smart contracts, BRC-20 uses small JSON inscriptions that describe three fundamental actions: deploy (create a new token), mint (create new units), and transfer (send tokens to someone else). Community-run indexers reconstruct token balances by reading the ordered history of these inscriptions, creating a system of "rules by convention" rather than enforcement by Bitcoin's scripting language.

The system works like this: a deploy inscription initializes a token ticker (typically four letters) and sets parameters like maximum supply. Mint inscriptions create new units and credit them to whoever owns the mint inscription. Transfer inscriptions earmark amounts to send. Unlike Ethereum tokens where a smart contract enforces all the rules, BRC-20 validity depends on indexers agreeing on the interpretation of these JSON messages.

The Transfer Process

A BRC-20 transfer follows a two-step process. Think of it like writing a check: First, you create the "check" by making a transfer inscription. This earmarks the funds you want to send. Then, you must physically hand the check to the recipient by sending them the transaction output containing that inscription.

The technical mechanics work as follows: users first inscribe a JSON object declaring their intent to transfer a specific number of tokens, receiving this transfer inscription in the same wallet that holds their BRC-20 balance. This step moves tokens from an "available" balance to a "transferable" pool in the eyes of indexers. Then, the transfer inscription itself must be sent to the recipient's address. When that transaction confirms, indexers debit the sender's balance and credit the recipient.

This creates an important distinction from Ordinals: sending an Ordinal inscription resembles moving a unique physical object, while BRC-20 transfers operate more like managing ledger entries with a paper trail.

The Debate

The emergence of Ordinals and inscriptions has sparked significant debate within the Bitcoin community. Critics argue that storing arbitrary data consumes valuable block space that should be reserved for financial transactions, creates sustained fee pressure that prices out smaller users, and represents a misuse of Bitcoin's design as peer-to-peer electronic cash. Proponents counter that all consensus-valid transactions are legitimate uses of the network, that inscription activity generates fee revenue crucial for long-term miner sustainability as the block subsidy declines, and that preventing users from embedding data would require contentious changes that conflict with Bitcoin's permissionless ethos.

This tension reflects deeper questions about Bitcoin's purpose and evolution: is it purely a payment and settlement layer, or can it accommodate diverse use cases that leverage its unique properties of immutability and censorship resistance?

Strengths and Limitations

Ordinals and BRC-20 demonstrate how Bitcoin's base layer can support digital asset systems through creative use of existing features without requiring new opcodes or consensus changes. They use Taproot's witness space and Bitcoin's transaction model to create application-layer conventions. The blockchain itself remains unchanged.

However, this approach has inherent limitations. Collection-wide rules, royalties, and token supply enforcement exist outside Bitcoin's scripting language and depend on indexers and community conventions rather than cryptographic guarantees. BRC-20 in particular remains explicitly experimental, with even its original creator pointing to alternative systems as more purpose-built solutions. Both systems work across multiple wallets and marketplaces today, but they're best understood as social conventions anchored to real Bitcoin transactions rather than protocol-enforced mechanisms.