Introduction
Bitcoin was purposefully built with minimalism and security at its core. But as new use cases emerge, there's a growing need for systems that extend its capabilities without compromising its principles.
BitVMX brings Bitcoin’s uncompromising security into the world of complex off-chain computation. It enables trustless, scalable, and efficient systems that extend Bitcoin's utility without sacrificing its foundations. Our goal is to expand Bitcoin’s programmability through a modular framework grounded in advanced cryptography and Layer 2 innovation.
But BitVMX is more than just a virtual CPU or an on-chain protocol. It provides a set of core abstractions and tools that accelerate and simplify the development of Bitcoin-native Layer 2 protocols.
Despite their differences, all Bitcoin L2s share a set of fundamental needs.
They must connect to the Bitcoin network, monitor transactions, decode them, and react in real time. They also need to create and sign transactions, which requires secure key management and ideally support for multi-signature coordination such as MuSig2. To fund activity, they need to track and manage UTXOs, which calls for basic wallet functionality.
State persistence is another key requirement. Protocols must store their current state and transition history to safely recover from disruptions. Without it, a node failure can lead to loss of funds. State updates must be reliable, especially given that the Bitcoin blockchain can reorg and remove previously confirmed transactions entirely.
Many protocols also enforce state-transition rules on-chain, which requires generating Bitcoin transaction graphs (DAGs) that encode this logic precisely, in so-called “emulated-covenants”. In complex protocols like BitVM-based bridges, the DAG may include tens of thousands of smart contracts prepared in advance to support future peg-ins, peg-outs, and operator slashing.
On top of that, protocols benefit from encrypted and authenticated peer-to-peer communication, a clean API for external software integration, and a zero-knowledge runtime for proof generation and verification.
This is the context in which BitVMX was created. It fills in the missing infrastructure that every serious Bitcoin L2 needs so developers can focus on what makes their protocols unique.
BitVMX Components
BitVMX is composed of modular components that work together to support the full lifecycle of Bitcoin Layer 2 protocols. Each module handles a distinct responsibility, from transaction orchestration and cryptographic operations to P2P messaging, state persistence, and zero-knowledge proof generation and verification. Together, they form a flexible architecture that can be adapted to a wide range of L2 designs.
The following simplified diagram showcases the main BitVMX components discussed in this section.
Bitcoin Coordinator
Tracks on-chain activity and manages transactions for the protocol. It monitors Bitcoin blocks to detect relevant transactions sent to the blockchain, tracks their confirmations, and builds SPV proofs when needed. It also checks whether spending conditions are met, such as transactions spending specific UTXOs, and coordinates transaction submission to advance protocol state and trigger on-chain enforcement. This component ensures that off-chain protocol logic remains synchronized with on-chain Bitcoin activity.
Key Manager
Generates, stores, and uses cryptographic keys across multiple schemes including ECDSA, Schnorr, Winternitz, and MuSig2. It provides signing, verification, and key aggregation functionality, along with the storage backend. This abstraction ensures consistent and secure cryptographic operations across the entire system.
Protocol Builder
A tool to construct directed acyclic graphs (DAGs) of pre-signed transactions. A protocol represents a graph of potential on-chain execution paths, encoded as a sequence of Bitcoin transactions. This component handles transaction graph construction, signature hash computation, signature generation, and transaction witness creation.
We're planning to add support for pre-computing the initial deposit required to fund the entire transaction graph. This includes dust-level outputs used as anchors or connectors, and also accounts for total transaction fees based on a specified fee rate.
Storage Backend
A persistence layer responsible for storing protocol state, transitions, configuration settings, and cryptographic materials. It ensures the system can resume reliably after disruptions.
The current implementation is built on top of RocksDB and Cocoon for encrypted data, but the design allows for alternative key-value backends to be integrated in the future without impacting the rest of the system. Planned features include support for data mirroring and backup processes.
Wallet
A lightweight Bitcoin wallet for managing keys, funding transactions, and spend from Bitcoin addresses. This hot wallet is used to accelerate transactions with additional transaction fees, and can also be used to collect protocol fees and perform security deposits.
Message Broker
A messaging layer between BitVMX components and also between other whitelisted BitVMX clients and external clients that enables participants to coordinate, exchange data, and drive the protocol forward via peer-to-peer messaging. It includes:
- A synchronous server for handling request-response messages
- An asynchronous client for background message flow
- A dual-channel interface for bidirectional communication
All communication channels are encrypted and authenticated for security.
Risc Zero Guest Adapter
A utility that simplifies integrating Risc Zero guest programs with BitVMX. Developers define their guest code in Risc Zero, and this adapter handles compilation, wrapping, and integration into the BitVMX proof generation and verification pipeline.
BitVMX CPU
The BitVMX CPU is a core component that provides a RISC-V compliant implementation with the I and M extensions. It enables verification of SNARKs, STARKs, and general-purpose RISC-V programs, acting as a disputable CPU on Bitcoin without requiring a soft fork. Future support may include methods such as garbled circuits, giving developers flexibility to choose the verification approach best suited to their protocol design.
BitVMX Client
The central entry point for interacting with BitVMX. It integrates all components into a unified system, exposing a clean API for external software. The client handles coordination, protocol lifecycle management, and integration with external systems.
What it Takes to Build with BitVMX
Let’s walk through what’s required to build a protocol using BitVMX, using a bridge between Bitcoin and a target blockchain (e.g. Ethereum) as an example.
As described earlier, BitVMX was designed to minimize duplication of effort by providing reusable, well-tested components for the common needs of Layer 2 protocols. Its modular architecture lets developers assemble custom solutions while reducing development time and cost. As new features or target blockchains emerge, they can be integrated with minimal disruption by adapting the existing framework.
To build a bridge, some components must be implemented for each side. On the Bitcoin side, BitVMX provides the core tools, but the protocol-specific logic still needs to be defined: transaction graphs, key material, and integration logic. These aren’t generic or reusable across all bridges, but they can be constructed using the BitVMX framework. On the target blockchain side, a chain-specific client must be developed to interact with the target blockchain and the BitVMX client.
The following simplified diagram illustrates the architecture of a bridge built with BitVMX, highlighting the components required on both the Bitcoin and target blockchain sides.
On the Bitcoin Side
BitVMX provides the tools to build what each bridge requires, but the components themselves need to be created for each specific implementation.
Protocols (Bitcoin Transaction Graphs)
Use the Protocol Builder to construct the protocols that define the on-chain logic for peg-ins, peg-outs, and operator slashing. These pre-signed transactions represent the possible execution paths of the bridge protocol.
Cryptographic Materials
Define and generate the keys, aggregated public keys, signatures, and zero-knowledge inputs using the Key Manager, the Emulator and a Zero Knowledge generation tool. These are specific to each deployment and are tied to the protocol’s structure.
State Persistence and Coordination
Store protocol state, transitions, and dispute data using the Storage Backend. Monitor Bitcoin activity and trigger transaction execution with the Bitcoin Coordinator. Coordinate with peers through the BitVMX Broker.
Once these components are prepared, the system is ready to communicate with the target blockchain.
On the Target Blockchain Side
A chain-specific client must be implemented for the target blockchain. This includes:
Light Client
Verifies block headers or relevant state proofs from the target chain. This component allows the bridge to validate events on the target blockchain without relying on trusted third parties, enabling decentralized peg-in and peg-out operations.
Zero Knowledge Proofs
Zero-knowledge proofs for peg operations (deposits, withdrawals, or challenges), aligned with the target chain’s state model and rules. BitVMX provides a ZK proof system through the Emulator and Verifier, but the bridge-specific proofs must be implemented to reflect the target chain’s consensus rules and, where relevant, its longest-chain rule for comparing competing chains.
Transaction Monitor and Dispatcher
Tracks relevant on-chain events and submits transactions on the target blockchain. It plays the same role as the Bitcoin Coordinator, keeping the bridge responsive to protocol activity and enforcing transitions as needed. For Bitcoin rollups, the existing Bitcoin Transaction Monitor and Dispatcher can be reused.
Simplified Key Manager
Handles signing using the target network’s cryptographic scheme. Unlike the full-featured BitVMX Key Manager, this component is limited to the specific signature requirements of the target chain.
Smart Contracts
Implements the locking, unlocking, and slashing logic on the target chain. These contracts define the bridge's execution rules and must be written using the native smart contract language (e.g. Solidity for EVM chains).
Communications API
Built on top of the BitVMX Broker, this layer exposes an authenticated messaging interface that enables communication between the BitVMX client and the target client.
Storage Layer
A lightweight persistence layer to store pending operations and client state. While less complex than BitVMX’s Storage Backend, this component ensures reliability and continuity across restarts or failures. Depending on the storage needs of the chain-specific client, the BitVMX Storage Backend could be reused directly.
Bridging It All Together
By combining the BitVMX stack on Bitcoin with a lean, chain-specific client on the target side, developers can build secure, modular bridges. BitVMX handles Bitcoin integration, transaction orchestration, state persistence, and proof generation. The rest adapts to the target environment.
Conclusion
BitVMX is designed to lower the barrier to building secure, expressive, and trust-minimized protocols on Bitcoin. Its architecture provides the critical infrastructure developers need to move beyond basic proofs of concept and into fully functional systems.
By decoupling protocol-specific logic from core infrastructure, BitVMX enables a new class of applications that would otherwise be too complex or costly to build. Whether you're designing a cross-chain bridge, a rollup, or an interactive computation protocol, the framework offers the primitives to construct and enforce off-chain logic with on-chain security.
This article focused on the bridge use case as a concrete example, but the same principles apply broadly. With BitVMX, developers can reuse well-defined and extensible components to assemble robust Bitcoin Layer 2 protocols without starting from scratch.
We will soon publish tutorials with examples of different types of bridges that can be built using BitVMX.
We’re just getting started. The next generation of Bitcoin-native applications will be more secure, more expressive, and more modular.
Attributions: Icons made by Yogi Aprelliyanto and sbts2018 from flaticon.com
