If you haven’t been paying attention to BitVM, it’s time to start.
We don’t blame you if you haven’t been following the BitVM saga. It’s difficult to explain and there have been multiple evolutions of BitVM to-date.
Robin Linus first introduced the L2 concept in an December 2023 whitepaper. It was immediately greeted with much fanfare as a way to add Ethereum-esque smart contract capabilities to Bitcoin, and it attracted oodles of capital. Since the whitepaper was published, investors have poured over $30 million into the BitVM ecosystem into companies such as Citrea, Alpen Labs, BOB, and BitLayer.
A lot has happened since then. In the beginning, building anything with BitVM was complex and unviable. Recently we’ve seen immense improvements and solutions to some previously impractical workarounds that are making us think that BitVM might actually be all it’s cracked up to be.
Let’s walk through what happened over the past 2 years, the previous development hurdles, and why the latest breakthroughs in BitVM are so promising.
Note: Development on BitVM is ongoing. Case in point, while we were drafting this article, Alpen’s Liam Eagen discovered an issue with one of the latest BitVM schemes. We’re still wrapping our heads around it, but that just goes to show that the BitVM landscape is constantly shifting.
Genesis: The BitVM whitepaper
In the fall of 2023, Robin Linus surprised the world when he published the BitVM whitepaper with the tagline “Compute Anything on Bitcoin.”
At a high level, BitVM describes a way to compute very basic operations on Bitcoin. To be more precise, you can verify that certain operations have been computed. Think of it like a chess game where 2 players can play a game off-chain but then we can verify that the game was played and the right person won. If the “wrong” person says they won, the true winner can challenge that claim and resolve it on-chain using BitVM.
It’s a simple concept but has big implications. Bitcoin can now theoretically do some of the same things as smart contract chains like Ethereum without requiring any changes. Granted, we’re still constrained by things like Bitcoin’s block size and block time, and the BitVM scheme is much less efficient than if you were trying to do the same thing on another chain.
To clarify, BitVM is a scheme that can be used to build many things (you could actually play chess!) but the entirety of research and investment have gone toward building bridges for Bitcoin L2s such as Citrea and Alpen Labs’ Bitcoin rollups. Further, actually building those bridges initially proved more difficult than some realized…
What is a bridge? A bridge allows users to transfer BTC, tokens, and data between two networks (e.g., Bitcoin L1 and an L2). Bridges can take many forms depending on the crypto network, but they generally have an operator or set of operators who run the bridge and require users to make some basic counterparty trust assumptions.
BitVM bridges are easier said than done
Once the dust cleared from the whitepaper investor frenzy, it became clear that actually building a bridge with BitVM was more challenging than anticipated. Some demos from ZeroSync and Citrea proved that the bridges actually worked in the wild, but they also have drawbacks. For example, it could take weeks to resolve disputes, which is terrible for user experience.
Not only that, but the cost to undergo the dispute process could be significant for all parties (especially the one making the dispute) – we’re talking hundreds, thousands of blocks and transactions. This is because the dispute has to prove each off-chain condition (tapleaf circuits) and there could be thousands of conditions. This process creates an untenable user experience; who’s going to pony up potentially tens of thousands in fees and wait weeks for the dispute to resolve?
The dispute resolution was later reduced significantly with BitVM2 (see below), but there was another issue that still needed addressing: the Liquidity problem.
BitVM’s liquidity problem
In spring 2024, the Taproot Wizards published a technical critique of BitVM explaining that BitVM bridges would require operators to front their own BTC to process user withdrawals, because the actual BitVM bridge implementation isn’t really a “bridge” – it’s technically more of a reimbursement system. This means that operators must have immediate access to liquidity equivalent to the withdrawal demands, which scales linearly with the bridge’s total value locked. Failure to have liquidity could cause the bridge operator to incur financial loss.
Basically, a “safe” BitVM bridge would require that a bridge operator have on-hand liquidity equivalent to the entirety of the TVL on the corresponding L2, or else users and the operator risk losing funds.
This story caused some drama (see this relevant Bitcoin Season 2 episode), and although some proposed mitigations, it was clear that a lot more work was needed for BitVM bridges to work in the wild.
BitVM 2: Complex but production ready
Those changes came in August 2024 with the introduction of BitVM 2.
BitVM 2 introduced a ground-up rewrite that significantly improved trust and efficiency. Additionally, BitVM2 allowed anyone to make a dispute – this was previously limited to certain participants
Moreover, BitVM 2 improved the bridge-custody trust model from an honest majority to only requiring one honest operator. BitVM bridges have multiple operators, but as long as a single operator is honest, anyone can make a challenge. Soon after BitVM 2, Citrea deployed its “Clementine” bridge on testnet in September 2024.
Learn more: Blockspace hosted Citrea cofounder Ekrem Bal at OPNEXT 2025 explaining Citrea’s BitVM implementation – link
Despite BitVM 2 meeting the bar for production quality, many issues remained. It still required a comparatively massive on-chain footprint, it was extremely complex, came with liveness requirements, and although “trust-minimized” it is not “trustless”. Additionally, Citrea’s bridge implementation also inadvertently kicked off the OP_RETURN debate. To be clear, Citrea has not made any efforts pushing for changes to Bitcoin Core relay policy. In my opinion, the latest OP_RETURN debate is simply coincidental.
BitVM 3: A 1000x improvement
The biggest change to BitVM, and the one that really pushed it further into the realm of viability, came just this spring.
Last month, Robin Linus published the third BitVM whitepaper, BitVM 3 building on work from Liam Eagen and Jeremy Rubin. While BitVM 2 forces scripts to do heavy computation on-chain, BitVM 3 flips the design. Utilizing an old cryptographic technique from the 80s, BitVM 3 uses “garbled circuits” to achieve a ~1000x improvement to the dispute process. Basically, you’re punished if you lie – the circuit is destroyed if someone tries to cheat.
For comparison, BitVM 1 requires ~1gb on-chain blockspace, BitVM 2 reduces this to under 4mb, and BitVM 3 only requires a few hundred bytes. Stanford Professor David Tse (and Babylon cofounder) calls this evolution “transformational.”
The trade-off is that we’re transmuting what used to be a large on-chain computation into a gigantic off-chain data problem: as high as ~5TB per BitVM operator. That shifts the bottleneck to data-availability networks. But this is a fairly well-charted L2 problem space (although it’s still not fully solved). The tradeoff is clear though: very expensive and limited Bitcoin blockspace vs. potentially cheaper, more available storage off-chain.
Oops! Someone just broke BitVM 3
As a timely illustration of how quickly things move, Alpen Labs’ Liam Eagen published a way to “break” the above BitVM scheme while I was writing this piece. Basically, the new type of circuits described in the BitVM 3 whitepaper have a vulnerability that allows an attacker to access information that should have otherwise been “garbled” or scrambled.
However the scheme described in Linus’s whitepaper isn’t the only one of its kind – there are other ways of skinning this cat garbling this circuit. Basically, if you’re able to reduce the complexity of the circuit then it becomes viable again. Alpen Labs claims to have accomplished this by leveraging a new SNARK recently invented by Liam Eagen which doesn’t contain the above vulnerability. Alpen Labs Ecosystem Lead David Seroy says “[Garbled Circuits] are the way forward, but the circuit has to be smaller and less complex.” He says “there are other ways to make the garbled circuit practical” that are differentiated from Robin Linus’s scheme.
Open problems with BitVM
There are still a number of open questions for BitVM’s viability, but the momentum and scale of improvements indicates that the design space for improvements has a bright future. Some of the remaining challenges:
- Data availability: with BitVM 3 we have a new off-chain data management and communication problem
- Fee-rebate markets: If someone challenges, do they get reimbursed, and if so, how?
- Opcode wish-list: a hypothetical OP_CAT revival or a Merklised OP_TXHASH could collapse circuit size, but they rely on a consensus change
- Competition: there are multiple teams working on BitVM implementations and the space is highly competitive. Many of these teams have brilliant folks working on BitVM, but there is a game being played – everyone wants the general concept of BitVM bridges to succeed, but there is a race to break other team’s implementations. This can result in some delicate & controversial clashes, but the drama sure is fun to watch!
From Whitepaper to the Wild
It’s not often that a hyped whitepaper in crypto actually results in a real impact to crypto networks (beyond launching a thousand affinity scams). BitVM’s progress over 22 months is staggering as it’s evolved into this garbled-circuit beast that squeezes proofs into sub-64 kB envelopes.
The long-standing narrative that “Bitcoin can’t do smart contracts” is looking dated. Now builders just need to ship production bridges, handle terabyte-scale side data, and stress-test fraud-proof economics. If they can clear those hurdles, Bitcoin may soon host some of the most trust-minimised roll-ups in the industry without changing a single consensus rule.
