Developers are increasingly looking for ways to bring decentralized finance (DeFi) capabilities to Bitcoin without compromising its security model. BitVMX is a powerful new framework enabling smart contract logic to run off-chain while remaining verifiable and enforceable through Bitcoin transactions. At the same time, Cardano's tooling and programming models offer a rich source of high-assurance smart contracts built around a UTXO model that aligns closely with Bitcoin's structure. This article explores how BitVMX works at a deep technical level. We explain how Cardano smart contracts written in Plutus or Aiken can be compiled to RISC-V and used to power Bitcoin DeFi. BitVMX: A New Execution Layer for Bitcoin BitVMX is a novel framework that extends Bitcoin's capabilities by enabling complex smart contracts to run off-chain and settle on-chain without modifying the Bitcoin protocol itself. It originates from the BitVM concept of "disputable computation," where two parties can disagree over the execution of a program and resolve their disagreement via Bitcoin Script. BitVMX generalizes and expands this idea, making it suitable for multi-party computation and full program execution using RISC-V, a real-world instruction set architecture. In the BitVMX architecture, the contract logic is expressed as a RISC-V binary. This binary is executed off-chain in a virtual machine environment. The system assumes that all participants are honest by default. Disputes only arise if a participant believes another has produced an invalid execution. In that case, a formal protocol unfolds on Bitcoin, using specially crafted transactions and pre-agreed constraints to enforce the correct outcome. Bitcoin Script Interaction: Verification and Enforcement BitVMX interacts with Bitcoin using its native scripting language and transaction format. Bitcoin Script is intentionally limited in complexity and expressiveness, but BitVMX works within these constraints by designing a system that performs almost all computation off-chain while using Script to enforce correctness. The system relies on two roles: the prover, who claims to have executed the RISC-V contract correctly, and the verifier, who checks that claim. The prover submits a transaction to Bitcoin asserting the outcome of a contract. This includes a cryptographic commitment to the final state of the execution trace. The verifier independently executes the same contract and compares their own trace to the prover's claimed result. If the verifier identifies a discrepancy, they can challenge the prover on-chain. The challenge initiates a dispute protocol, where the verifier forces the prover to reveal intermediate execution states (hashed and linked). Through a binary search-like mechanism, the parties isolate the specific step where the prover's claim diverges from valid execution. Once found, proof of fraud is submitted using a Bitcoin transaction that enforces penalties or reverses the claim. Bitcoin Script plays a crucial role in verifying these disputes. Each step in the protocol is embedded in pre-signed transactions that enforce the flow of the verification game. Script checks the validity of provided hashes, digital signatures, and time constraints. The Bitcoin network itself becomes the impartial judge. Off-Chain Execution and On-Chain Enforcement The primary innovation of BitVMX is that the execution of smart contracts does not occur on-chain. Instead, the RISC-V binary runs in an off-chain virtual machine. This execution is fully transparent and deterministic. All participating parties can run the same program and independently derive the same result. Only in the event of a dispute does execution data begin to touch the blockchain. In such cases, only a few bytes of data per transaction are needed to carry hash commitments and digital signatures. The actual logic and computations remain off-chain, drastically reducing the burden on Bitcoin’s limited block space. The result is a hybrid model: computation happens off-chain, but settlement and dispute resolution happen on-chain. This aligns well with Bitcoin’s design philosophy—minimalism and robustness—while expanding its utility. Side note: This mechanism is similar to how Cardano applications function, where they consist of both on-chain and off-chain components working together. In the case of Cardano, the on-chain component serves as the ultimate settlement layer. There is no prover or verifier in play. Pre-Signed Transactions and Dispute Resolution One of the foundational security mechanisms in BitVMX is the use of a graph of pre-signed transactions. These transactions are prepared and cryptographically signed by all participants, such as two parties engaged in a swap, like Alice and Bob, before the off-chain execution of the smart contract begins. The graph structure encodes every potential state transition or branch in the contract's lifecycle, including successful completions, disputes, and final resolutions. The reason for this pre-signing requirement is that Bitcoin, unlike some other blockchains, does not natively support programmable spending conditions that can evolve dynamically during a contract's lifetime. Instead, the future execution paths must be fixed in advance using a set of transactions that are cryptographically bound to specific outcomes. This ensures that all paths—such as valid execution, challenge responses, or timeouts—can be enforced on-chain without needing to trust any one participant. For example, in the case of a two-party swap, Alice and Bob must both agree to and sign a suite of transactions that include: A claim transaction where Alice asserts a successful execution. A series of challenge transactions that Bob can use to question Alice's result. Response transactions where Alice defends her execution trace. Final resolution transactions that award funds to the rightful party, depending on the outcome. These transactions include commitments to specific hashes of the execution trace, ensuring that any deviation can be detected and proven. Hashes are not all stored directly on-chain, but rather are included in the witness data of transactions when needed, such as during a fraud proof. This model makes it possible for the Bitcoin blockchain to act as the arbiter of truth without needing to see the entire computation, just the minimal data necessary to validate or refute a claim. In the best case, when both parties are honest and agree on the contract's outcome, only one transaction ever hits the Bitcoin blockchain: the one that finalizes and settles the contract (e.g., a swap completion). That transaction includes a proof (in its witness) that execution was performed correctly. The trace hashes themselves are typically not stored on-chain unless there’s a dispute. So if Alice and Bob agree, the execution is done off-chain, and a single cooperative transaction (pre-signed and agreed upon) completes the swap. The role of the prover isn’t limited to just one participant, like the DEX operator. Instead, different people can take on this role. The DEX operator can act as the prover by running the application logic, such as matching orders and computing outcomes. Alternatively, the users involved in a swap, like Alice or Bob, may take on this role depending on the contract structure. Additionally, any participant who has the right to initiate a claim and holds the necessary pre-signed transactions can act as the prover. To fulfill the prover role, a participant must control or co-sign the required pre-signed transactions and be able to generate the off-chain execution trace before submitting the corresponding on-chain commitment, such as the final hash or result. Because all transactions are signed ahead of time and constrained using Bitcoin’s SIGHASH semantics, neither party can deviate from the protocol once execution begins. This pre-commitment architecture is what allows BitVMX to remain trustless, enforceable, and compatible with Bitcoin’s existing consensus rules. These transactions are constructed in advance with the help of Bitcoin’s SIGHASH flags and Taproot outputs. Each branch in the execution graph is cryptographically locked to prevent tampering. For example, a challenge transaction can only be executed if accompanied by a valid signature on a specific execution state hash. In a dispute, these transactions are sequentially published to the blockchain. Each one reveals a fragment of the execution trace and forces the counterparty to respond. If the prover cannot justify a transition or contradicts themselves, the verifier proves fraud using signatures and committed state hashes. The final resolution transaction then moves the funds to the rightful party and punishes the dishonest one. These mechanisms allow Bitcoin to enforce the outcome of arbitrary computations without ever needing to evaluate the computation itself. The chain only needs to verify a few cryptographic conditions, while the rest of the logic remains in the RISC-V program. The UX Challenge The UX of pre-signing transactions and handling disputes is one of the most critical challenges for real-world adoption of BitVMX. Let’s look at how this works today conceptually. In the raw protocol: Every possible transaction that may be broadcast (claim, challenge, response, resolution) must be created and signed in advance. This includes outputs, fee assumptions, and timelocks — all must be fixed. All parties (e.g., Alice and Bob) must agree and sign these before any off-chain execution starts. That’s a lot of complexity. If exposed directly to end users, this would be highly cumbersome. The contract between Alice and Bob can be deployed via dApp interface: Alice wants to enter a BTC/USDM swap. She connects to a DEX UI that supports BitVMX (e.g., a Bitcoin-native version of MinSwap). The dApp (front end) generates all required pre-signed transactions under the hood using libraries or wallet APIs. Alice reviews a summary: "You are about to enter a swap. This will create 7 safety-enforced fallback transactions in case something goes wrong." She clicks “Approve”, and her wallet signs all necessary pre-signed transactions in one batch. A dispute can be handled via watchers or delegation. In case of dispute, users don’t need to act alone. The system may rely on watchtowers — agents that monitor the blockchain and execute challenge protocols on behalf of users. Alternatively, dApps could offer “dispute insurance” or include verifier-as-a-service modules that automatically challenge fraudulent activity. So while Alice and Bob technically have the right to challenge, in practice, they would delegate dispute responsibility to trusted verifiers or automatic scripts. These agents would hold a copy of the execution trace and be paid to intervene when fraud is detected. BitVMX UX will likely follow a similar evolution to the Lightning Network. UPLC to RISC-V: Enabling Cardano Smart Contracts on Bitcoin The key to enabling Cardano smart contracts on Bitcoin lies in the compilation pipeline that transforms a contract written in a Cardano-native language into a form executable by BitVMX. Developers write smart contracts in languages like Aiken or Plutus, which compile to Untyped Plutus Core (UPLC). UPLC is a minimal functional language used to define contract logic for Cardano. IOG has developed a compiler that translates UPLC into RISC-V machine code. This is the same architecture supported by BitVMX. Once compiled, the RISC-V binary can be executed in BitVMX’s off-chain virtual machine, and its outcome enforced on Bitcoin using the aforementioned fraud-proof mechanism. This approach allows a Cardano application to be deployed and run entirely within the Bitcoin ecosystem. The execution uses Bitcoin UTXOs, Bitcoin transactions, and Bitcoin fees. Cardano's blockchain is not involved. The only link to Cardano is in the tooling and language used to define the contract. No Need for Cardano On-Chain: Bitcoin-Only Execution When a Cardano contract is compiled to RISC-V and deployed via BitVMX, the only blockchain involved at runtime is Bitcoin. The application logic is authored using Cardano tools, but all execution and settlement happen through Bitcoin transactions. No ADA is needed. No Cardano chain interactions occur. The user experience remains Bitcoin-native. This enables developers from the Cardano ecosystem to reuse their skills and tools to build Bitcoin-native DeFi applications. At the same time, Bitcoin users benefit from rich contract capabilities without touching any other chain. When Cardano Matters: Cross-Chain Solutions and Native Assets To involve Cardano itself, so its tokens, dApps, or ledger state, a cross-chain bridge is required. Such a bridge must allow secure interaction between Bitcoin and Cardano, without relying on centralized custodians or federated systems. There are several technical paths to achieving this: Verifiable light clients for Cardano running inside BitVMX, which could verify Cardano state transitions from Bitcoin. Zero-knowledge proofs of Cardano ledger state that are succinct enough to be verified in a BitVMX-compiled verifier contract. Multi-signature or threshold signature protocols, involving a decentralized set of relayers or oracles that monitor both chains and enable lock-and-mint mechanisms. These technologies would enable Bitcoin DeFi contracts to recognize and utilize Cardano native assets. For instance, a cross-chain DEX could accept BTC on the Bitcoin side and match it against liquidity held in USDM on the Cardano side, enforcing settlement conditions across both networks. Conversely, a cross-chain bridge would also allow BTC to become a first-class asset within the Cardano ecosystem. This would mean locking BTC on Bitcoin using a BitVMX-enabled covenant, and minting a wrapped representation on Cardano that is fully usable within Plutus-based dApps. With this capability, BTC could be deposited into Cardano-native lending platforms, used to provide liquidity on Cardano DEXs like MinSwap or SundaeSwap, or serve as collateral in Cardano-based stablecoin systems. The execution logic would still follow the same principles: Cardano's UTXO model handles local state and transaction-based interactions, while the bridge ensures cryptographic linkage between the state of the two chains. Whether via direct proofs, signed attestations, or fraud-detectable protocols, such integration would enable richer financial products across both ecosystems. Although no such full-featured bridge has yet been publicly deployed (BitcoinOS showed such a demo, but it is not production-ready yet), early development and research collaborations, such as those between IOG, the developers of BitVMX, and potential protocol layers like Babylon or Mithril, suggest that the roadmap includes secure cross-chain execution. Once in place, Cardano and Bitcoin could act as co-equal execution and settlement layers in an open, multi-chain financial system. Why Cardano’s eUTxO Model is Ideal for Bitcoin DeFi Cardano’s smart contract model is based on Extended UTXO (eUTxO), an evolution of Bitcoin’s original UTXO model. Like Bitcoin, Cardano contracts operate by consuming and producing transaction outputs. However, eUTxO adds additional features: each output can carry arbitrary data, scripts can access transaction context, and execution is deterministic and local. This makes Cardano’s contracts naturally aligned with Bitcoin’s architecture. Developers building on Cardano are already used to stateless contracts, output-based state modeling, and limited global knowledge—all of which are inherent in Bitcoin. In contrast, Ethereum uses an account-based model with a global mutable state. Smart contracts like Uniswap assume they can access and update the centralized contract state. This model is powerful but incompatible with Bitcoin’s design. Adapting a Cardano dApp like MinSwap to run on Bitcoin using BitVMX is comparatively straightforward. Each liquidity pool can be modeled as a UTXO; trades and deposits consume and create UTXOs accordingly. This aligns with both Cardano’s and Bitcoin’s mental model. Adapting Ethereum’s Uniswap, by contrast, would require emulating account balances using UTXOs, redesigning stateful logic into stateless transitions, and rewriting many assumptions about storage and inter-contract calls. It is possible in theory, but cumbersome in practice. What to Expect at the Bitcoin Conference in Las Vegas Input Output Global (IOG) has announced its participation in the upcoming Bitcoin conference in Las Vegas, where Charles Hoskinson himself will be presenting. Based on available information and public statements, it is likely that IOG will showcase a working implementation of a Cardano smart contract, compiled to RISC-V, running via BitVMX on Bitcoin. This demonstration will likely include a simple DeFi application—perhaps a BTC escrow, a lending protocol, or a trustless swap—all executed using Bitcoin transactions, and enforced using the BitVMX dispute mechanism. No Cardano blockchain interaction is expected for the core demo. However, speculation remains around possible cross-chain components. There is a chance that IOG will reveal preliminary work on bridging Bitcoin and Cardano, allowing Cardano native assets (like USDM) to be used in conjunction with BTC. Such a feature would require secure cross-chain messaging or proofs, possibly using ZK techniques or signed commitments. The involvement of Charles Hoskinson hints that this may be more than a technical showcase. It could be a strategic move to position Cardano as a foundational layer for Bitcoin's programmable future, starting with tooling and extending toward full interoperability. Until then, BitVMX represents a clean, scalable way to bring expressive, formally verified contracts to Bitcoin. And thanks to the compatibility of Cardano’s eUTxO model, it may be Cardano developers who lead the charge in building the next generation of Bitcoin-native decentralized finance.
