What Makes Bitcoin Rollups Break

Bitcoin's 4MB block limit makes on-chain data storage for rollups prohibitively expensive and slow. Off-chain solutions like BitVM's challenge-response or client-side validation shift trust assumptions, creating liveness vulnerabilities and complex withdrawal delays.\n- Cost: On-chain data can be >100x the cost of an Ethereum calldata post.\n- Throughput: Capped by Bitcoin's ~4-8 transactions per second base layer.

A rollup's security depends on its client software. Sovereign rollups (e.g., early Rollkit implementations) require full-node operators to run custom software, risking consensus splits. Smart contract rollups (e.g., Citrea) use a Bitcoin L1 verifier contract, but face BitVM's extreme complexity and high capital lock-up for operators.\n- Attack Surface: A bug in the sovereign client is a network fork.\n- Capital Lockup: BitVM operators must bond significant capital, limiting decentralization.

Moving assets between L1 and L2 requires a secure bridge, which becomes a centralized single point of failure. Most implementations rely on a multisig federation (e.g., Stacks, Liquid Network), trading trustlessness for pragmatism. Even advanced designs using Taproot covenants or time-locked puzzles have limited capacity and introduce new trust assumptions.\n- TVL Concentration: >90% of bridged value often secured by 5-8 entities.\n- Withdrawal Delay: Trust-minimized bridges can have 7-day+ challenge periods.

Bitcoin's probabilistic finality (requiring ~6 block confirmations) means a rollup's state can be invalidated by a deep chain reorganization. This forces rollups to implement long dispute windows or fraud proof delays, crippling user experience for fast withdrawals. Solutions like Babylon aim to provide stake-based finality, but add another layer of cryptographic complexity.\n- Settlement Time: Minimum ~60 minutes for secure Bitcoin finality.\n- Reorg Depth: Historical reorgs of >100 blocks are possible.

Rollups need cheap, abundant data. Bitcoin's ~4MB block limit and high on-chain cost create a severe bottleneck.\n- Compression is mandatory, pushing data to ~10-100x smaller than Ethereum equivalents.\n- Off-chain data solutions (like BitVM's challenge-response) introduce new trust assumptions and latency.\n- Inscriptions/Taproot are clever hacks, but they congest the base layer they're meant to scale.

Bitcoin's slow block time (~10 min) makes optimistic rollups vulnerable. A malicious sequencer can steal funds if the fraud proof challenge window is misaligned.\n- Challenge periods must span days, not hours, to guarantee safety, crippling capital efficiency.\n- BitVM's interactive fraud proofs require multiple round trips on-chain, making disputes expensive and slow.\n- This creates a fundamental trade-off: security vs. withdrawal latency.

Without a native mempool for rollup transactions, sequencing becomes a privileged, centralized role.\n- A single sequencer can censor or reorder transactions for MEV.\n- Decentralized sequencer sets (like in Babylon) require complex Bitcoin-native staking, which is still experimental.\n- Failure here doesn't break safety, but it destroys the credible neutrality Bitcoin is built on.

Moving assets between Bitcoin L1 and the rollup requires a secure bridge, which is a massive attack surface.\n- Multi-sig federations (like early RSK) are trusted and prone to collusion.\n- BitVM 2-of-2 covenants improve security but are complex and limit capital efficiency.\n- A bridge hack would drain the rollup's entire TVL, making it the single point of catastrophic failure.

Bitcoin Script is not Turing-complete. Rollup logic must be implemented within a severely constrained instruction set.\n- Complex operations (e.g., signature aggregation for ZKPs) are impossible on-chain, forcing them off-chain.\n- Every new feature (e.g., a new signature scheme) requires a soft fork or another layer of abstraction.\n- This limits innovation velocity and creates versioning lock-in for deployed contracts.

Rollups pay fees to Bitcoin miners for data and settlement, but don't share sequencer revenue with them.\n- This creates a tragedy of the commons: miners secure the chain but aren't incentivized to prioritize rollup data.\n- During congestion, rollup transactions are outbid by ordinal inscriptions and other fee-paying users.\n- Long-term, this threatens the economic sustainability of the rollup ecosystem.

Bitcoin's ~4MB block limit makes on-chain data posting impossible. Off-chain solutions like BitVM's challenge-response or client-side validation (e.g., RGB) shift the burden, creating liveness assumptions and high sync costs for users.\n- Problem: No native, cheap DA layer like Ethereum's calldata.\n- Solution Space: Compressed inscriptions, sovereign sidechains, or waiting for covenants.

Bitcoin's probabilistic finality (~1 hour for high confidence) means a rollup's state can be invalidated by a deep reorg. This breaks any fraud proof or optimistic challenge window.\n- Problem: A 10-block confirmation on Bitcoin is not a guarantee.\n- Solution Space: Long challenge periods (weeks), or anchoring to multiple checkpoints, which destroys UX.

Moving assets to/from L1 via a multisig or federated bridge creates a centralized point of failure. Even advanced models like BitVM 2-of-2 federations or Drivechain sidechains rely on a fixed, permissioned operator set.\n- Problem: The rollup inherits the security of its smallest bridge, not Bitcoin's.\n- Solution Space: Trust-minimized bridges using covenants (when available) or extensive fraud-proof systems.

Bitcoin Script is intentionally limited. Implementing a fraud proof verifier or validity condition on-chain requires monumental workarounds like BitVM's Bitcoin Script 'circuits', which are complex, size-limited, and computationally explosive.\n- Problem: No native support for the logic required to verify rollup state transitions.\n- Solution Space: Move verification off-chain (sovereign rollups) or accept massive inefficiency.