Bitcoin Smart Contracts Depend on Spending Paths

Native Bitcoin Script is non-Turing complete, lacks state, and has a ~10KB size limit. This prevents complex DeFi logic, forcing innovation into layers above the base chain.\n- No Native State: Can't track balances or variables over time.\n- Limited Opcodes: Missing key functions for modern applications.\n- Verification Overhead: Every node validates all script logic, limiting complexity.

Using Taproot's key-path/spend-path flexibility and covenant-like patterns (e.g., OP_CTV, OP_APO), complex contracts are enforced by requiring specific spending conditions. Projects like BitVM and Ark use this to create trust-minimized protocols.\n- Off-Chain Logic: Contract state and execution happen client-side.\n- On-Chain Enforcement: Settlement is guaranteed by Bitcoin's consensus.\n- Scalability: Heavy computation is moved off the base layer.

Scaling solutions like Lightning Network and Rootstock (RSK) create their own rule sets for spending locked BTC. They act as independent realms with their own state machines, where Bitcoin L1 only validates the final settlement claim.\n- Sovereign Execution: L2 has its own virtual machine (e.g., EVM on RSK).\n- Batched Settlement: Thousands of transactions settle in a single L1 spend.\n- Specialized Use Cases: Lightning for payments, RSK for general smart contracts.

Federated or miner-secured sidechains (Liquid Network, proposed Drivechains) create alternative blockchains with pegged BTC. The spending path is a multi-sig or threshold signature releasing funds from the L1 peg wallet to the sidechain's consensus rules.\n- Independent Chains: Full blockspace and new opcodes (e.g., Confidential Assets).\n- Faster Finality: ~2 min blocktimes vs. Bitcoin's 10 minutes.\n- Trade-Off: Security depends on a federation or miner set, not pure PoW.

Once a UTXO is created with a specific spending script, its logic is immutable. This creates a permanent attack surface and prevents protocol upgrades without migrating funds to a new contract.

• No Post-Deployment Patches: A discovered bug in a complex Taproot script cannot be fixed; the only solution is to abandon the UTXO.
• Forking Inefficiency: Upgrading a protocol like a DEX or lending market requires users to manually move liquidity, fragmenting TVL and network effects.

Complex contracts like BitVM or Merkleized Abstract Syntax Trees (MAST) encode multiple execution paths. Validators must check all possible paths, creating a verification time bomb.

• Worst-Case Gas: Fees must cover the most expensive path, making simple transactions subsidize complex, rarely-used logic.
• Denial-of-Service Vector: An attacker can force execution down the most computationally expensive path, similar to the Ethereum gas limit attacks of 2016.

Techniques like CTV (CheckTemplateVerify) and APO (AnyPrevout) introduce covenants—rules restricting a UTXO's future spending. This enables secure, upgradeable state machines on Bitcoin.

• Controlled Evolution: A covenant can enforce that a UTXO's value can only move to a new, upgraded script, enabling trust-minimized protocol migrations.
• Native Rollup Security: Covenants are foundational for drivechains and rollups like Botanix or Chainway, allowing assets to be securely locked and released based on off-chain proof verification.

Moving complex state transitions off-chain, as seen in Lightning Network and BitVM, mitigates on-chain path dependency. Disputes are settled on-chain only if a participant is malicious.

• Capital Efficiency: The vast majority of transactions (e.g., Lightning payments) never touch the base chain, avoiding its constraints entirely.
• Fraud-Proof Window: In BitVM-like systems, a single honest validator can challenge invalid state transitions, enforcing correctness without requiring all nodes to verify all logic.

Bitcoin scripts cannot natively fetch external data. Oracles (e.g., for price feeds) must be hardcoded as public keys in the spending path, creating a centralized failure point.

• Single Point of Trust: A DIS (Delegated Signing) oracle's key compromise can drain all dependent contracts, as seen in early Ethereum DeFi hacks.
• Rigid Integration: Switching oracle providers requires a new UTXO, unlike Ethereum where a contract's oracle address can be updated via governance.

Projects like Sovryn's Babylon or Rootstock use federations or Bitcoin's own security to create decentralized data feeds. Taproot's key aggregation can mask multi-oracle consensus.

• Federated Signatures: A MuSig2 threshold signature from a known oracle set can provide robust data with n-of-m security.
• Bitcoin-Time Security: Babylon proposes using Bitcoin's checkpointing to secure external proof-of-stake chains, turning Bitcoin itself into a truth oracle for its own ecosystem.

Unlike Ethereum's account model, Bitcoin's UTXO model lacks a shared memory. This makes complex, stateful applications like AMMs or lending pools fundamentally difficult to build natively.

• State must be encoded directly into transaction outputs.
• Each contract interaction is a destructive update: old UTXOs are spent, new ones are created.
• This leads to data availability challenges and complex state management off-chain.

Smart contracts are enforced via script path conditions that lock a UTXO's future. Projects like Taproot Assets and RGB use this to create off-chain state coupled with on-chain settlement.

• A UTXO can have multiple spending paths (e.g., cooperative close, dispute, timeout).
• Miniscript allows for composable, analyzable Bitcoin Script.
• The contract logic defines who can sign and under what conditions the next output is valid.

The viable pattern is a client-side validation model. The blockchain only enforces the rules; proof of state transitions is managed peer-to-peer. This is the core innovation behind Lightning Network (payment channels) and RGB (client-validated assets).

• On-chain = dispute resolution & settlement layer.
• Scalability is achieved by keeping most data and computation off-chain.
• Requires robust client software and data availability solutions.

Each unique contract is a specific, unforgeable UTXO. This contrasts with Ethereum, where thousands of users interact with a single contract address. This model enables powerful properties but demands a different mental model.

• Enables true ownership and portability of contract state.
• Introduces UTXO management complexity for wallets and indexers.
• Parallel execution is natural, but composability is harder than on EVM.