Bitcoin Scaling Pushes Risk Off-Chain

The canonical bridge is the single point of failure for any L2. Its security model—be it multi-sig federations, light clients, or optimistic verification—defines the entire system's trust assumptions.\n- Multi-sig Dominance: Most bridges rely on ~8/15 federations, a significant regression from Bitcoin's Nakamoto Consensus.\n- Proving Latency: Zero-knowledge proofs for trust-minimized bridges (like zkBridge) introduce ~20-minute finality delays, creating a window for chain reorg attacks.

A single, profit-maximizing sequencer (e.g., Stacks, Liquid) controls transaction ordering and inclusion, replicating the miner extractable value (MEV) and censorship problems of Ethereum pre-PBS.\n- Forced Inclusion Lags: Users must wait for an L1 challenge period (~24hrs) to bypass a censoring sequencer, breaking composability.\n- Revenue Leakage: MEV that should accrue to Bitcoin miners is captured by off-chain operators, creating misaligned incentives.

If transaction data isn't reliably posted to L1, the L2 can't be rebuilt and funds can be stolen. Optimistic rollups and validiums make this risk explicit.\n- Cost-Driven Compromise: To save fees, operators may use Data Availability Committees (DACs) or external solutions like Celestia, trading security for scalability.\n- L1 Fee Spikes: During congestion, posting data can cost >$50K/hour, incentivizing operators to skip posts and risk fraud.

The Problem: Bitcoin's base layer is too slow and expensive for micro-payments.\nThe Solution: A network of bidirectional payment channels that settle on-chain only for opening/closing. This creates a hub-and-spoke topology where liquidity concentrates around major nodes, introducing systemic counterparty risk.\n- ~1,000-5,000 TPS theoretical capacity\n- ~$200M in public channel capacity\n- Risk: Requires constant online presence, capital locking, and complex inbound liquidity management.

The Problem: Institutions need fast, confidential Bitcoin settlements and asset issuance.\nThe Solution: A federated sidechain secured by a multi-sig of 15+ functionaries (exchanges, custodians). Users trade Bitcoin's proof-of-work security for ~2-minute block times and confidential transactions.\n- ~$400M in TVL\n- Enables stablecoins, security tokens\n- Risk: The federation is a centralized attack vector; users must trust the signatories not to collude.

The Problem: Bitcoin lacks a native smart contract layer for DeFi and apps.\nThe Solution: A separate proof-of-transfer (PoX) blockchain that uses Bitcoin's block hashes as its source of truth. Stacks miners spend BTC to mine, anchoring state to Bitcoin every block.\n- ~$100M DeFi TVL\n- Enables NFTs, DeFi on Bitcoin\n- Risk: Security is not inherited; Stacks has its own consensus and validator set. Compromise of the Stacks chain does not affect BTC.

The Problem: Existing L2s sacrifice too much of Bitcoin's security model.\nThe Solution: Bitcoin rollups (like Citrea, Chainway) use new opcodes (OP_CAT, OP_CHECKTEMPLATEVERIFY) to post fraud or validity proofs directly to Bitcoin L1. This moves the scaling computation off-chain but keeps the security and data availability rooted in Bitcoin.\n- Aims for EVM-equivalent execution\n- Leverages Bitcoin's $1T+ security budget\n- Risk: Early stage; depends on future Bitcoin protocol upgrades and novel cryptography.

Bitcoin's ~7 TPS and ~10-minute block times are incompatible with DeFi. On-chain execution is a $5+ cost for simple swaps, making microtransactions and complex smart contracts economically impossible.

• Throughput Ceiling: Layer 1 is a global settlement layer, not an execution engine.
• Cost Prohibitive: Data and computation are priced at a security premium.
• State Bloat: Storing all application data on-chain is unsustainable.

Protocols like Lightning Network (payment channels) and Stacks (clarity VM) move execution off-chain. They batch transactions, settle proofs periodically to Bitcoin, and inherit base-layer security for finality.

• Lightning: Enables ~1M TPS potential with instant, sub-cent payments.
• Stacks/sBTC: Enables DeFi apps via a separate VM, using Bitcoin as a cryptographic anchor.
• Trade-off: Users now trust the liveness and honesty of L2 operators or watchtowers.

Moving value between L1 and L2 requires bridges (like sBTC or multisig federations). This creates a new centralization vector and $B+ honeypot. The security model shifts from Bitcoin's PoW to the bridge's governance.

• Custodial Risk: Most bridges use multisig federations (e.g., 8-of-15 signers).
• Liveness Risk: If an L2 sequencer fails, funds can be temporarily stuck.
• Oracle Risk: Price feeds and state proofs become critical, single points of failure.

You must choose between sovereign rollups (like BitVM) and client-side validation (like RGB). Sovereign chains offer more flexibility but weaker coupling to Bitcoin. Client-side validation maximizes privacy and scalability but sacrifices global composability.

• BitVM: A fraud proof system allowing any computation to be verified on Bitcoin, but with complex setup.
• RGB: Client-validated state where all data is kept off-chain, enabling massive scale but requiring active user participation.
• Trade-off: There is no free lunch—scalability is purchased with complexity and new trust models.