BitVM Bridge and OP-DLC: Design Approaches for the Next-Generation Bitcoin Layer2 Cross-Chain Bridges
TechFlow Selected TechFlow Selected
BitVM Bridge and OP-DLC: Design Approaches for the Next-Generation Bitcoin Layer2 Cross-Chain Bridges
Understanding the design philosophy of a new generation of Bitcoin cross-chain bridges through Bitlayer and Citrea.
Navigating Web3 tides with focused insightsAuthors: Faust & Nickqiao, Geeker Web3
Abstract:
-
ZK bridges deploy smart contracts on Chain A to directly verify block headers and corresponding zero-knowledge proofs from Chain B, confirming the validity of cross-chain messages. This represents the highest security level among bridge solutions. Optimistic/OP bridges rely on fraud proofs to challenge invalid cross-chain messages on-chain—so long as at least one honest challenger exists, the safety of the bridge’s fund pool is guaranteed.
-
Due to technical limitations, Bitcoin mainnet cannot directly support ZK bridges, but optimistic bridges can be implemented using BitVM and fraud proofs. Teams like Bitlayer and Citrea adopt BitVM-based bridge designs, incorporating pre-signing and channel-like mechanisms that allow users to predetermine how their deposits will be handled before making a deposit, eliminating opportunities for bridge operators to misuse user funds.
-
The BitVM bridge fundamentally operates on a "pay-first, reimburse-later" model, where dedicated Operator nodes send funds to withdrawing users, then periodically apply for reimbursement from a public deposit address. If an Operator submits fraudulent reimbursement claims, anyone can challenge and slash them.
-
Theoretically, BitVM bridges have no security flaws, but they face liveness/availability issues and fail to meet specific user demands for fund independence and anti-money laundering (as they still operate as pooled funds). To address this, Bitlayer introduces an alternative bridging solution called OP-DLC, similar to DLC.link, which builds upon payment channels and DLCs while introducing fraud proofs to prevent oracle malice in DLC bridges.
-
Given the high implementation difficulty of BitVM and fraud proofs, DLC bridges will launch first as interim alternatives. By mitigating oracle trust risks and integrating more reliable, mature third-party oracles, DLC bridges can currently serve as safer withdrawal verification methods than multisig bridges.
Introduction
Since last year's inscriptions boom, the Bitcoin ecosystem has entered a period of explosive growth. In just half a year, nearly 100 projects claiming to be BTC Layer2s have emerged, turning it into a chaotic new frontier filled with both opportunity and scams. It’s not an exaggeration to say that today’s Bitcoin ecosystem resembles a “melting pot” of diverse technologies—akin to Ethereum, Cosmos & Celestia, CKB, and native Bitcoin innovations—all converging without authoritative oversight. Much like 19th-century America absorbing waves of settlers, the Bitcoin ecosystem has become a land of opportunity for various factions. While this brings vitality and narrative richness to Web3, it also introduces significant risks.
Many projects begin aggressive marketing even before releasing any technical documentation, touting themselves as "native Layer2s" and falsely claiming full inheritance of Bitcoin mainnet security. Some resort to inventing obscure jargon as part of their promotional tactics to assert superiority. Although self-promotion has become commonplace in the Bitcoin space, several top-tier KOLs have raised legitimate concerns.
Recently, Monanaut, founder of blockchain explorer Mempool, publicly criticized current issues within the Bitcoin ecosystem, sharply pointing out that if a Bitcoin Layer2 relies solely on a multisig withdrawal bridge that doesn’t allow users to withdraw assets in a trustless manner, it cannot be considered a true Layer2. Interestingly, Vitalik previously stated that Layer2 security should be stronger than systems relying purely on multisigs.
Indeed, Monanaut and Vitalik have candidly highlighted technical shortcomings in Bitcoin Layer2s: many L2 withdrawal bridges are essentially multisig bridges, whether controlled by several well-known institutions each holding one key, or using decentralized POS-based signing schemes. Regardless, their security models depend on the “honest majority assumption”—that most signers won’t collude maliciously.
Such heavily trust-dependent withdrawal bridge designs are unsustainable. History shows that multisig bridges eventually suffer exploits. Only minimally trusted or near-trustless asset custody models can withstand time and attacks from hackers. Yet, the reality in the Bitcoin ecosystem is that many teams haven’t even published technical roadmaps for their bridges, let alone concrete plans for minimizing trust in these systems.
However, this does not represent the entire picture. Some project teams have shared thoughtful approaches to improving withdrawal bridges. In this article, we will briefly analyze Bitlayer and Citrea’s BitVM bridge designs and explain Bitlayer’s OP-DLC bridge—a complementary solution addressing the limitations of BitVM bridges—helping more people understand the risks and design principles behind cross-chain bridges, which is crucial for all participants in the Bitcoin ecosystem.
Optimistic Bridges: Fraud Proof-Based Bridge Verification
In essence, a cross-chain bridge simply proves that a certain event occurred on Chain A to Chain B. For example, when transferring assets from ETH to Polygon, the bridge must prove you actually sent funds to a designated address on the Ethereum chain, allowing you to receive equivalent tokens on Polygon.
Traditional cross-chain bridges typically use multisig validators (or “watchmen”), who run nodes across chains and monitor off-chain whether users have deposited funds into bridge addresses.
Their security model mirrors that of multisig wallets, defined by configurations such as M/N thresholds, ultimately relying on the honest majority assumption—that most validators act honestly. Limited fault tolerance makes them vulnerable. Most major cross-chain bridge hacks in history have involved such multisig bridges, due either to insider theft or external attacks.
In contrast, “optimistic bridges” based on fraud proofs and “ZK bridges” are significantly more secure. Take ZK bridges: they deploy specialized verifier contracts on the destination chain to validate withdrawal proofs directly on-chain, removing reliance on off-chain watchers.
For instance, a ZK bridge connecting ETH and Polygon would deploy a verifier contract (say, Verifier) on Polygon. The bridge’s Relayer node forwards the latest Ethereum block header along with its ZK proof to Verifier for validation. This effectively allows the Verifier contract to sync and verify the latest Ethereum block headers directly on Polygon. Block headers contain Merkle roots linked to transaction sets inside blocks, enabling verification of whether a specific transaction exists within a block.
If 10 transactions from ETH to Polygon appear in Ethereum block #101, the Relayer generates Merkle Proofs related to those 10 transactions and submits them to the Verifier contract on Polygon, asserting:
Block #101 on Ethereum contains 10 cross-chain transfers from ETH to Polygon. Alternatively, the ZK bridge can convert Merkle Proofs into ZK Proofs and submit only the ZK Proof to the Verifier. Throughout this process, users need only trust that the bridge’s smart contract is bug-free and that zero-knowledge cryptography itself is sound—eliminating the excessive trust assumptions required by traditional multisig bridges.
Optimistic bridges work slightly differently—some retain validator-like roles but introduce fraud proofs and challenge windows. After validators generate a multisig signature for a cross-chain message, it is submitted to the target chain but not immediately accepted. Only after a challenge window passes without dispute is the message deemed valid. This concept closely resembles Optimistic Rollups. Of course, optimistic bridges may vary in design, but fundamentally, their security relies on fraud proof protocols.
A multisig bridge under M/N setup assumes N-(M-1)/N honesty—you assume no more than M-1 malicious actors exist among N participants. A ZK bridge requires negligible trust assumptions, whereas an optimistic bridge based on fraud proofs assumes only 1/N honesty: among N validators, only one honest actor needs to challenge invalid messages on-chain to ensure bridge security.
Currently, technical constraints limit us to building ZK bridges only for depositing from Bitcoin to Layer2. For withdrawals—from Layer2 back to Bitcoin—we’re restricted to multisig bridges, optimistic bridges, or channel-like models (the OP-DLC bridge discussed later falls into this category). To build an optimistic bridge on Bitcoin, fraud proofs must be introduced, and BitVM enables precisely this capability.
As explained in our previous article "A Simplified Explanation of BitVM: How to Verify Fraud Proofs on BTC", BitVM’s fraud proof mechanism breaks down complex off-chain computations into many simple steps, then selects one step to be verified directly on the Bitcoin chain. This approach bears strong resemblance to Ethereum optimistic rollups like Arbitrum and Optimism.
(The BitVM2 whitepaper describes splitting computation tasks via Lamport signatures into numerous intermediate steps, allowing anyone to challenge a single step)
While the above explanation remains somewhat abstract, most readers likely grasp the general idea of fraud proofs. Due to length constraints, we won't delve into the technical intricacies of BitVM and fraud proof implementations here, as they involve complex interaction flows.
Instead, we’ll focus on product and mechanism design, briefly explaining native BitVM bridges proposed by BitLayer, Citrea, BOB, and even the official BitVM team, as well as how Bitlayer uses its OP-DLC bridge to mitigate BitVM bridge bottlenecks, showcasing superior withdrawal bridge designs possible on Bitcoin.
(Diagram of Bitlayer’s bridging solutions)
Understanding Bitlayer and Citrea’s BitVM Bridge Design
Below, we use publicly disclosed BitVM bridge designs from Bitlayer, Citrea, and Bob to illustrate the overall workflow of BitVM bridges.
In their official documents and technical blogs, these teams clearly outline the product design philosophy behind BitVM withdrawal bridges (currently theoretical). First, when a user initiates a withdrawal via the BitVM bridge, a withdrawal statement is generated through the Layer2 Bridge contract, containing the following key parameters:
-
Amount of pegged BTC to be burned on L2 (e.g., 1 BTC);
-
Cross-chain fee the user intends to pay (assume 0.01 BTC);
-
User’s L1 receiving address: L1_receipt;
-
Withdrawal amount (i.e., 1 – 0.01 = 0.99 BTC)
Then, this withdrawal statement is included in a Layer2 block. The BitVM bridge’s Relayer node synchronizes L2 blocks, monitors for withdrawal statements, and forwards them to the Operator node, which sends funds to the withdrawing user.
It’s important to note that the Operator pays the user first—essentially fronting funds (“垫付”) on behalf of the BitVM bridge—and later applies for reimbursement from the BitVM bridge’s fund pool.
When applying for reimbursement, the Operator must provide proof of their Bitcoin chain payment (proving they transferred funds to the user’s specified L1 address, extracting the relevant transaction record from a Bitcoin block). Additionally, the Operator must present the withdrawal statement generated on L2 (using Merkle Proof to show it originated from an actual L2 block, not fabricated). Then, the Operator must prove the following:
-
Funds advanced by the Operator equal the amount requested by the user in the withdrawal statement;
-
Reimbursement claimed does not exceed the amount of pegged BTC burned on Layer2;
-
All L2-to-L1 withdrawal statements over a given period have been processed, with each matching a corresponding withdrawal transaction on the Bitcoin chain;
This essentially penalizes Operators for falsely reporting advance amounts or refusing to process withdrawal requests (addressing censorship resistance in withdrawal bridges). The Operator must perform off-chain verification, comparing critical fields between the payment proof and withdrawal statement to confirm matching BTC amounts.
If a BitVM bridge Operator falsifies the advance amount, it means they claim the L1 payment proof matches the L2 withdrawal statement, but in reality, they do not match.
In this case, the ZKP proving Payment Proof = Withdrawal Statement must be incorrect. Once published, a challenger can identify the erroneous step and initiate a challenge via BitVM2’s fraud proof protocol.
Notably, Bitlayer, Citrea, BOB, ZKBase, and others follow the latest BitVM2 architecture—an upgraded version of BitVM that ZK-ifies off-chain computations. This involves generating ZK proofs for off-chain processes, verifying those proofs, and translating the verification logic into BitVM-compatible formats for subsequent challenges.
Moreover, by leveraging Lamport signatures and pre-signing, the original BitVM’s multi-round interactive challenges can be optimized into single-round non-interactive ones, greatly reducing challenge complexity.
The BitVM challenge process relies on something called a “commitment.” Let’s clarify what a commitment is. Typically, someone publishing a commitment on the Bitcoin chain asserts that certain off-chain data or computations are accurate, and the on-chain declaration is the “commitment.”
We can roughly equate a Commitment to the hash of a large set of off-chain data. The Commitment itself is highly compressed but can be bound via Merkle Trees to vast volumes of off-chain data, none of which needs to go on-chain.
In BitVM2, Citrea, and Bitlayer’s BitVM bridge designs, if someone believes the Operator’s on-chain commitment is flawed—because it references an invalid ZKP verification process—they can launch a permissionless challenge. (The internal interactions are complex and won’t be detailed here.)
Since the Operator fronts funds from the BitVM pool to pay withdrawing users and later seeks reimbursement, during reimbursement they publish a Commitment proving the L1 payout matches the L2 withdrawal request. If this Commitment survives the fraud proof challenge window unchallenged, the Operator can withdraw their reimbursement.
Here, we must explain how the BitVM bridge’s public fund pool is maintained—as this is precisely the crux of any cross-chain bridge. Everyone knows that the funds available for withdrawal come from depositors or other liquidity providers. Since Operators front money, they eventually reclaim it from the public pool. Therefore, in terms of final fund flow, total deposits should equal total withdrawals. So, how these deposit funds are safeguarded becomes critically important.
In most Bitcoin Layer2 bridge designs, multisig accounts are used to manage pooled assets. User deposits are aggregated into a multisig wallet, which disburses withdrawals. This approach clearly carries substantial trust risk.
Bitlayer and Citrea’s BitVM bridges instead adopt ideas from Lightning Network and payment channels: Before depositing, users communicate with the BitVM Federation to obtain pre-signatures, achieving the following effect:
After users send funds to a deposit address, the money is locked into a Taproot address accessible only by the bridge Operator. Moreover, the Operator can only reclaim these funds by applying for reimbursement after having already advanced withdrawal funds to users. Only after the challenge period ends can the Operator withdraw a certain amount of user deposits.
In the BitVM bridge design, there exists a BitVM Federation composed of N members responsible for managing user deposits. Yet these N members cannot misuse user funds because, prior to depositing, users require the BitVM Federation to pre-sign, ensuring deposits can only be legitimately reclaimed by Operators.
(BitVM2’s illustration of its optimistic bridge design)
In summary, the BitVM bridge borrows concepts from channels and the Lightning Network, enabling users to “verify by yourself.” Through pre-signing, it prevents the BitVM Federation from arbitrarily controlling the deposit pool—the pool’s funds can only reimburse Operators. If an Operator falsely reports advances, anyone can issue a fraud proof and challenge it.
If successfully implemented, the BitVM bridge would become one of the most secure Bitcoin withdrawal bridges: theoretically free of security vulnerabilities, though subject to liveness/availability issues. Users attempting to deposit might face censorship or refusal from the BitVM Federation, preventing successful deposits—but this relates to availability, not security.
However, implementing the BitVM bridge is technically challenging, and it cannot satisfy large holders with high demands for fund transparency—such users may have anti-money laundering concerns and prefer not to mix their funds with others. Yet the BitVM bridge pools all depositors’ funds together, effectively creating a mixed fund pool.
To address the liveness issues of the BitVM bridge and provide independent, clean fund channels for users with special needs, the BitLayer team added an OP-DLC bridging solution—complementing the BitVM2 optimistic bridge with a DLC-style bridge similar to DLC.link, offering users two entry/exit options (BitVM and OP-DLC), thereby reducing dependency on the BitVM bridge and the BitVM Federation.
(DLC schematic diagram)
DLC: Discreet Log Contracts
DLC (Discreet Log Contracts), or Discreet Log Contracts, was proposed by MIT’s Digital Currency Initiative. Originally designed to enable lightweight smart contracts on Bitcoin, DLC allows privacy-preserving contract functionality without putting contract details on-chain, using off-chain interactive communication and pre-signing techniques. We’ll now illustrate how DLC works using a sports betting example.
Suppose Alice and Bob want to bet on the outcome of a Real Madrid vs. Barcelona match happening in three days, each contributing 1 BTC. If Real wins, Alice gets 1.5 BTC and Bob recovers 0.5 BTC—effectively Alice gains 0.5 BTC, Bob loses 0.5 BTC. If Barcelona wins, Alice recovers 0.5 BTC, Bob takes 1.5 BTC. In case of a draw, both get back 1 BTC.
To make this betting process trustless, we must prevent either party from cheating. Using plain 2-of-2 or 2-of-3 multisig isn’t sufficient. DLC offers a solution (relying on a third-party oracle). The entire workflow consists of four main stages.
Taking Alice and Bob as examples, first, both create a fund transaction off-chain, locking their respective 1 BTC into a 2-of-2 multisig address. Once confirmed, spending from this address requires authorization from both parties.
Of course, this fund transaction isn’t broadcast yet—it remains locally stored in Alice and Bob’s clients. Both know the consequences once it goes live. At this stage, they are merely simulating outcomes and reaching agreements based on these simulations.
In the first phase of DLC creation, we establish that both parties will eventually lock 1 BTC each into a shared multisig address.
Second, both continue to simulate possible future events and outcomes: after the match result is announced, possibilities include Alice winning/Bob losing, Alice losing/Bob winning, or a draw—each leading to different distributions of BTC from the 2-of-2 multisig address.
Different outcomes require different triggering transactions. These "potential future on-chain transactions" are called CETs (Contract Execution Transactions). Alice and Bob must precompute all possible CETs and generate a complete dataset of CET transaction data.
For example, based on the possible outcomes of Alice and Bob’s bet, Alice creates the following CETs:
-
CET1: Alice receives 1.5 BTC from the multisig address, Bob receives 0.5 BTC;
-
CET2: Alice receives 0.5 BTC, Bob receives 1.5 BTC;
-
CET3: Each receives 1 BTC.
Take CET1 as an example (Alice gets 1.5 BTC, Bob gets 0.5 BTC):
This transaction moves 1.5 BTC from the multisig address to a Taproot address triggered jointly by Alice and the oracle’s output, while 0.5 BTC goes to Bob’s address. The associated event: Real Madrid wins, Alice profits 0.5 BTC, Bob loses 0.5 BTC.
To spend this 1.5 BTC, Alice must obtain the oracle’s signature confirming “Real Madrid won.” In other words, only after the oracle outputs “Real victory” can Alice move the 1.5 BTC. CET2 and CET3 follow similarly and won’t be repeated here.
Note that a CET is essentially a pending on-chain transaction. What happens if Alice broadcasts CET1 prematurely, or submits CET1 on-chain when “Barcelona won,” despite CET1 being unlockable only when “Real won”?
As shown earlier, once CET1 is on-chain, it moves 2 BTC from the original multisig address: 0.5 BTC to Bob, 1.5 BTC to a Taproot address unlockable only upon receipt of the oracle’s “Real won” signature. As illustrated below.
Additionally, this Taproot address is time-locked: if Alice fails to withdraw the 1.5 BTC within the lock-up window, Bob gains full rights to claim it.
Thus, provided the oracle is honest, Alice cannot access the 1.5 BTC. Once the time lock expires, Bob can take it. Adding the 0.5 BTC already sent to him via CET1, Bob ends up with all 2 BTC.
For Alice, regardless of win or loss, her optimal strategy is always to broadcast the correct CET—submitting an invalid CET causes greater losses.
Actually, during CET construction, Schnorr signatures on Taproot are enhanced—using the oracle’s public key plus event outcomes to generate distinct addresses per outcome. Only when the oracle reveals a signature for a specific outcome can funds locked to that outcome’s address be spent.
There’s another scenario: suppose Alice knows she lost and refuses to broadcast CET1. What then? Simple—Bob can construct his own custom CET for “Alice loses, Bob wins,” achieving nearly identical effects, differing only in minor details.
Above is the core CET construction process. The third step involves Alice and Bob exchanging and verifying each other’s CETs, signing them, and upon mutual confirmation, both depositing 1 BTC into the initial 2-of-2 multisig address, waiting for one CET to be broadcast and trigger downstream actions.
Finally, when the oracle publishes the result and signs it, either party can submit the correct CET on-chain to redistribute the 2 BTC. If the loser submits a wrong CET first, they lose everything; submitting the correct one lets them recover 0.5 BTC.
One might ask, how is DLC different from ordinary 2-of-3 multisig? First, under 2-of-3 multisig, any two colluding parties can steal all assets. DLC limits all scenarios upfront via pre-built CET sets—even if the oracle colludes, damage is usually limited.
Second, multisig requires all parties to sign specific on-chain transactions, whereas in DLC, the oracle only needs to sign event outcomes—not knowing CET content or even the existence of Alice and Bob—interacting normally like
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
