Patents Wiki
Back to briefings
PaperBlockchain

Cutting the bridge bill by 1000x: how BitVM3 reopens trust-minimized Bitcoin bridging

For most of Bitcoin's history, the cleanest way to move BTC into a smart-contract environment was to hand it to a federation. Lock BTC, mint a wrapped version, trust a multisig of well-known operators not to collude. That model is now under quiet, sustained pressure. Robin Linus and a team of five co-authors have just released a paper that replaces the federation with a cryptographic dispute game powered by garbled circuits. They report a worst-case on-chain dispute cost of roughly 9.Thepreviousstateoftheartwasaround9. The previous state of the art was around 16,000. The cost reduction is large enough to change who can plausibly run a Bitcoin bridge.

The paper is called "BitVM3: Efficient Bitcoin Bridges via Garbled Circuits." It was posted to the IACR Cryptology ePrint Archive in late May 2026, with a revision on June 8. It is the third generation of the BitVM line that Linus kicked off in late 2023. The headline number is repeated in the abstract, the introduction, and the cost-analysis section, and it deserves a careful look. There is a tendency to read "$9" out of context, so it is worth understanding what the paper actually builds and what the cost figure does and does not tell us.

Briefing registry

  • Paper number: IACR ePrint 2026/933
  • Title: BitVM3: Efficient Bitcoin Bridges via Garbled Circuits
  • Authors: Robin Linus Woll (Stanford, ZeroSync), Ioannis Alexopoulos (TU Wien), Lukas Aumayr (University of Edinburgh, Common Prefix), Zeta Avarikioti (TU Wien, Common Prefix), Matteo Maffei (TU Wien), David Tse (Stanford, Byzantine Research)
  • Received: 2026-05-11; revised 2026-06-08
  • Length: 29 pages
  • License: CC BY 4.0
  • Source: Cryptology ePrint Archive, Paper 2026/933

Why the old trust model for Bitcoin bridges is a standing invitation

A bridge, in the sense the paper uses, is a protocol that locks BTC on Bitcoin. It represents that BTC on a second system, typically Ethereum or a Bitcoin rollup. Deployed bridges today are almost all federated: a known group of operators holds the keys, and the system stays safe as long as a majority of them behave. That assumption has been tested in the worst possible way. Ronin lost roughly 625millionin2022.Harmony′sHorizonbridgelostaround625 million in 2022. Harmony's Horizon bridge lost around 100 million the same year. A long tail of smaller incidents has drained funds from permissioned custody schemes regularly. Even when the assumption holds, the operator set is permissioned, deposits are large, and a user with a problem has no on-chain recourse.

BitVM2, the previous state of the art, took a different route. It encoded the bridge's accounting logic into Bitcoin Script using pre-signed transactions. Any honest challenger could dispute an operator's claim by re-running the same logic on chain. The catch was the dispute cost. Pinning down a single bad claim required an on-chain trace large enough to push worst-case fees into the four-figure-to-five-figure dollar range. To make that economic, an operator had to post a bond orders of magnitude larger than the amount being bridged. Minimum deposits drifted upward until only well-funded parties could participate. The result was a bridge that was technically trust-minimized and operationally the same as a federation.

The core idea: move the heavy computation off-chain, keep the dispute on L1

BitVM3 keeps BitVM2's structure. A single operator proposes a state and any challenger can dispute it. But BitVM3 moves almost all of the verification work off the Bitcoin base layer. The bridge's full accounting logic is encoded once at setup time as a garbled circuit. A garbled circuit is an encrypted form of a Boolean circuit. Given the right set of input keys, anyone can evaluate it. But they cannot read the circuit's internal wiring. The operator commits to a claim by publishing a hash of an input to that circuit. A challenger holds the input keys. They evaluate the circuit privately on commodity hardware. Then they produce a witness that proves the operator's claim was wrong.

What changes the economics is what happens next. When a challenger finds a fraud, they post a short proof back to Bitcoin. Because the garbled circuit is fixed at setup, the on-chain proof does not need to re-execute the bridge logic. It only needs to demonstrate that the challenger's local evaluation produced a specific output inconsistent with the operator's claim. The Bitcoin script for that check is small, the witness is small, and the on-chain cost collapses.

The paper makes the comparison explicit: BitVM2's worst-case dispute is roughly 16,000.BitVM3′stotalworst−casedisputeisroughly16,000. BitVM3's total worst-case dispute is roughly 9, with the challenge transaction itself around $0.20. The reduction is on the order of a thousandfold, and the paper largely centers on that fact.

How it all fits together

The architecture has three layers, and the diagram below walks through them left to right.

Core Architecture/Flow

