Bitcoin Virtual Machine Comparison: BitVM, RGB, Liquid & More
Compare Bitcoin virtual machine proposals and programmability layers: BitVM, BitVM2, RGB, Liquid, Starknet, Rootstock, and Stacks for smart contracts on Bitcoin.
Bitcoin Virtual Machines and Programmability Layers
Bitcoin's scripting language was intentionally limited by design: no loops, no global state, and a small opcode set that prioritizes security over expressiveness. These constraints make Bitcoin the most secure settlement layer in cryptocurrency, but they also prevent native smart contract execution of the kind found on Ethereum or Solana. Bitcoin virtual machines and programmability layers are the various approaches to bringing general computation to Bitcoin without weakening its base-layer security model.
The approaches differ fundamentally in where computation happens, what trust assumptions they introduce, and how much data touches Bitcoin L1. Some rely on fraud proofs, others on validity proofs or federated consensus, and some keep computation entirely off-chain with only cryptographic commitments anchored to Bitcoin. The following table provides a high-level comparison.
| Platform | Computation Model | Trust Assumptions | On-Chain Footprint | Status | Primary Use Cases |
|---|---|---|---|---|---|
| BitVM / BitVM2 | Off-chain execution, on-chain fraud proofs | 1-of-n honesty (BitVM2) | 1 tx optimistic; 3 txs dispute | Mainnet (bridges) | Bridge verification, rollup settlement |
| RGB Protocol | Client-side validation | Sender-receiver only | Commitment in OP_RETURN or Taproot | Mainnet (v0.11+) | Token issuance, smart contracts |
| Liquid Network | Extended Bitcoin Script (Elements) | Federation (15 functionaries) | None on Bitcoin L1 (sidechain) | Mainnet (since 2018) | Confidential txs, asset issuance, covenants |
| Starknet (Bitcoin) | ZK-STARK proof verification | Trustless (requires OP_CAT) | STARK proof on-chain | Signet testnet | Bridge verification, rollup settlement |
| Rootstock (RSK) | EVM-compatible sidechain | Merge-mining + federation | None on Bitcoin L1 (sidechain) | Mainnet (since 2018) | DeFi, Solidity smart contracts |
| Stacks | Clarity VM (Proof of Transfer) | PoX miners + Bitcoin finality | Block hashes anchored to Bitcoin | Mainnet (Nakamoto upgrade live) | DeFi, NFTs, sBTC |
For a broader view of Bitcoin L2 networks including Lightning and Ark, see the Bitcoin Layer 2 comparison tool.
BitVM: Fraud-Proof Computation on Bitcoin
BitVM, proposed by Robin Linus in October 2023, introduced a mechanism for verifying arbitrary computation on Bitcoin without consensus changes. The core insight is that Bitcoin Script, despite its limitations, can verify the correctness of individual logic gate computations. By decomposing any program into a circuit of NAND gates and committing to each gate's state in a Taproot address, a prover can claim a computation result off-chain while a verifier retains the ability to challenge any incorrect step on-chain.
The original BitVM had significant limitations: it was restricted to a two-party setting (one prover, one verifier), required large Bitcoin Script commitments, and dispute resolution could require up to 70 on-chain transactions through a bisection protocol. These constraints made it impractical for production bridge designs.
BitVM2, published in August 2024 by Robin Linus, Alexei Zamyatin, and collaborators, addressed all three limitations. It introduced permissionless challenging (any Bitcoin full node operator can dispute a fraudulent claim), reduced the trust model to 1-of-n (only one honest participant needs to exist during setup), and compressed dispute resolution from 70 transactions to just 3, resolvable in one to two weeks. BitVM2 achieves this without any Bitcoin consensus changes.
A further iteration, BitVM3 (2026), reduced the Assert transaction size to approximately 2.4 kvB: a 1,700x reduction from BitVM2. Fraud proofs shrunk to roughly 93 vB, making on-chain disputes dramatically cheaper.
BitVM Bridge Implementations
The primary application of BitVM is trustless bridge verification. Several projects have deployed BitVM-based bridges:
- Bitlayer launched the first BitVM bridge on mainnet in July 2025, minting YBTC tokens with a 1:1 BTC peg
- Citrea deployed its Clementine Bridge (BitVM-based) on testnet, then launched Citrea mainnet on January 27, 2026
- BOB (Build on Bitcoin) launched a BitVM bridge on public testnet in July 2025
The BitVM Alliance, founded by ZeroSync, coordinates development across core members including Fiamma, Element Labs, Citrea, Strata (incubated by Alpen Labs), and Bitlayer. For a deeper technical explanation, see our research article on BitVM trustless Bitcoin verification.
RGB Protocol: Client-Side Validation
The RGB protocol takes a fundamentally different approach to Bitcoin programmability. Rather than executing computation on any blockchain (main chain, sidechain, or rollup), RGB keeps all contract logic and state entirely off-chain through client-side validation. When a user receives an RGB asset, the sender provides a "consignment" containing the full history of state transitions back to the asset's genesis. The recipient validates this history locally against the contract's schema rules.
On-chain, RGB uses only a small commitment embedded in a Taproot transaction output or OP_RETURN field. This means RGB transactions are indistinguishable from regular Bitcoin transactions to outside observers, providing strong privacy guarantees while keeping the on-chain footprint to a few dozen bytes.
RGB v0.11.1 launched on Bitcoin mainnet in July 2025, followed by v0.12 which added zk-STARK support. A significant milestone came in August 2025 when Tether announced plans to launch USDT natively on Bitcoin via RGB. Use cases include token issuance, smart contracts with complex state machines, and digital identity credentials.
The tradeoff is interactivity: RGB transfers require direct communication between sender and receiver to exchange consignment data. This complicates use cases like DeFi protocols where contracts need to interact autonomously, and it limits composability compared to account-model systems.
Liquid Network: Federated Programmability
The Liquid Network is a federated sidechain operated by Blockstream, live on mainnet since October 2018. Unlike BitVM or RGB, Liquid does not attempt trustless verification on Bitcoin L1. Instead, it extends Bitcoin's scripting capabilities within a separate consensus environment secured by a federation of 15 functionaries who sign blocks and manage the BTC peg via multisig. The broader Liquid Federation includes 87 member organizations.
Liquid's Elements platform adds capabilities that Bitcoin mainnet lacks. OP_CHECKSIGFROMSTACK allows signature verification against arbitrary messages (enabling oracle-based contracts). Over 30 introspection opcodes, introduced with Liquid's Taproot upgrade, allow scripts to inspect transaction fields directly on the stack. These opcodes enable production covenants on Liquid today: spending conditions that constrain where and how funds can move, a feature Bitcoin mainnet does not yet support.
Liquid also provides confidential transactions (hiding amounts and asset types using Pedersen commitments) and native asset issuance (L-BTC, Liquid securities, and fungible tokens). The tradeoff is federation trust: users must trust that a majority of the 15 functionaries will not collude to steal pegged funds or censor transactions.
Starknet: ZK-STARK Verification on Bitcoin
StarkWare, the team behind Starknet, has pursued direct zero-knowledge proof verification on Bitcoin. They successfully verified the first STARK proof on Bitcoin's Signet testnet using OP_CAT, demonstrating that Bitcoin Script (with OP_CAT enabled) has sufficient expressiveness to verify STARK proofs natively.
The long-term vision is a fully trustless bridge between Starknet and Bitcoin: OP_CAT activation on mainnet would let Bitcoin nodes natively verify Starknet state transitions, enabling a validity proof-based bridge with no federation or fraud-proof delay. For 2026, StarkWare is pursuing a trust-minimized bridge using a cryptographic verifier on Bitcoin as an intermediate step. The project also launched strkBTC for ZK-powered shielded bitcoin on its L2.
The critical dependency is OP_CAT activation on Bitcoin mainnet, which remains a subject of active debate in the Bitcoin development community. Without OP_CAT, Starknet's Bitcoin integration relies on trust-minimized rather than fully trustless mechanisms.
Rootstock and Stacks: EVM and Clarity on Bitcoin
Sidechains like Rootstock (RSK) and independent chains like Stacks take a different path: they run their own execution environments while anchoring security to Bitcoin through various mechanisms.
Rootstock is Bitcoin's longest-running EVM-compatible sidechain, secured through merge-mining with Bitcoin miners. This means Bitcoin miners can simultaneously secure both networks without additional energy expenditure. Rootstock supports Solidity smart contracts, making it accessible to Ethereum developers. Its DeFi TVL sits at approximately $98 to $109 million, with protocols like Money on Chain and Sovryn accounting for roughly 77% of activity. In Q1 2025, Rootstock achieved a 60% reduction in transaction fees.
Stacks uses Proof of Transfer (PoX), where Stacks miners spend BTC to mine STX blocks, and block hashes are anchored to Bitcoin transactions. The Nakamoto upgrade (Q4 2024) brought faster block production and improved Bitcoin finality. sBTC, a decentralized tokenized BTC, launched deposits on mainnet in December 2024 and withdrawals in April 2025, currently secured by 14 elected signers. Stacks uses Clarity, a decidable smart contract language designed to prevent common vulnerabilities like reentrancy.
Trust Model Comparison
The trust assumptions of each approach determine the security guarantees users actually receive. The following table breaks down trust models, consensus requirements, and key risks.
| Platform | Trust Model | Requires Bitcoin Soft Fork | Dispute Mechanism | Key Risk |
|---|---|---|---|---|
| BitVM2 | 1-of-n honesty (existential) | No | 3-tx fraud proof (1-2 weeks) | All n participants collude |
| RGB | Direct counterparty only | No | N/A (client-side) | Data loss, sender unavailability |
| Liquid | 8-of-15 federation | No | N/A (federated consensus) | Functionary collusion or compromise |
| Starknet (Bitcoin) | Trustless (with OP_CAT) | Yes (OP_CAT) | STARK validity proof on-chain | OP_CAT may not activate |
| Rootstock | Merge-mining + Powpeg federation | No | N/A (PoW consensus) | Low hashrate share, federation risk |
| Stacks | PoX miners + signer set | No | Bitcoin finality via PoX | Signer centralization, PoX assumptions |
BitVM2's 1-of-n model is notable because it only requires one honest participant to exist at setup time: a significantly weaker trust assumption than Liquid's 8-of-15 federation or traditional multisig bridges. Starknet's approach would be fully trustless (relying only on cryptographic proof verification) but depends on a Bitcoin consensus change that has not yet been activated.
How These VMs Enable Bitcoin DeFi
Each programmability layer unlocks different categories of DeFi applications on Bitcoin:
Bridge verification:
- BitVM2 enables trust-minimized bridges that let BTC move to rollups and sidechains without relying on a federation majority
- Starknet's STARK verification (if OP_CAT activates) would enable fully trustless two-way bridges with cryptographic settlement on Bitcoin L1
Token issuance:
- RGB enables private, scalable token issuance with minimal on-chain footprint: Tether's planned USDT on RGB is the highest-profile example
- Liquid supports confidential asset issuance with built-in amount and type blinding
Smart contract execution:
- Rootstock provides full EVM compatibility for Solidity developers building lending, trading, and yield protocols
- Stacks offers Clarity smart contracts with Bitcoin finality, supporting DeFi protocols and NFT markets
- Liquid's covenant opcodes enable programmable spending conditions, vaults, and time-locked contracts
For Bitcoin-native applications like stablecoin payments, protocols such as Spark provide an alternative path: fast off-chain settlement for BTC and assets like USDB without requiring a separate VM or execution environment.
Choosing a Bitcoin Programmability Layer
The right choice depends on what you are building:
If you need trustless bridge verification between Bitcoin and an L2: BitVM2 is the most mature option that works today without a soft fork. Projects like Citrea and Bitlayer have deployed BitVM-based bridges on mainnet.
If you need private, scalable token issuance: RGB offers the smallest on-chain footprint and strongest privacy properties. Its client-side validation model keeps all contract state off-chain.
If you need production covenants and confidential transactions today: Liquid provides extended scripting with introspection opcodes in a federated environment that has been running since 2018.
If you need EVM compatibility to port existing Ethereum contracts to Bitcoin: Rootstock is the direct path, with full Solidity support and merge-mining security.
If you need a purpose-built smart contract language with Bitcoin finality: Stacks and its Clarity language offer a decidable, auditable contract environment anchored to Bitcoin through Proof of Transfer.
For a comparison of Bitcoin Layer 2 solutions focused on scaling rather than programmability, see the Layer 2 comparison tool.
Frequently Asked Questions
What is BitVM and how does it work?
BitVM is a computing paradigm that enables verification of arbitrary computation on Bitcoin without consensus changes. A prover claims a computation result off-chain, and any verifier can challenge an incorrect claim using on-chain fraud proofs. In the optimistic case (no fraud), settlement requires a single Bitcoin transaction. BitVM2 improved the original design by enabling permissionless challenges and reducing dispute resolution from up to 70 transactions to just 3.
Can Bitcoin run smart contracts?
Bitcoin cannot run Turing-complete smart contracts natively due to its intentionally limited Script language. However, multiple approaches enable smart contract functionality: BitVM verifies computation via fraud proofs, RGB executes contracts client-side with on-chain commitments, Rootstock runs a full EVM sidechain, and Stacks provides its own Clarity VM. Each approach trades off between trust assumptions, performance, and the degree of Bitcoin security inherited.
What is the difference between BitVM and a rollup?
A rollup is a complete execution environment that batches transactions and posts state commitments to a base layer. BitVM is not a rollup itself: it is a verification mechanism that rollups can use to settle on Bitcoin. For example, Citrea uses BitVM2 to verify its ZK-rollup state transitions on Bitcoin L1. BitVM provides the fraud-proof infrastructure; the rollup provides the execution environment.
Does BitVM require a Bitcoin soft fork?
No. BitVM, BitVM2, and BitVM3 all work within Bitcoin's existing consensus rules, using Taproot script paths and precommitted gate logic. This is a key advantage over approaches like Starknet's STARK verification, which requires OP_CAT activation (a soft fork) to work trustlessly on Bitcoin mainnet.
What is client-side validation in RGB?
Client-side validation means that contract state and transaction history are stored off-chain by the participants, not on any blockchain. When receiving an RGB asset, the recipient receives a consignment: the full chain of state transitions from the asset's genesis. The recipient validates this history locally. Only a small cryptographic commitment is published on Bitcoin, making RGB transactions private and extremely lightweight on-chain.
How does Liquid extend Bitcoin Script?
Liquid's Elements platform adds opcodes that Bitcoin mainnet does not have. OP_CHECKSIGFROMSTACK enables signature verification against arbitrary data (useful for oracle feeds). Over 30 introspection opcodes allow scripts to read transaction fields directly, enabling covenants: spending conditions that constrain future transaction outputs. These features have been in production on Liquid since its Taproot upgrade, providing a testing ground for script extensions that may eventually reach Bitcoin mainnet.
Which Bitcoin VM has the smallest on-chain footprint?
RGB has the smallest on-chain footprint by a wide margin. An RGB transaction places only a cryptographic commitment (a few dozen bytes) in a Taproot output or OP_RETURN, indistinguishable from a regular Bitcoin transaction. BitVM2 requires a single transaction in the optimistic case but can consume up to 4 MB during a dispute. Liquid and Rootstock operate as separate chains with no direct L1 data footprint, but require federation-managed peg transactions.
This tool is for informational purposes only and does not constitute financial or investment advice. Development statuses, trust models, and protocol specifications change frequently. Always verify current information through official project documentation before making technical or financial decisions.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →
