Introduction
The BitVMX Protocol Builder is a Rust library for designing Bitcoin protocols as directed acyclic graphs (DAGs) of pre-signed transactions. Each transaction is modeled as a node and each spend as an edge. Encoding protocols in this way captures every valid execution path before anything is sent to the mempool.
The Protocol Builder brings structure to Bitcoin protocol design, making complex systems reproducible and auditable under all conditions. Transactions and signatures can be prepared in advance and broadcast only when needed. For multi-party protocols with timelocks, disputes, or fallback branches, this provides both safety and consistency.
Being a core component of BitVMX, its Open Source release comes as a great opportunity to expand further on its features and key characteristics.
Why A DAG of Pre-Signed Transactions
Bitcoin protocols depend on predictable execution. Bridges, payment channels, and dispute systems must guarantee that every branch of their flow works under all conditions. Hand-crafting these flows is brittle, especially when combining timelocks, multiple signature schemes, and Taproot scripts.
The Protocol Builder addresses this by turning protocols into deterministic flows. All permitted on-chain paths are known in advance, which makes them both predictable and auditable. Time-sensitive branches such as CSV delays or disputes are prepared ahead of time. Hashing and signing are also performed early to coordinate transactions that require MuSig2 aggregation across participants.
Core Abstractions
A Protocol owns the transaction graph and provides the operations for building, signing, and witness assembly. Developers add transactions, inputs, and outputs, linking them. A stateless ProtocolBuilder simplifies common constructions such as Taproot paths, SegWit outputs, timelocks, OP_RETURN commitments, or external UTXOs.
The graph itself tracks transactions and their dependencies, enforces topological order, and models external UTXOs without including them into the build sequence.
Signing and Spend Model
The builder supports ECDSA for SegWit transactions, Schnorr for Taproot, MuSig2 for aggregated key paths, and Winternitz one-time signatures (W-OTS) for signature verification in scripts.
Spending modes can be tuned to the protocol. A Taproot output may include both key and script paths, a key only, or selected leaves. Signing options range from single-key signatures to MuSig2 sessions, or deliberate skips when a participant will sign only at broadcast.
The build pipeline consists of build, which computes transaction IDs and sighashes; and sign, which applies the chosen signature scheme. A build-and-sign option intended for non-collaborative flows is also included.
Balancing and Fee Estimation
Output amounts can be explicitly indicated or automatically computed, ensuring a child covers its own fees. Outputs can also be marked to allow branches to claim its parent’s value if unused. The builder traverses the graph bottom-up, estimates size and witness costs, applies a margin, and backfills concrete values. This guarantees that every branch is valid without manual bookkeeping.
Witness Assembly
Signatures are generated early, but full witnesses are only assembled when a transaction is requested to send. Developers supply input arguments that define which signatures and stack items to attach.
For Taproot, this means selecting a key path or script leaf, providing signatures, and letting the library add the tapscript and control block. For SegWit, DER signatures and stack data are inserted as needed. Deferring witness assembly minimizes leakage of stack data and preserves flexibility.
Handling Speed and Congestion
Since collaboratively pre-signed transactions cannot use replace-by-fee, the builder supports Child-Pays-For-Parent. A CPFP child can be prepared with its own funding input and the necessary signatures, ensuring that under-funded transactions are eventually included in the blockchain without altering the original protocol.
Visualization and Auditability
The builder produces Graphviz-compatible text output that can be used to visualize the DAG. Nodes show inputs, outputs, and values; edges reflect spending relationships. These diagrams help developers review dependencies and communicate protocol logic clearly.
Integration and Extensibility
The library delegates all key management and signing to an external component that handles nonce generation, MuSig2 aggregation, and Winternitz proofs. Protocols can be saved and re-loaded by name, enabling iterative development and reproducibility.
Conclusion
The BitVMX Protocol Builder turns Bitcoin protocol engineering into a structured and auditable workflow. By modeling protocols as DAGs of pre-signed transactions, it ensures deterministic execution, predictable fees, and consistent signatures. Time-sensitive flows can be prepared in advance, dependencies visualized, and congestion handled without manual intervention.
As Layer 2 systems, dispute mechanisms, and cross-chain bridges expand, reproducibility and automation are becoming essential. The Protocol Builder provides the abstractions and tools to build these systems with confidence.