On the Bitcoin side, the operator posts a peg-in UTXO that locks user BTC and commits a collateral bond. To advance the bridge state, the operator publishes an "assert" transaction. This commits to a witness hash and pays roughly 9inon−chainfees.Duringachallengewindow,anychallengercanevaluatethegarbledcircuitagainstthecommittedinput.Iftheoperator′sclaimiswrong,thechallengerpostsashortchallengetransaction(9 in on-chain fees. During a challenge window, any challenger can evaluate the garbled circuit against the committed input. If the operator's claim is wrong, the challenger posts a short challenge transaction (0.20 worst case) that slashes the bond and reverts the state. If the window closes unchallenged, the claim becomes final.

In the middle sits BitVM3-CORE, the paper's reusable abstraction. The garbled circuit is the heart of it. But the authors also formalize it as a sound and complete on-chain proof system under standard cryptographic assumptions. Prior GC-based proposals tend to argue security informally, or at the level of a specific construction. The BitVM3 paper captures a family of GC constructions inside a single formal framework. That is what makes the cost number credible. The reduction is a property of the proof system, not a hand-tuned measurement of one circuit.

On the destination side, the paper describes two variants. The EVM variant works against chains that can produce finality certificates, for example via EigenLayer restaking on Ethereum. The rollup variant works against Bitcoin rollups. For that case, the paper introduces a second contribution: the first on-chain Bitcoin light client that is secure under variable proof-of-work difficulty. Earlier Bitcoin light clients had to assume a fixed difficulty epoch, which limited what they could prove. The new construction removes that assumption and lets a rollup do chain introspection on Bitcoin without trusting an external oracle.

What the paper actually claims

The paper's central claims come in two flavors. The first set is quantitative. Worst-case on-chain dispute cost of about 9forthefullbridge,withthechallengetransactionitselfabout9 for the full bridge, with the challenge transaction itself about 0.20. Worst-case dispute cost of about $16,000 for BitVM2, which is the comparison baseline. A roughly 1000x reduction in total cost. Lower collateral requirements, smaller minimum deposits, and the resulting ability for less-capitalized operators to participate.

The second set is qualitative. The bridge covers two destination families: chains with finality certificates, and Bitcoin rollups. The proof system, BitVM3-CORE, is sound and complete under standard cryptographic assumptions. The authors capture it in a uniform model that covers prior GC constructions. The on-chain Bitcoin light client works under variable difficulty, which the authors describe as a new result.

These are research claims. The paper presents a construction, costs derived from a model of Bitcoin block space, and proofs of security. None of that guarantees that a production bridge using BitVM3 will behave as modeled. The cost estimates may not hold under real mempool conditions. User funds may not be safe.

Why the cost number matters more than the cost itself

The deeper point of the paper is not the 9figure.Itiswhatthatfigureenables.WithBitVM2,anoperatorbridging,say,tenBTChadtopostabondlargeenoughtoabsorba9 figure. It is what that figure enables. With BitVM2, an operator bridging, say, ten BTC had to post a bond large enough to absorb a 16,000 dispute. They also had to pay a risk premium for the time the bond was locked. The economics pushed minimum deposits into a range that effectively excluded retail and small institutional users. Only entities with deep risk budgets remained as plausible bridge operators. That is the structural problem the paper is trying to solve.

BitVM3 changes the constraint. A 9disputeissmallenoughthatabondcoveringroutineoperationalriskisenough.Achallengercanposta9 dispute is small enough that a bond covering routine operational risk is enough. A challenger can post a 0.20 challenge without meaningful exposure. The authors argue that this opens the door to many more operators running bridge nodes. That is what the optimistic model needs to actually be decentralized rather than just labeled as such.

There is a secondary effect. Smaller minimum deposits become viable. A bridge that requires 50,000toenterisnotthesameproductasonethatrequires50,000 to enter is not the same product as one that requires 500. The work in this paper is what shifts the threshold. The two are linked. A smaller bond only works if the challenge cost is small. A smaller deposit only matters if the operational overhead per user is also small.

Limits, open questions, and what to watch

The paper is candid about what it does not solve. First, the cost estimates depend on the garbled circuit fitting in a single Bitcoin transaction envelope. The authors model this but do not deploy it at scale. If real-world circuit sizes push the assert or challenge transaction across additional segwit weight thresholds, the cost numbers move. Second, the security proofs assume at least one honest challenger is online during the challenge window. In practice, the challenger set is open. Liveness arguments have to hold against the possibility that no honest party is watching. Third, the variable-difficulty light client is a new construction. The research community will need to scrutinize the assumptions, particularly around difficulty adjustment edge cases.

There are also practical engineering questions the paper does not address. Who runs the setup phase that generates the garbled circuit, and what trust does that setup require? How is the operator set selected, rotated, and held accountable off-chain? What is the recovery story if the operator goes offline for the entire challenge window? These matter for a production bridge, and they are outside the scope of this paper.

What to watch in the next few months: independent reviews of the BitVM3-CORE proof system, especially the completeness argument under realistic network conditions. Open-source reference implementations. Pilot deployments on Bitcoin testnet or signet, including from the Bitlayer and Citrea teams that have already been experimenting with BitVM2. And the first operational measurements of the assert transaction cost. These will tell us whether the $9 figure survives contact with mempool dynamics.

Sources