Destination Chain Awareness

It is crucial for Bitcoin to be aware of the state of other chains (e.g., Ethereum). However, due to Bitcoin’s limited programmability, constructing a light client for other chains directly on Bitcoin is impossible.

Fortunately, we’ve discovered that even without Bitcoin’s native programmability, a secure cross-chain protocol can still be implemented between Bitcoin and other alt-chains. The key insight is: if Bitcoin can reliably verify the state of alt-chains, we can integrate this mechanism into our bridge protocol.

Atomic Swap protocol

Atomic Swap is a trustless, decentralized cross-chain trading protocol that enables users to exchange cryptocurrencies across different blockchains without intermediaries. It relies on cryptographic primitives like Hashed Timelock Contracts (HTLCs) to ensure atomicity—either the entire swap succeeds or nothing happens.

Atomic swaps are easy for users to learn about, as they are a mature protocol widely used in many scenarios, such as the Lightning network and Binance.

We focus only on the key element we can reference: the hashlock (the other component is the timelock, but we won’t explore it here).

Hasklock

A Hashlock is a cryptographic construct that restricts access to funds until a predefined condition is met:

• A secret preimage (s) is hashed to produce a commitment hash (H = hash(s)).

• Funds are locked in a script/contract that enforces:

  • Unlock condition: The correct s must be revealed to match H.

How to Achieve Cross-Chain Awareness?

Cross-chain awareness depends on the leakage of secret s. Bob can obtain secret s on Bitcoin only if Alice claims the asset on the destination chain by revealing s. Based on this logic, we design the following mechanism:

"If the operator is slashed on the destination chain, they can also be slashed on Bitcoin (because any challenger can spend the disprove transaction)."

This means that when the operator is slashed on the destination chain, secret s must have been leaked, allowing any challenger to use s to slash the operator on Bitcoin.

---

Hashlock-Based BitVM2 Bridge Protocol

The hashlock-based solution enables challengers to easily detect malicious behavior—such as an invalid Bitcoin block submitted in a claim. The process consists of two main phases:

1. Pre-Sign Phase

• All challengers generate their own secret value s_i.

• All challengers submit H(s_i) (the hash of s_i) to the bridge service.

• The bridge service aggregates these hashes into a Merkle root and constructs a Taproot address, which will be used on both the destination chain and Bitcoin.

• The user, operator, and committee pre-sign necessary transactions.

Note: Submitting s_i is permissionless—any challenger can participate.

1. Challenger Phase

   1. Challenge Initiation

      • Challenger A raises a challenge.

   2. Operator Response

      • The operator submits the assert transaction to respond to the challenge.

   3. Slashing Execution

      • Challenger B (who may be different from Challenger A) slashes the operator on the destination chain by revealing secret s_i.

   4. Disprove Transaction

      • Any challenger can then submit the disprove_2 transaction using s_i.

   Note: The disprove_2 transaction prevents a malicious operator from withdrawing BTC from the bridge.

If you want to understand how we prevent challengers from maliciously slashing the operator, please see the section: Permissionless slashable protocol