Bitcoin Smart Contracts Rely on Transaction Graphs

Bitcoin's UTXO model defines all programmatic logic as a directed acyclic graph of spending conditions. This creates a state transition system where smart contracts are not stored code but the permissible paths between transaction outputs. Unlike Ethereum's account-based model with persistent contract storage, Bitcoin's state is ephemeral and bound to coin movement.

Complex contracts require oracles because the transaction graph cannot natively access external data. Protocols like RGB or Liquid must use external attestation services to inject real-world information, creating a trust vector absent in self-contained systems like Solana or Arbitrum. The graph is a closed system.

Scaling this model is intractable for high-frequency applications. Each contract interaction requires a new on-chain transaction, making systems like Lightning Network necessary for scalability. This contrasts with rollups like Starknet or Optimism, which batch thousands of state updates into a single settlement transaction on L1.

Evidence: The most complex Bitcoin script, Taproot, allows for Merkelized Alternative Script Trees (MAST), but its practical use is limited to relatively simple multisig and timelock conditions, not the generalized computation seen in ecosystems like Avalanche or Polygon.

Bitcoin enforces constraints, not logic. Ethereum's EVM is a state machine that computes outcomes. Bitcoin's Script is a predicate that validates a transaction's cryptographic proofs against a set of pre-defined rules.

Contracts are transaction graphs. A Bitcoin smart contract is a directed acyclic graph of unspent transaction outputs (UTXOs). Each node is a UTXO locked with a script; each edge is a transaction that spends it by satisfying its constraints.

Complexity emerges from chaining. Protocols like the Lightning Network (payment channels) and RGB (client-side validation) build complex applications by constructing elaborate, off-chain graphs of these constrained transactions.

Evidence: The Discreet Log Contract (DLC) specification demonstrates this. It creates a multi-step oracle-fed contract using only a series of pre-signed transactions, proving complex logic is possible without an on-chain virtual machine.

Bitcoin is a state machine where the only native state is the UTXO set. Smart contracts on Bitcoin, from Ordinals inscriptions to Stacks Clarity contracts, function by encoding logic into transaction patterns. The network validates the spending conditions, not the contract execution.

Ordinals and Runes create graphs by linking transactions through specific spending rules. A BRC-20 transfer is a spend-to-same-script pattern that the indexer, not the Bitcoin node, interprets. The blockchain provides the immutable, ordered data; the indexer builds the application state.

Layer 2s like Stacks formalize this. Stacks uses a Proof-of-Transfer (PoX) consensus to submit its block headers to Bitcoin. Its Clarity contracts execute off-chain, but their final state is anchored to Bitcoin via a Merkle root. Security derives from Bitcoin's finality of the anchor transaction.

The counter-intuitive insight is that Bitcoin's security model for smart contracts is verification, not computation. Protocols like Liquid Network and RGB use similar models. The heavy computation occurs off-chain; Bitcoin secures the promise that the computed state is correct and finalized.

Evidence: Stacks processes ~50-100k daily transactions off-chain, settling a single hash to Bitcoin every ~10 minutes. This demonstrates the throughput separation: execution scales on Layer 2, security is inherited from Bitcoin's base layer.

Bitcoin Script is not Turing-complete. It lacks loops and complex state management by design, forcing developers to model all logic as pre-signed transaction chains. This creates a deterministic but cumbersome programming model compared to Ethereum's EVM or Solana's Sealevel.

Complexity scales with state, not computation. A simple multi-signature vault requires a pre-defined graph of possible transaction paths. More complex applications like DLCs (Discreet Log Contracts) or RGB protocols must manage exponentially larger graphs for each new condition or participant.

The security model is inverted. Security derives from the constraint of possible futures, not the correctness of runtime execution. A bug manifests as a missing transaction path, potentially locking funds permanently, unlike a reverted EVM transaction.

Evidence: The Liquid Network and Stacks exist as separate layers precisely to bypass these limits, offering richer smart contracts but introducing federated or hybrid trust models alien to Bitcoin's base layer ethos.

Transaction graphs encode logic. Bitcoin's limited scripting language pushes complex logic off-chain. Protocols like RGB and Taro define smart contracts as state transitions across a directed acyclic graph of Bitcoin transactions, where each UTXO points to a specific state.

The base layer is a notary. Bitcoin L1 provides finality and censorship resistance for state transitions, but the contract's business logic lives in the client-side validation of the graph. This separates execution from settlement, similar to Arbitrum's rollup model but without a centralized sequencer.

Client-side validation scales. Every participant validates only the subgraph relevant to them, enabling massive parallelization. This avoids the global state bloat of Ethereum's model, making massive asset issuance feasible without congesting the base chain.

Evidence: The Lightning Network is the canonical example, where a payment channel is a two-party subgraph. Its success proves the model works for high-frequency, low-value transactions, setting the pattern for more complex DeFi primitives on Bitcoin.