Bridge Circuit

​

Role in Clementine

​

Covenant Emulation

• Pre-Signed Transaction Set: During peg-in, a committee of n signers pre-signs transactions that govern future peg-outs
• Deterministic Game Tree: Creates a predictable and unalterable execution path for BitVM2 challenge-response
• Automated Enforcement: The circuit receives correct inputs guaranteed by the pre-signed transaction structure

​

BitVM2 Integration

​

Disprove Scripts

• Verifies the main Bridge Circuit computation
• Uses Groth16 proof to validate circuit execution
• Checks Header Chain Proof, Watchtower challenges, SPV, and storage proofs

• Ensures inputs to Bridge Circuit match on-chain state
• Verifies Watchtower challenges weren’t censored
• Confirms block hash commitments via WOTS are used correctly

​

Verification Logic

​

1. Header Chain Proof Verification

// From bridge-circuit/guest/src/main.rs and circuits-lib/src/bridge_circuit/mod.rs
assert_eq!(
    HEADER_CHAIN_METHOD_ID, input.hcp.method_id,
    "Invalid method ID for header chain circuit"
);
guest.verify(input.hcp.method_id, &input.hcp);

• Validates the Operator’s Header Chain Proof (HCP) method ID matches expected value
• Cryptographically verifies the HCP using RISC Zero’s verify() function
• Ensures the Operator is following a valid Bitcoin chain

​

2. Watchtower Challenge Processing

​

3. Simple Payment Verification (SPV)

let mmr = input.hcp.chain_state.block_hashes_mmr.clone();

if !input.payout_spv.verify(mmr) {
    panic!("Invalid SPV proof for txid: {}", 
           input.payout_spv.transaction.compute_txid());
}

• Verifies inclusion of payout transaction in the claimed Bitcoin block
• Uses Merkle tree proof based on transaction IDs
• Confirms block header is in the Merkle Mountain Range (MMR) of the canonical chain

​

4. Light Client Proof Verification

let light_client_circuit_output = lc_proof_verifier(input.lcp.clone());

let lc_l1_block_hash = light_client_circuit_output.latest_da_state.block_hash;
let spv_l1_block_hash = input.payout_spv.block_header.compute_block_hash();

if lc_l1_block_hash != spv_l1_block_hash {
    panic!("L1 block hash mismatch");
}

• Verifies the Light Client Proof from Citrea’s recursive circuit
• Ensures L1 block hash from LCP matches the payout transaction’s block hash
• Validates the L2 state root for storage proof verification

​

5. EVM Storage Proof Verification

let (user_wd_outpoint, vout, move_txid) =
    verify_storage_proofs(&input.sp, light_client_circuit_output.l2_state_root);

assert_eq!(
    user_wd_txid,
    input.payout_spv.transaction.input[payout_input_index].previous_output.txid,
    "Invalid withdrawal transaction ID"
);

• Verifies storage proof for deposit UTXO using state root from LCP
• Verifies storage proof for withdrawal data from bridge contract
• Confirms payout transaction data matches contract state

​

6. Output Generation

let deposit_constant = deposit_constant(
    operator_xonlypk,
    input.watchtower_challenge_connector_start_idx,
    &input.all_tweaked_watchtower_pubkeys,
    *move_txid,
    round_txid,
    kickoff_round_vout,
    input.hcp.genesis_state_hash,
);

let journal_hash = journal_hash(
    payout_tx_blockhash,
    latest_blockhash,
    challenge_sending_watchtowers,
    deposit_constant,
);

guest.commit(journal_hash.as_bytes());

​

Groth16 Proof System

​

Proof Structure

• Elliptic curve points proving witness computation
• Pairing check elements
• Constraint satisfaction evidence

​

Verification Process

fn convert_to_groth16_and_verify(
    compressed_proof: &[u8; 128],
    total_work: [u8; 16],
    image_id: &[u8; 32],
    genesis_state_hash: [u8; 32],
) -> bool {
    let seal = match CircuitGroth16Proof::from_compressed(compressed_proof) {
        Ok(seal) => seal,
        Err(_) => return false,
    };

    let groth16_proof = CircuitGroth16WithTotalWork::new(
        seal, total_work, genesis_state_hash
    );

    groth16_proof.verify(image_id)
}

1. Reconstructs the Work Only Circuit output from total_work and genesis_state_hash
2. Creates output digest using SHA-256
3. Generates claim digest for the proof
4. Verifies against prepared verification key using BN254 curve pairing

​

Key Implementation Files

​

RISC Zero Guest

use circuits_lib::bridge_circuit::bridge_circuit;

pub static WORK_ONLY_IMAGE_ID: [u8; 32] = match option_env!("BITCOIN_NETWORK") {
    Some(network) if matches!(network.as_bytes(), b"mainnet") => MAINNET_WORK_ONLY_METHOD_ID,
    Some(network) if matches!(network.as_bytes(), b"testnet4") => TESTNET4_WORK_ONLY_METHOD_ID,
    Some(network) if matches!(network.as_bytes(), b"signet") => SIGNET_WORK_ONLY_METHOD_ID,
    Some(network) if matches!(network.as_bytes(), b"regtest") => REGTEST_WORK_ONLY_METHOD_ID,
    None => MAINNET_WORK_ONLY_METHOD_ID,
    _ => panic!("Invalid network type"),
};

fn main() {
    let zkvm_guest = common::zkvm::Risc0Guest::new();
    bridge_circuit(&zkvm_guest, WORK_ONLY_IMAGE_ID);
}

• Entry point for RISC Zero zkVM execution
• Dynamically resolves Work Only circuit method ID based on network
• Initializes guest environment and invokes bridge circuit logic

​

Core Circuit Logic

1. Input reading from host
2. HCP verification (line 146)
3. Watchtower challenge processing (line 148-149)
4. Work comparison (line 156-160)
5. SPV verification (line 164-169)
6. Light client verification (line 172)
7. Block hash consistency check (line 178-180)
8. Storage proof verification (line 183-184)
9. Output generation and commitment (line 237-244)

​

Build Configuration

• Compiles bridge-circuit-guest into RISC Zero ELF binary
• Computes unique method ID for the compiled program
• Handles BITCOIN_NETWORK environment variable for network-specific builds
• Optionally uses Docker for reproducible guest builds
• Copies generated ELF to elfs folder with test- prefix if use-test-vk feature enabled

​

Next Steps